UNIVERSIDAD DEL VALLE DE GUATEMALA

Facultad de Ingeniera

Megaproyecto: CanSat Fase 2

Mdulo: Software de Vuelo

Trabajo de graduacin en modalidad Megaproyecto presentado por

Juan Fernando Medrano Yax
Para optar al grado acadmico de Licenciado en Ingeniera Mecatrnica

Guatemala, Noviembre de 2014

Megaproyecto: CanSat Fase 2

Mdulo: Software de Vuelo

UNIVERSIDAD DEL VALLE DE GUATEMALA

Facultad de Ingeniera

Megaproyecto: CanSat Fase 2

Mdulo: Software de Vuelo

Trabajo de graduacin en modalidad Megaproyecto presentado por

Juan Fernando Medrano Yax
Para optar al grado acadmico de Licenciado en Ingeniera Mecatrnica

Guatemala, Noviembre de 2014

4

Vo. Bo. :

(f) _________________________________________________
Ing. Gustavo Antonio Prera Sierra

Tribunal Examinador:

(f) _______________________________________________
Ing. Gustavo Antonio Prera Sierra

Ing. Victor Hugo Ayerdi Bardales

Ins Alberto Esquit Hernndez

PREFACIO
El objetivo de este megaproyecto fue disear y construir un picosatlite con la forma de una lata y
competir con este en la Annual CanSat Competition, organizada por agencias y compaas de la industria
aeroespacial estadounidense. El presente trabajo trata uno de los 8 mdulos que componan al picosatlite:
el software de vuelo. Este software fue el encargado de permitir, controlar y coordinar todas las actividades
bsicas de funcionamiento y cumplir los objetivos de la misin.

Agradezco el apoyo de mis compaeros de equipo, en quienes pude confiar durante todo el proyecto y
de quienes aprend y experimente valores como la tolerancia y el trabajo en equipo. Sin ellos sencillamente
este trabajo y experiencias no seran una realidad. A mi asesor, Ingeniero Gustavo Prera quien siempre se
mostr atento a proporcionar consejos, ayuda e ideas respecto al desarrollo del trabajo a continuacin, as
como con otros procesos ms administrativos. Al Ingeniero Vctor Ayerdi de quien todos en el equipo
aprendimos cualidades tiles para el trabajo en un puesto real y que la ingeniera es un proceso en que se
debe encontrar el mejor compromiso entre muchas variables (algunas desconocidas). Al Ingeniero Luis Zea
por su apoyo constante como monitor del equipo y como espejo en el que pudimos tener una imagen
mental de cmo un ingeniero de NASA lo evaluara. Finalmente a mis padres y hermanos, quienes siempre
mostraron inters en este proyecto, apoyo para permitirme alcanzarlo y compaa en cada pequeo paso
que daba.

NDICE
Pgina
Lista de Cuadros ........................................................................................................................................... vii
Lista de Figuras ........................................................................................................................................... viii
Resumen ..........................................................................................................................................................x
I.

Introduccin .......................................................................................................................................1

II.

Objetivos ............................................................................................................................................3

III.

Justificacin........................................................................................................................................4

IV.

Marco terico .....................................................................................................................................5

V.

Metodologa .......................................................................................................................................9

VI.

Resultados ........................................................................................................................................ 64

VII.

Anlisis de resultados ....................................................................................................................... 88

VIII.

Conclusiones .................................................................................................................................... 91

IX.

Recomendaciones ............................................................................................................................. 92

X.

Bibliografa ...................................................................................................................................... 94

XI.

Anexos ............................................................................................................................................. 96

vi

LISTA DE CUADROS
Pgina

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

Requerimientos de Software de Vuelo .............................................................................................. 9

Ponderacin de los criterios utilizados para la seleccin de microcontrolador. .............................. 39
Valores normalizados de las variables evaluadas para la seleccin del microcontrolador. ............ 40
Ponderacin de los criterios utilizados para la seleccin de microcontrolador. .............................. 40
Verificaciones realizadas durante la competencia para comprobar que todos los elementos
relacionados al funcionamiento del software estuvieran completos. .............................................. 70
Pruebas iniciales realizadas al software y sistema electrnico de Contenedor para verificar su
funcionamiento correcto. ................................................................................................................ 71
Pruebas iniciales realizadas al software y sistema electrnico de Carga til para verificar su
funcionamiento correcto. ................................................................................................................ 72
Pruebas iniciales realizadas al software y sistema electrnico de Carga til para verificar su
funcionamiento correcto. ................................................................................................................ 74
Criterios evaluados en la Revisin de Seguridad. ........................................................................... 75
Pasos de configuracin y verificacin realizados para la preparacin del software de Contenedor
para el lanzamiento. ........................................................................................................................ 77
Pasos de configuracin y verificacin realizados para la preparacin del Software de Carga til
para el lanzamiento. ........................................................................................................................ 78
Prueba de verificacin de comunicacin entre Contenedor y Estacin en Tierra durante la
instalacin del picosatlite en el cohete. ......................................................................................... 79
Resultados de las operaciones realizadas por el Contenedor durante el lanzamiento. .................... 80
Resultados de las operaciones realizadas por la Carga til durante el lanzamiento. ...................... 84

vii

LISTA DE FIGURAS
Pgina

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.

Flujo general de un programa orientado a eventos/interrupciones [4]. .............................................6

Arquitectura de Hardware de Contenedor. ...................................................................................... 12
Arquitectura de Hardware de Carga til. ........................................................................................ 12
Diagrama de Estados y Condiciones de Transicin de la Carga til. ............................................. 15
Diagrama de Estados y Condiciones de Transicin de la Carga til. ............................................. 16
Modelo de Capas del Software de Carga til. ................................................................................ 17
Modelo de Capas del Software de Contenedor. .............................................................................. 18
Diagrama de flujo y condiciones de transicin del ciclo principal (main) de la Carga til y
Contenedor. Ntese que las operaciones mostradas aqu son las operaciones principales y todas se
ejecutas por ocurrencia de un evento/interrupcin (indicado por la flecha punteada). ................... 21
Diagrama de flujo y condiciones de transicin para la operacin principal Muestreo de Sensores
de la Carga til. .............................................................................................................................. 22
Diagrama de flujo y condiciones de transicin para la operacin de muestreo del sensor de
aceleracin. ..................................................................................................................................... 23
Grfico de llamadas de funciones de la operacin de muestreo de sensor de aceleracin. ............. 25
Grfico de llamadas de funciones de la operacin de muestreo de sensor de voltaje. .................... 25
Grfico de llamadas de funciones de la operacin configuracin de sensor de aceleracin. ......... 25
Grfico de llamadas de funciones de la operacin de muestreo de sensor de temperatura. ............ 26
Grfico de llamadas de funciones de la operacin de muestreo de sensor de presin..................... 26
Grfico de llamadas de funciones de la operacin de almacenamiento de paquetes de datos en
memoria externa. ............................................................................................................................. 26
Grfico de llamadas de funciones de la operacin de recuperacin de cuenta de nmero de
paquetes........................................................................................................................................... 26
Grfico de llamadas de funciones de la operacin de borrado de memoria externa........................ 26
Grfico de llamadas de funciones del ciclo de ejecucin principal. ................................................ 27
Diagrama de flujo del algoritmo implementado para la liberacin de la carga til. ....................... 32
Diagrama grfica del vuelo y de los puntos en que se verifica el estado de vuelo del picosatlite. 33
Diagrama de flujo del algoritmo implementado para muestrear el sensor de presin LPS331AP del
Contenedor. ..................................................................................................................................... 34
Diagrama de flujo del algoritmo implementado para muestrear el sensor de aceleracin ADXL345
de la Carga til. .............................................................................................................................. 35
Diagrama de flujo del algoritmo implementado para muestrear el sensor de presin BMP085de la
Carga til. ....................................................................................................................................... 36
Diagrama de flujo del algoritmo implementado para muestrear el sensor de temperatura
BMP085de la Carga til. ................................................................................................................ 37
Diagrama esquemtico Rev. 2 (Final) del circuito de funcionamiento del microcontrolador para la
Carga til. ....................................................................................................................................... 42
Diagrama esquemtico del circuito de conexin del cable para monitoreo/prueba. ....................... 45
Diagrama esquemtico del circuito recolector de energa de paneles solares y regulador de voltaje.
........................................................................................................................................................ 48
Diagrama esquemtico del circuito de conexin de memoria externa 24AA128. ........................... 48
viii

30. Diagrama esquemtico del driver del servomotor utilizado para la liberacin de la Carga til del
Contenedor. ..................................................................................................................................... 50

31. Diagrama esquemtico del circuito de alimentacin de Servomotor. ............................................. 50

32. Diagrama esquemtico del circuito de alimentacin del sistema electrnico a bordo del
Contenedor. ..................................................................................................................................... 51

33. Primer prototipo del circuito impreso del Sistema Electrnico integrado de la Carga til.
Izquierda: Vista Trasera. Derecha: Vista Frontal y antena de XBEE.............................................. 52

34. Diseo y presentacin preliminar 3D del circuito impreso del Sistema Electrnico integrado de la
Carga til. Izquierda: Vista Trasera. Derecha: Vista Frontal y antena de XBEE. .......................... 52

35. Versin final del circuito impreso del Sistema Electrnico Integrado de la Carga til. Izquierda:
Vista Trasera. Derecha: Vista Frontal y antena de XBEE............................................................... 53

36. Anlisis del intercambio de datos a travs del bus I2C entre el sensor BMP085 y el

37.

38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.

microcontrolador. Arriba se presenta el bus utilizando un analizador lgico. Abajo se muestra la

seal el bus utilizando un osciloscopio. El bus est compuesto por una lnea de datos, y una lnea
de reloj. ........................................................................................................................................... 55
Anlisis de la integridad y datos de la seal serial entre el software de vuelo y el dispositivo XBE.
Arriba se muestra la seal de acknowledge utilizada OK/n decodificada utilizando un analizador
lgico. Abajo la misma seal analizado utilizando un osciloscopio para verificar su forma y
niveles de voltaje. ............................................................................................................................ 56
Evolucin en el tiempo de la seal enviada al dispositivo XBEE. ........................................... 57
Graficas de aceleracin generadas por la estacin en tierra. La generacin de estas grficas implica
un funcionamiento integrado correcto............................................................................................. 57
Prueba de liberacin de Contenedor y Carga til bajo condiciones reales. .................................... 65
Pruebas de envo de datos e interaccin entre sistema electrnico, software y estacin en tierra. .. 67
Prueba de paracaidismo realizada con el picosatlite diseado en conjunto con la Asociacin
Guatemalteca de Paracadismo. ...................................................................................................... 67
Hoja de Evaluacin de la Revisin de Seguridad. ........................... Error! Marcador no definido.
Verificacin de conexin activa entre Contenedor y estacin en tierra. ......................................... 79
Grfica generada por la estacin en tierra con los datos de presin enviados por el Contenedor. .. 81
Fotografa tomada en el lugar del lanzamiento en la que se observa el Contenedor (Arriba derecha)
y la Carga til (Abajo izquierda) completamente separados y descendiendo haciendo uso de sus
respetivos sistemas de control de descenso. .................................................................................... 82
Fotografa tomada en el lugar del lanzamiento en la que se observa la carga til y el cohete
descendiendo. .................................................................................................................................. 83
Grfica de aceleraciones en funcin del tiempo generada por la estacin en tierra en base a los
datos almacenados en la memoria interna de la Carga til. ............................................................ 84
Grfica de altura en funcin del tiempo generada por la estacin en tierra en base a los datos
almacenados en la memoria interna de la Carga til. ..................................................................... 85
Grfica de temperatura en funcin del tiempo generada por la estacin en tierra en base a los datos
almacenados en la memoria interna de la Carga til. ..................................................................... 85
Grfica de voltaje de la fuente de energa. Esta grfica fue generada por la estacin en tierra en
base a los datos almacenados en la memoria interna de la Carga til. ........................................... 86
Diagrama esquemtico completo del Sistema Electrnico de Carga til. ..................................... 96
Diagrama esquemtico completo del Sistema Electrnico de Contenedor. ................................... 97

ix

RESUMEN
Un CANSAT es un satlite artificial con una masa entre 0.1kg y 1 kg con las dimensiones de una lata. El
CANSAT debe cumplir con la misin y los requerimientos de la competencia Annual CANSAT
Competition, para luego participar en sta en el ao 2014.
El Software de Vuelo

es la parte de un CANSAT que se encarga del control, mantenimiento,

regulacin y coordinacin de todas las actividades del mismo, tanto para el cumplimiento de los objetivos
para los cuales el CANSAT fue diseado durante la misin como para su propio funcionamiento fuera de la
misin: es el centro de operaciones y comunicaciones. Es una seccin crtica en el sentido en que es la parte
que provee autonoma de operaciones al CANSAT. Este Software de Vuelo est almacenado como
instrucciones que forman algoritmos y rutinas dentro de dispositivos microcontroladores a bordo del
CANSAT, y como parte de los sistemas electrnicos. El desarrollo e implementacin completa de dicho
software es el tema y trabajo de este mdulo.

Se desarroll un sistema electrnico centrado en un microcontrolador en el cual se ejecuta el software

de vuelo. El CANSAT est compuesto por dos vehculos: un Contenedor y una Carga til que viaja dentro
del primero. Se desarrollaron dos sistemas electrnicos y dos softwares de vuelo, uno para cada vehculo.
Se realizaron pruebas para validar el diseo y que dicho diseo fuese capaz de cumplir con las operaciones
de las cuales es responsable durante la misin.

Durante el lanzamiento del CANSAT, solamente el Contenedor completo con xito todas sus
operaciones. Por el contrario, la Carga til fall en la mayora. La razn por la que esto ltimo sucedi es
que el sistema de recoleccin de energa que energiza al sistema electrnico no funcion, por lo que no se
pudo ejecutar el software de vuelo.

I.

INTRODUCCIN

El presente trabajo es una exposicin completa del desarrollo de un sistema electrnico y software de
vuelo para un picosatlite tipo CANSAT que compiti en la Annual CANSAT Competition realizada en
Burkett, Texas del 13 al 15 de julio de 2014. El objetivo de la Annual CANSAT Competition es exponer
a los estudiantes al ciclo de vida del desarrollo de una misin aeroespacial utilizando una metodologa
similar a la aplicada para misiones espaciales reales. Los organizadores de la competicin especifican una
misin a cumplir y una serie de requerimientos operacionales y funcionales.
La Annual CANSAT Competition 2014 consiste bsicamente en simular una carga de sensores
viajando a travs de una atmsfera planetaria muestreando su composicin durante el descenso. El
CANSAT est compuesto por dos componentes principales, una carga cientfica y un contenedor que
protege esta carga durante el ascenso, durante la liberacin del cohete de transporte y el descenso hasta
antes del momento en que la carga cientfica se libera del contenedor.

Para la misin CANSAT2014, es necesario el desarrollo e implementacin exitosa de dos softwares de

Vuelo independientes pero que funcionan en forma conjunta para cumplir la misin. Deben proveer
autonoma en todas sus funciones a los dos vehculos de los cuales est compuesto el CANSAT: un
contenedor, vehculo que sirve como transporte y una carga de experimentacin, que sirve como almacn
de sensores. Por la naturaleza del sistema (un sistema embebido), el diseo y desarrollo de ambas
herramientas de software tiene implicaciones directas tambin en hardware.

Por tanto, la metodologa a seguir es incremental, en la que se identifican los requerimientos mnimos
del sistema en base a la gua de la misin CANSAT2014 y los requerimientos adicionales que permitan un
funcionamiento integrado con los otros mdulos (sensores, comunicacin, control terrestre, despliegue 1 y
2) y se define una arquitectura de hardware junto con una de software, tales que cumplan todos los
requerimientos.

La implementacin de ambas arquitecturas se hizo realizando varias iteraciones en las que el sistema se
mejor para cada iteracin. Para el hardware se realizaron solamente 2 iteraciones de diseo, la ltima de
las cuales result en el diseo del sistema electrnico completo fabricado en China y ensamblado en
Guatemala. Para el software se realizaron ms de 10 iteraciones del software validando su funcionamiento

integrado con los dems mdulos del picosatlite. Se implement el software de vuelo en un
microcontrolador MSP430F5529 de Texas Instruments.

Como resultado de este mdulo se espera la creacin de un software de vuelo capaz de cumplir la
misin CANSAT2014 as como un conjunto de tcnicas y mtodos para el desarrollo de software de vuelo
similares.

El hardware electrnico y software diseados e implementados para el Contenedor permitieron cumplir

con los aspectos de la misin que este vehculo deba cumplir. Para la carga til estos no funcionaron
debido a que el sistema de recoleccin de energa no permiti su operacin al fallar en proveerles
alimentacin elctrica. Se concluye que ambos diseos e implementaciones son capaces de cumplir con las
operaciones asignadas.

II.
A.

OBJETIVOS

Objetivo General

1.

Desarrollar e implementar un Software de Vuelo capaz de darle autonoma de

operaciones a un picosatlite tipo CANSAT que cumpla la misin CANSAT2014.

B.

Objetivos Especficos

1.

Definir, desarrollar e implementar una arquitectura de hardware que permita a

los microcontroladores en los vehculos de vuelo comunicarse con todos los sensores y
dispositivos perifricos a travs de un solo bus, con el dispositivo de comunicacin
XBEE por un bus independiente y con una base o estacin en tierra a travs de un bus
almbrico independiente que permita su monitoreo y otro inalmbrico que permita la
transmisin de telemetra.

2.

Definir, desarrollar e implementar una arquitectura y diagrama de estados de

software que cumpla con los requerimientos mnimos, funcionales y de integracin, y

capaz de proveer de la autonoma requerida a los vehculos de vuelo, mantener las
operaciones del vehculo y tolerar las fallas de energa que se prevn as como reponerse
de las mismas.

3.

Permitir en el software de vuelo dos modos de operacin: un modo de monitoreo

en el que un control en tierra puede tener conocimiento completo de los datos de los
sensores y ejecutar comandos y un modo de vuelo en el que el software acta de forma
completamente autnoma con el objetivo de cumplir la misin.

III.

JUSTIFICACIN

El desarrollo de un software de vuelo para el sistema CANSAT especfico para la misin CANSAT2014 es
necesario ya que el sistema debe ser completamente autnomo en sus funciones como en la toma de
decisiones, debe monitorear variables de su entorno y comunicarlas a una estacin en tierra de forma
determinista y debe cumplir una misin especfica de recopilacin de datos de forma confiable. Adems,
por el hecho de ser un sistema orientado a aplicaciones aeroespaciales, es necesario que el sistema tenga
alguna forma de inteligencia o capacidad de decisin y tener la capacidad de tolerar fallas y recuperarse en
cualquiera de sus subsistemas (incluido el propio software de vuelo) as como reportarse con un control
central, recibir informacin de l y poder modificar el modo en que funciona segn se le comande.
Desarrollar un software que ejecute todas las funciones del sistema mientras vuela (software de vuelo) es la
solucin ms flexible, adaptable, sencilla y confiable.

IV. MARCO TERICO

A.

Qu es un sistema embebido

La definicin de sistema embebido no es del todo clara. Puede definirse un sistema embebido como un
microprocesador utilizado como componente de otra pieza de tecnologa [], no es, por definicin, una
computadora, como una laptop o PC. En contraste, tiene recursos restringidos como una memoria
limitada, un procesador de 8MHz a 48Mhz tpicamente y un bajo consumo de energa comparado con una
computadora tradicional. Asimismo, su respuesta en tiempo real es crtica y debe estar garantizada en
aplicaciones crticas. Interacta con el ambiente a travs de sensores, pantallas, actuadores, etc., y siempre
debe ser confiable. [1].

Otro autor menciona que los sistemas embebidos son diferentes que una sistema de cmputo de escritorio
en formas fundamentales e importantes. Deben cumplir objetivos en tiempo real. Tambin deben cumplir
metas de costo demandantes que restringen la cantidad de hardware de cmputo disponible. Usualmente
controlan la liberacin de energa al ambiente en alguna manera, lo que significa que la seguridad es una
consideracin relevante. Y la gente espera que estn libres de errores de software. [2].

B.

Programacin Orientada a Eventos

La programacin orientada a eventos, tambin conocida como programacin orientada por interrupciones
[3] en el mbito de sistemas embebidos, se refiere a un paradigma o tcnica de programacin en la que el
flujo del programa est dirigido por los eventos [4]. Los eventos son generados en su mayora cuando el
usuario ejecuta alguna accin sobre el sistema, como presionar un botn, tocar una pantalla tctil o conectar
algn otro dispositivo al sistema. Los eventos tambin pueden ser generados por sensores o dispositivos
conectados al sistema (puede ser a travs de interrupciones o a travs de paquetes de datos a travs de una
interfaz fsica). Algunas veces el evento puede ser generado internamente, como un temporizador o una
excepcin de software. Sin importar la fuente o el tipo de evento, la programacin orientada por eventos es
un paradigma en el que el fujo del programa est determinado por los eventos.

La implementacin puede realizarse utilizando cualquier lenguaje de programacin, y para los sistemas
embebidos, C y C++ son opciones frecuentes. Generalmente, estas implementaciones tienen las siguientes
secciones de programa:

1.

Seccin de Captura de Eventos

Esta seccin del programa es responsable de la captura de eventos, hacer un pre-procesamiento

identificar el tipo de evento. Puede suceder en un lugar o estar distribuida en varios manejadores de
interrupcin y el ciclo principal.

2.

Seccin de Despacho de Eventos

La responsabilidad del despacho de eventos es mapear cada evento con su respectivo manejador y llamar
efectivamente a su manejador o servidor. Si no hay un manejador asociado con un evento, el despacho de
eventos ignora el mismo o produce una excepcin.

3.

Seccin de Manejo de Eventos

Los manejadores de evento efectan las actividades relacionadas al mismo; deben ocurrir en el momento en
que sucede el evento.
Muchos programas orientados por eventos no tienen estados, lo que significa que cuando alguna
aplicacin termina de procesar un evento, no es requerido que la aplicacin mantenga el evento anterior.
Sencillamente, cuando el evento ocurre, su respectivo manejador se ejecuta. Es un programa orientado por
eventos sin estados en el que el flujo del mismo no depende de eventos anteriores, sino solo el actual. Por el
contrario, la otra categora de programas orientados a eventos, en los que el flujo del mismo depende no
solo del evento actual sino de los anteriores, se conoce como programa de estados orientado por eventos
[4].
Figura 1. Flujo general de un programa orientado a eventos/interrupciones [4].

C.

CANSAT Competition

La CANSAT Competition es una competencia de diseo construccin lanzamiento que provee a los
equipos la oportunidad de experimentar el ciclo de vida del diseo de un sistema aeroespacial. La
CANSAT Competition est diseada para reflejar un programa aeroespacial tpico en pequea escala e
incluye todos los aspectos de un programa aeroespacial desde una revisin de diseo preliminar hasta una
revisin post-misin. La misin y sus requerimientos son diseados para reflejar varios aspectos de
misiones del mundo real incluyendo requerimientos de telemetra, comunicaciones y operaciones
autnomas. Se evala a cada equipo durante toda la competencia en base a entregables (documentos) del
mundo real tales como planificaciones, presentaciones de revisin de diseo y vuelos de demostracin [5].

D.

Annual CANSAT Competition 2014

La misin 2014 simula una carga de sensores viajando a travs de una atmsfera planetaria
muestreando la composicin atmosfrica durante el descenso.

El sistema CANSAT est compuesto de dos componentes primarios, una carga cientfica y un
contenedor de entrada que protege la carga durante el ascenso, liberacin en el punto mximo y
entrada/descenso inicial.

Una vez que el sistema contenedor/carga alcanza una altura especfica, la carga es liberada del
contenedor para descender de forma lenta y aterrizar de forma segura. Todas las operaciones deben ser
autnomas. La liberacin cerca del punto mximo ocurre a una altura de aproximadamente 670m o ms.
Luego de la liberacin del cohete, el conjunto contenedor-carga deben descender a 12 m/s utilizando
cualquier sistema pasivo de control de descenso. A una altura de 500 m la carga debe ser liberada del
contenedor y descender bajo su propio control para aterrizar de forma segura. El aterrizaje seguro de la
carga til debe cumplirse sin utilizar un paracadas o dispositivo similar para disminuir su rapidez. La
velocidad de descenso de la carga til debe ser de 10m/s o menor. Luego de la liberacin, la rapidez de
descenso del contenedor no debe mantenerse. La carga til enviar telemetra durante el descenso y no
utilizar bateras. Toda la energa debe ser obtenida del ambiente. La carga debe llevar de forma segura un
huevo crudo de gallina, el cual simula instrumentacin delicada.

La telemetra debe ser recolectada a una tasa mnima de 1Hz (una vez por segundo). La carga til debe
transmitir tanta telemetra como sea posible durante el descenso. La telemetra se puede enviar de forma

8
continua o en pulsos rpidos. Una vez que la carga aterrice, la transmisin de datos debe detenerse. Se
otorgarn puntos por cada paquete de datos recolectado desde la liberacin de la carga hasta el aterrizaje.
Los jueces revisaran los datos recolectados y presentados y contaran solamente los datos durante el
descenso activo de la carga.

E.

CANSAT

Un CANSAT es un satlite artificial con una masa entre 0.1kg y 1 kg con las dimensiones de una lata y
funciones muy bsicas. Por estas caractersticas es clasificado tambin como un picosatlite [6].

V.

METODOLOGA

Una caracterstica importante del software desarrollado y cuyo reconocimiento en la etapa de diseo es
fundamental, es que se deba disear e implementar un software para sistema embebido. Esto implica que
el diseo y funcionamiento del software est ntimamente ligado a la seleccin y diseo del hardware que
lo rodea y que le permite cumplir sus funciones. Bajo esta consideracin, se sigui una metodologa de
diseo de software y sistema embebido tomando mtodos de diseo estandarizados en el desarrollo de
software y herramientas de ponderacin objetivas para la seleccin de hardware.

A. Identificacin de Requerimientos de Software de Vuelo

En base al documento en donde se describe la misin CANSAT 2014 [5] se identificaron y extrajeron los
requerimientos que definen la funcionalidad y restricciones del software y hardware a disear para lograr
satisfactoriamente la misma. Estos se presentan a continuacin.

Cuadro 1. Requerimientos de Software de Vuelo

ID

Requirimiento

FSWR-01

El software del container debe monitorear

constantemente la altura del mismo para liberar la
carga til a la altura apropiada.
El software de contenedor debe recolectar y
almacenar datos de altitud a una tasa mnima de
1Hz desde el lanzamiento hasta el aterrizaje. Estos
datos deben ser accesibles para un postprocesamiento.
El software de contenedor debe transmitir datos de
altura a una tasa de 1Hz desde el lanzamiento hasta
el aterrizaje y debe detener la transmisin luego del
aterrizaje.
Durante el descenso, el software de carga til debe
recolectar y almacenar la presin atmosfrica,
temperatura, tiempo de misin, nmero de paquetes
transmitidos, ngulo de descenso y voltaje de la
fuente de energa a una tasa de 1Hz.
Durante el descenso, el software de carga til debe
transmitir toda la telemetra a una tasa de 1Hz.

FSWR-02

FSWR-03

FSWR-04

FSWR-05

Priority

Parent

Fuente

Alta

SYSR-01
SYSR-13

DR

Alta

SYSR-18

CGR-26

Alta

SYSR-18

CGR-27

Alta

SYSR-19

CGR-29

Alta

SYSR-19,
SYSR-20,
SYSR-24

CGR-30

10
FSWR-06

La telemetra de carga til debe inclur tiempo de misin

con resolucin de 1s o mayor, la cual comienza cuando el
payload es encendido. Este tiempo debe preservarse sobre
resets del procesador y puede ser mantenido a travs de un
reloj en software o hardware.
El software de carga til debe mantaner una cuenta de
paquetes transmitidos, la cual debe incrementar con cada
paquete transmitido durante la misin. Dicha cuenta debe
preservarse sobre resets del procesador.

Media

SYSR-24

CGR-31

Alta

SYSR-23

CGR-48

FSWR-08

El software del container debe mantener el tiempo de

misin en segundos desde que es encendido. Este tiempo de
misin debe preservarse sobre resets del procesador y puede
mantenerse a travs de un reloj en software o hardware.

Media

SYSR-24

CGR-49

FSWR-09

Si se usa un reloj de tiempo real en hardware en

cualesqueria de los vehculos (contenedor o carga til),
puede utilizarse una fuente de energa dedicada, pero esta
no puede utilizarse para energizar cualquier otra funcin del
vehculo.
El software de payload debe recolectar datos para calcular
la estabilidad y ngulo de descenso utilizando un
acelermetro de 3 ejes. Este sensor debe muestrearse a una
tasa apropiada y los datos deben almacenarse para una
recuperacin posterior.
El software de Carga til debe organizar la telemetra en
paquetes ASCII y campos separados por coma seguidos por
un retorno de carrete.
Todas las operaciones deben ser autnomas.

Alta

SYSR-16
SYSR-17

CGR-24

Media

FSWR-04

DR

Alta

FSWR-05

DR

Alta

SYSR-01

CGR-MO

Media

FSWR-11

CGR-36

Baja

SYSR-25

DR

FSWR-07

FSWR-10

FSWR-11

FSWR-12
FSWR-13

La Carga til debe tener un conector umbilical externo para

realizar pruebas y chequeos de seguridad mientras no
recolecta energa del ambiente.

FSWR-14

Tanto Contenedor como Carga til deben mantener y

almacenar un indicador del estado actual del software para
recuperarse satisfactoriamente de cualquier evento que
produzca un reset de procesador.

11
FSWR15

El Contenedor debe incluir un conector umbilical

externo para pruebas y chequeos de seguridad.

Baja

FSWR-11

DR

FSWR16

El software de Carga til debe operar en modos de bajo

consumo de energa tanto como sea posible.

Alta

SYSR-16
SYSR-17

DR

B. Diseo de Hardware y Software

1. Definicin de la Arquitectura de Hardware
En base a los requerimientos descritos en la seccin anterior se definieron los elementos que deben
componer al hardware electrnico del sistema embebido a disear y que tienen un efecto directo en el
software a desarrollar. Tambin define el tipo de interconexiones o buses a utilizar para la comunicacin
entre los distintos elementos.

Se definieron arquitecturas de hardware distintas tanto para el Contenedor como para la Carga til. Esto es
necesario ya que este hardware estara integrado en un Sistema Electrnico compuesto de un circuito
impreso que contiene las interconexiones fsicas elctricas entre elementos, los elementos como tales y el
dispositivo de control principal. Cada vehculo debe ser provedo de su propio Sistema Electrnico para
cumplir con sus funciones, por lo que cada vehculo debera tener su propio hardware.

A continuacin se presentan las arquitecturas de hardware desarrolladas. Ambas fueron desarrolladas y

mejoradas en base a:

Los requerimientos de la misin.

Anlisis de las implicaciones de los requerimientos sobre un sistema electrnico que los
cumplira.

Escalabilidad para integrar ms dispositivos sin impacto sobre los otros existentes.

Flexibilidad para aceptar otros tipos de sensores sin modificaciones grandes en el hardware.

Facilidad para cambiar los dispositivos perifricos sin necesidad de modificar el hardware al
momento de hacer prototipos.

Se presenta en un diagrama de bloques interconectados por buses de comunicacin. Las siglas sobre las
lneas y el color de las mismas indican el tipo de bus de comunicacin utilizado y el tipo de seal que viaja
por dichos buses.

12

Figura 2. Arquitectura de Hardware de Contenedor.

Figura 3. Arquitectura de Hardware de Carga til.

13
Se observa de las Figura 2 y Figura 3 que ambas arquitecturas son muy similares. Ambas arquitecturas
fueron desarrolladas de forma independiente. Las razones por las cuales existe esta similitud se derivan del
reglamento de las competencias y decisiones de programacin:

Ambos sistemas tienen operaciones en comn:

o

Mantenimiento del tiempo

Almacenamiento de datos de telemetra

Medicin de altura

Comunicacin inalmbrica a travs del mismo sistema de comunicacin (XBEE).

Conexin externa a PC

Utilizan una arquitectura centrada en un microcontrolador, el cual, para facilitar el desarrollo

de software y, especficamente de drivers para los dispositivos perifricos, se decidi sera el
mismo en ambos sistemas de Contenedor y Carga til. (Los criterios de seleccin del
microcontrolador se discuten ms adelante).

Utilizan los mismos buses de comunicacin.

Los buses de comunicacin estandarizados utilizados son: Inter Integrated Circuit (I 2C o I2C) y UART
(Universal Asynchronous Receiver Transmitter). Otros buses de comunicacin incluyen: PWM (Pulse
Width Modulation) para comunicacin con el servomotor, pines GPIO (General Purpose Input/Output) del
microcontrolador para activar o desactivar el buzzer y, en el caso del hardware de la Carga til, un bus
analgico.

a. Criterios para la seleccin del bus de comunicacin I2C para la comunicacin

de dispositivos perifricos

1) El bus I2C define que cada dispositivo esclavo debe tener una direccin propia
definida a travs de la cual, el dispositivo maestro lo puede direccionar unvoca.
2) Permite velocidades de transmisin de datos lo suficientemente altas para
minimizar el tiempo de transmisin y limitar el consumo de energa.
3) Todos los dispositivos estn conectados al mismo bus de comunicacin, es decir,
a las mismas lneas fsicas, lo cual permite aadir o remover dispositivos a
discrecin sin afectar la comunicacin entre el maestro y los esclavos restantes.
4) Por el criterio anterior (c.), se minimiza el nmero de pines necesarios para
establecer comunicacin con todos los dispositivos a solo 3. Esto tiene impacto

14
directo en facilitar el diseo del circuito impreso y requerir menos espacio en el
mismo, reduciendo as el tamao y el peso del sistema electrnico final.
5) Aunque la programacin de drivers para la comunicacin I2C es ms complicada
que otras alternativas (SPI, UART), la flexibilidad y escalabilidad que se gana
compensa dicha dificultad. Estas dos caractersticas fueron fundamentales para el
desarrollo ya que se contaba con poco tiempo para el mismo.

b. Criterios para la seleccin del bus de comunicacin UART para

comunicacin con XBEE y PC
1) La comunicacin con el mdulo XBEE est restringida a comunicacin serial a
travs de un mdulo de comunicacin UART.
2) La configuracin de este bus de comunicacin es relativamente sencilla y, a
diferencia de otros protocolos (p.ej.: I2C, SPI), no existe complicaciones ms
all de los bits de inicio y terminacin de comunicacin.
3) Existen disponibles en el mercado convertidores de bus serial a USB que
permiten hacer transparente la comunicacin final de datos hacia la PC.
4) Permite configurar varias velocidades de transmisin de datos para adaptarse a
las necesidades de esta aplicacin.

2. Definicin de la Arquitectura de Software

La arquitectura de software presentada a continuacin es el resultado de un proceso iterativo de diseo. El
modelo de capas, la programacin dirigida por eventos (interrupciones), los grficos de llamadas de
funciones y el orden de los procesos son caractersticas del cdigo que se pueden analizar de forma
independiente. Sin embargo, el diseo final de cada una es producto de la forma en que las dems fueron
progresando, con una gran interdependencia en su desarrollo.

a. Diagrama de Estados y condiciones de Transicin: Despus de la definicin de

requerimientos que se desarroll en la seccin V.A Definicin de Requerimientos de Software de Vuelo,
el segundo paso que se sigui fue la creacin de un diagrama de estados y condiciones de transicin para el
software de vuelo de la Carga til y del Contenedor. En esta seccin se presenta y define las principales
caractersticas de los mismos.

15

Los diagramas de estado que se analizan a continuacin son de alto nivel, en el sentido que representan las
acciones que ejecuta el software como elemento de todo el sistema que cumple la misin para la cual es
desarrollado. No se adentra dentro de las operaciones especficas que ejecuta el software ni cmo las hace,
sino las acciones que desarrolla en conjunto con otros mdulos del sistema (elementos mecnicos, sensores,
dispositivos de comunicacin inalmbrica) y el momento y condiciones en que las ejecuta.

Figura 4. Diagrama de Estados y Condiciones de Transicin de la Carga til.

16

Figura 5. Diagrama de Estados y Condiciones de Transicin de la Carga til.

b.

Modelo de Capas del Software: Tanto para la Carga til como el Contenedor

se generaron modelos de software por capas para identificar los componentes de software necesarios en
cada vehculo y la interdependencia entre estos componentes. Es importante entender que los componentes
estn relacionados en el sentido en que los componentes que estn en las capas superiores se construyen a
partir de los que se encuentran en las capas inferiores.

Todos los componentes identificados y desarrollados se pueden clasificar en 3 distintas capas:

Aplicacin: Contiene los componentes que proveen la funcionalidad requerida y algoritmos para
cumplir los requisitos operacionales y funcionales de cada vehculo. Se puede asignar a estos
componentes los requerimientos relacionados al software.

Driver: Son los componentes que proveen funcionalidad relacionada al manejo del hardware a
travs de funciones de software. Es decir, proveen algoritmos de inicializacin y comunicacin

17
con todos los dispositivos perifricos e internos al microcontrolador, as como la generacin de
paquetes de datos.

Configuracin/Fsica: Estos componentes proveen la funcionalidad bsica para la interaccin del

hardware. Los componentes de esta capa son los que generan las seales apropiadas para dicha
interaccin.

A continuacin se presentan dichos modelos de capas:

Figura 6. Modelo de Capas del Software de Carga til.

18

Figura 7. Modelo de Capas del Software de Contenedor.

c. Programacin orientada por Eventos (Interrupciones): Este modelo de

programacin se seleccion con el nico objetivo de poder mantener al microcontrolador en estado SLEEP
la mayor parte del tiempo posible. El microcontrolador es el componente de hardware cuyo consumo de

19
potencia es potencialmente el mayor (con excepcin del dispositivo XBEE). Por tanto, era necesario
considerar que todas las actividades del mismo deben ocurrir tan rpido como sea posible y en el momento
en que fuera necesario, ni antes ni despus. La programacin dirigida por eventos permite cumplir con este
objetivo en el sentido que el microcontrolador se activa s y solo s algn dispositivo perifrico interno o
externo al mismo requiriera procesamiento por parte de l.

Tanto la Carga til como el Contenedor se implementaron bajo este modelo. Solo en la carga til
este modelo era indispensable debido a sus restricciones de energa, sin embargo, result til en el
contenedor, no solo para tener una base comn ms amplia entre ambos softwares y simplificar el
desarrollo individual de cada uno, sino tambin por el hecho de que la potencia requerida por el dispositivo
XBEE era tal que el Contenedor como un todo funcionaba perfectamente durante solo 30 min; pasado este
tiempo se producan errores de transmisin. Si el software no se hubiese implementado bajo este modelo
para el Contenedor, este tiempo podra haberse reducido, poniendo en riesgo el xito de la misin.

Se puede representar, en mquina de estados finitos, la abstraccin de las operaciones principales

ejecutadas por el software de Contenedor y Carga til. Estas operaciones se ejecutan en una secuencia
especfica y lgica, y se realizan al ejecutar un conjunto definido de operaciones que las componen. La
programacin dirigida por eventos se ve reflejada en dos caractersticas importantes en esta
implementacin y que regulan la forman en que se ejecutan estas operaciones:

La transicin entre operaciones principales y entre cada operacin en el conjunto que las
componen, se ejecuta s y solo s ha ocurrido un evento o interrupcin que conduzca a dicha
transicin.

Para que las operaciones se ejecuten en una secuencia especfica y lgica se implement un
conjunto de banderas que indican el inicio o finalizacin de cada operacin.

Lo anterior se puede entender al observar que todos los componentes de la capa de Aplicacin y
Driver de la Carga til y Contenedor (Figura 6 y Figura 7, respectivamente) se implementaron como
pequeas mquinas de estados finitos sencillas. La transicin entre cada accin ocurre solo por
interrupciones y, mientras alguna operacin se inici pero no se ha terminado, la serie de instrucciones
restantes a ejecutar dirige siempre al estado SLEEP, estado del cual saldr solamente cuando ocurra una
interrupcin que indique que la operacin actual ya termin, y as continuar con la siguiente operacin.

La Figura 4 y Figura 5 presentan los diagramas de flujo y condiciones de transiciones que permiten
observar esta caracterstica. En este caso, la abstraccin de las operaciones principales para la Carga til y
Contenedor es la misma.

20

Una de las caractersticas de esta implementacin de software y que posiblemente no se puede

observar de la Figura 4 y Figura 5 es la siguiente: El ciclo principal, en el que se ejecuta las 4 operaciones
principales mostradas, evala cul de todas estas y cuales operaciones del conjunto que compone a cada
una se pueden ejecutar en el ciclo actual. Es decir, en el caso de la operacin Muestreo de Sensores y
Conversin de Datos y Generacin de Paquete, se evala si hay algn sensor por muestrear, si lo hay, se
muestrea el sensor; al mismo tiempo, mientras un sensor es muestreado, el dato muestreado de un sensor
anterior est ya listo para ser convertido al formato ASCII apropiado y se hace dicha conversin. Por tanto,
estas operaciones, aunque no son parte del mismo conjunto, pueden ejecutarse aunque la operacin
principal anterior no haya terminado.
En el caso de la operacin Transmisin de Datos, se implement el software de tal forma que todos
los datos estuviesen listos y el paquete de datos formado antes de que cualquiera fuera enviado. Fue una
decisin tambin esperar a que los datos fueran transmitidos por completo antes de comenzar la operacin
de Almacenamiento de Datos. La razn para esta decisin es que mientras se estn transmitiendo los
datos el consumo de energa del dispositivo XBEE es de 0.33W (100mA @3.3V) durante 23.95ms. El
consumo de energa durante el almacenamiento de datos en la memoria externa seleccionada tambin es
alto (no comparado al del dispositivo XBEE pero s durante ms tiempo: 9mW, 3.3V @3mA durante 2ms).
Ejecutarlas al mismo tiempo podra tener como consecuencia que ninguna de las dos se ejecutara bien, que
hubiese corrupcin de datos, reduccin en la potencia de transmisin en el dispositivo XBEE ya que las
restriccin de potencia fueron bastante grandes para la Carga til, dado que recolectaba toda su energa por
paneles solares poco estables y lejos de ser ideales. Esto podra poner en riesgo cumplir con algunos
requerimientos de la misin, por lo que se decidi que ambas operaciones se ejecutaran una despus de la
otra aunque se pudieran realizar simultneamente.

Asimismo, el orden de las operaciones antes mencionadas fue una decisin durante el desarrollo del
software. La transmisin de datos tiene una puntuacin alta y calificacin en base a cada dato transmitido
(40 pts. en total). El almacenamiento de datos tambin es una operacin crtica ya que permitira evaluar
muchas caractersticas post-vuelo, sin embargo, tiene una puntuacin acumulada menor (30 pts.). Se utiliz
este criterio para decidir que la transmisin de datos se realizara antes, pero no existe ninguna base fuerte
para decir que alguno es ms crtico o crucial que otro, por lo que en el desarrollo final pudo haberse
intercambiado el orden de estas operaciones.

Las decisiones de diseo e implementacin mencionadas en los dos ltimos pasos fueron realizadas
durante las iteraciones y pruebas del software. No se inici con este diseo desde los primeros prototipos de
software sino que, conforme se iba probando individualmente cada operacin, se analizaban todos los

21
factores y consecuencias relacionadas al funcionamiento de todo el sistema electrnico, y los propios
resultados de las pruebas de prototipos de software indicaban que estas decisiones deban tomarse.

Figura 8. Diagrama de flujo y condiciones de transicin del ciclo principal (main) de la Carga til y Contenedor.
Ntese que las operaciones mostradas aqu son las operaciones principales y todas se ejecutas por ocurrencia de un
evento/interrupcin (indicado por la flecha punteada).

En la Figura 9 se ejemplifica el conjunto de operaciones que componen al Muestreo de Sensores de la

Carga til. Esta figura muestra que todos los componentes del Software estn programados por pasos
secuenciales, cada uno de los cuales se ejecuta solo por ocurrencia de alguna interrupcin que provoque la

22
salida del estado SLEEP. Sucede lo mismo en el software del Contenedor, pero las operaciones que
componen al muestreo de sensores son distintas. Sin embargo, se ejecutan de la misma forma, bajo el
mismo concepto.

La Figura 10 ejemplifica el mismo concepto pero para los componentes de bajo nivel que componen al
muestreo del sensor de aceleracin en la Carga til. Se presenta esta figura para proveer mayor claridad en
cuanto a la estructura del software.
Figura 9. Diagrama de flujo y condiciones de transicin para la operacin principal Muestreo de Sensores de la Carga
til.

23

Figura 10. Diagrama de flujo y condiciones de transicin para la operacin de muestreo del sensor de aceleracin.

24

En la Figura 10 se muestran las operaciones que implica muestrear el sensor de aceleracin. Se ha

representado las operaciones como funciones con parmetros para hacer explcito el hecho que estas
operaciones individuales son componentes de la capa Driver (en este caso del software de Carga til). Por
ejemplo, la operacin de la Figura 10 transmisinI2C(Direccin de Sensor, Registros de Muestra)
representa a la accin de transmitir hacia el sensor cuya direccin se enva como parmetro la direccin de
los registros de su memoria interna, que tambin se envan como parmetro, para ser preparados y ledos en
el prximo intercambio I2C.

Es importante mencionar que la implementacin del diagrama de flujo y algoritmo presentado en la

Figura 10 se hizo utilizando la estructura switch-case. Una interrupcin inicial permite la entrada a esta
serie de pasos, internamente se decide qu paso se debe ejecutar y se finaliza la ejecucin al terminar cada
paso. Se regresa a evaluar el siguiente paso a ejecutar solo cuando el paso anterior ya se termin de ejecutar
y el hardware lo indica con una bandera de interrupcin.
Todas las operaciones, con excepcin de las rutinas de inicializacin de los perifricos internos del
microcontrolador y sensores, fueron diseadas e implementadas bajo los conceptos mencionados

25
anteriormente. La consecuencia de esto se resume en que la implementacin est orientada por
eventos/interrupciones y explica una gran parte de la forma en que se desarroll, estructur e implement el
software de ambos vehculos.

d.

Grficos de llamadas de funciones:

La interrelacin de las funciones expuesta en la Figura 8, Figura 9 y Figura 10 permite tener una
buena idea general de cmo dependen los componentes del software unos de otros. Los grficos de
llamadas son una vista ms explcita y detallada de estas relaciones. En el caso de esta implementacin de
software, se desarrollaron estos grficos en la etapa de diseo y modificaron y mejoraron durante el proceso
de pruebas para llegar a la estructura de software ms ptima. El desarrollo de los grficos de llamadas de
funciones y el modelo de capas del software tuvieron gran interdependencia y los cambios en uno se
reflejan automticamente en el otro.

A continuacin se presenta una breve explicacin de cada una de las funciones y los grficos de
llamadas de funciones de las funciones principales desarrollada. Las funciones que se omiten no hacen
llamadas a funciones y son llamadas por otras o ejecutan funciones de inicializacin que no forman parte de
las funciones principales para las que fue diseado el software.

Figura 11. Grfico de llamadas de funciones de la operacin de muestreo de sensor de aceleracin.

Figura 12. Grfico de llamadas de funciones de la operacin de muestreo de sensor de voltaje.

Figura 13. Grfico de llamadas de funciones de la operacin configuracin de sensor de aceleracin.

26

Figura 14. Grfico de llamadas de funciones de la operacin de muestreo de sensor de temperatura.

Figura 15. Grfico de llamadas de funciones de la operacin de muestreo de sensor de presin.

Figura 16. Grfico de llamadas de funciones de la operacin de almacenamiento de paquetes de datos en memoria
externa.

Figura 17. Grfico de llamadas de funciones de la operacin de recuperacin de cuenta de nmero de paquetes.

Figura 18. Grfico de llamadas de funciones de la operacin de borrado de memoria externa.

27

Figura 19. Grfico de llamadas de funciones del ciclo de ejecucin principal.

28

29

e.

Herramientas seleccionadas para la

implementacin del software:

Las herramientas que fue necesario seleccionar para la implementacin del software son: lenguaje de
programacin, editor, compilador y debugger, plataforma de pruebas y herramienta de documentacin. A
continuacin se expone la eleccin realizada para cada una de estas herramientas y las razones por las
cuales se eligieron.

1)

Lenguaje de Programacin: C estndar 1999 (C99).

Se decidi utilizar este lenguaje de programacin por las siguientes razones:

El microcontrolador seleccionado MSP430F5529 de Texas Instruments- tiene

un conjunto de instrucciones optimizado para trabajar bajo este lenguaje.

Es el lenguaje de programacin recomendado por el fabricante para el

microcontrolador sobre el cual se ejecuta el software.

Existen una gran cantidad de opciones de compiladores para este lenguaje y

microcontrolador seleccionado.

Existe familiaridad previa del desarrollador con este lenguaje.

Provee la flexibilidad y abstraccin suficiente y requerida para desarrollar la

aplicacin con suficiente control de las operaciones internas del microcontrolador

sin necesidad de utilizar el lenguaje ensamblador del mismo.

Existe documentacin amplia para este lenguaje y microcontrolador. Esto

incluye ejemplos de cdigo, implementaciones reales, notas de aplicacin y ayuda

en lnea que pueden simplificar el desarrollo y proveer apoyo en la solucin de
problemas.

2)

Editor: Sublime Text 2.0.

Se decidi utilizar el editor de texto/cdigo Sublime Text 2.0 por las siguientes razones:

Provee una interfaz y estilos amigables con el usuario. Esta caracterstica es

importante ya que es el ambiente con el que el desarrollador se enfrenta

constantemente para desarrollar el cdigo.

30

Tiene caractersticas que facilitan la digitacin del cdigo como: resaltado de

texto, reemplazo de texto flexible, autocompletacin de cdigo, autocompletacin

de parmetros y teclas y combinaciones de acceso rpido que facilitan la digitacin
de operaciones que se hacen frecuentemente.

Es un software que se puede utilizar sin lmite y gratuitamente durante un

tiempo indefinido, aunque tambin se solicita una paga por el mismo.

3)

Compilador y Debugger: IAR Embedded Workbench for

MPS430 v5.6.

Se eligi el software IAR EW430 v5.6 por las siguientes razones:

Es recomendado por el fabricante del microcontrolador.

Tanto el compilador como el debugger estn optimizados para la familia

MSP430.

Existe familiaridad previa del desarrollador con el uso e interfaz de esta

herramienta. De esta forma se acorta la curva de aprendizaje de la misma.

Esta herramienta incluye un editor pero solo se utiliz al momento de hacer

depuraciones de cdigo.

4)

Plataforma de Pruebas: MSP430F5529 Launchpad Evaluation

Kit.

Texas Instruments desarrolla y distribuye plataformas para la evaluacin de sus microcontroladores

(adems de la amplia gama de productos que ofrece). En este caso se eligi esta herramienta por las
siguientes razones.

Es fundamental contar con una herramienta flexible y fcil de utilizar desde el

inicio para probar el cdigo de inicializacin. Esto provee un marco de software

para iniciar rpidamente el desarrollo. El MSP430F5529 Launchpad provee el
hardware para que este paso sea sencillo.

Incluye un programador y debugger integrados, lo cual se traduce en ahorro en

costo y facilidad de uso de la herramienta ya que est integrada.

El programador y debugger se pueden utilizar en otro microcontrolador objetivo.

Esto

significa

que

estas

dos

herramientas

pueden

desconectarse

del

31
microcontrolador includo en el Launchpad y conectarse a uno externo, lo cual es
tambin fundamental ya que se dise un hardware a medida para el picosatlite.

Su precio es reducido ($12.99).

32

f.

Principales Algoritmos

A continuacin se presentan los algoritmos de mayor relevancia para cada vehculo y la misin a
cumplir.
Figura 20. Diagrama de flujo del algoritmo implementado para la liberacin de la carga til.

33
La Figura 20 presenta el diagrama de flujo del algoritmo implementado para la liberacin de la carga
til como parte del software del contenedor. Este algoritmo inicia con la inicializacin de variables, y
especficamente con la inicializacin de la variable Release_Point asignndole un valor de cero. Esta
variable mantiene un conteo de la cantidad de veces que el contenedor ha pasado por el punto en el que se
debe liberar la Carga til. Inicialmente todo el picosatlite (y tambin la Carga til) se encuentran a nivel
del suelo en el momento del lanzamiento, por lo que se inicializa con valor cero. Se mantiene con dicho
valor mientras el picosatlite no haya llegado o sobrepasado el punto de liberacin. La presin atmosfrica
desciende conforme la altura sobre el nivel del mar aumenta, por lo que cuando la altura del picosatlite es
mayor a la altura de liberacin, la presin atmosfrica es menor a la presin de liberacin, y se indica
actualizando la variable Release_Point asignndole valor de 1 (Release_Point = 1).

Conforme el picosatlite sigue su ascenso y llega a su altura mxima, la presin atmosfrica sigue
siendo menor a la presin del punto de liberacin. Ahora debe compararse que la presin atmosfrica sea
mayor al punto de liberacin. El picosatlite ya ha sido liberado del cohete en este momento. Tan pronto
como la presin atmosfrica sea mayor a la presin del punto de liberacin, se libera la Carga til del
Contenedor y se ha completado esta fase. Esto se indica asignando a la variable Release_Point el
valor 2 (Release_Point = 2).

Figura 21. Diagrama grfica del vuelo y de los puntos en que se verifica el estado de vuelo del picosatlite.

34

Figura 22. Diagrama de flujo del algoritmo implementado para muestrear el sensor de presin LPS331AP del
Contenedor.

35
La Figura 22 muestra el diagrama de flujo de algoritmo programado para muestrear el sensor de
presin. Este algoritmo es especificado en la hoja de datos del sensor. La implementacin del mismo es
relativamente sencilla y los datos se obtienen sin complicaciones.
Figura 23. Diagrama de flujo del algoritmo implementado para muestrear el sensor de aceleracin ADXL345 de la
Carga til.

El algoritmo implementado para el muestreo del sensor de aceleracin se muestra en la Figura 23. El
ltimo paso de separacin de bytes y determinacin de las aceleraciones individuales X, Y y Z se hace a
travs de corrimiento de bytes y el uso de mscaras para eliminar bits. Los pasos anteriores son definidos
en la hoja de datos del sensor y solo es necesario implementarlos en el software.

36

Figura 24. Diagrama de flujo del algoritmo implementado para muestrear el sensor de presin BMP085de la Carga
til.

La Figura 24 muestra el diagrama de flujo del algoritmo implementado para el muestreo del sensor de
presin. Al igual que para el muestreo del sensor de aceleracin mostrado en la Figura 23, en este
algoritmo la obtencin del valor final de presin se realiza utilizando corrimiento de bytes y mscaras.
Todos los dems pasos son especificados en la hoja de datos del sensor.

37

Figura 25. Diagrama de flujo del algoritmo implementado para muestrear el sensor de temperatura BMP085de la Carga
til.

En la Figura 24 y Figura 25 se presentan los algoritmos para muestrear el sensor de presin y

temperatura de la Carga til. Como se observa en el diagrama esquemtico de la Carga til en la seccin
XI. Anexos, este es un solo sensor que provee ambos datos: el sensor BMP085.

38

3.

Seleccin del Microcontrolador

El microcontrolador es la parte principal de todo el sistema electrnico y acta como unidad central de
procesamiento en la Carga til y el Contenedor. La seleccin del mismo est influenciada por necesidades
de hardware y software, y sus caractersticas tienen consecuencias en la forma en que el hardware y
software se disean y desarrollan en el proceso iterativo. En esta implementacin, existieron ms
requerimientos de hardware, en comparacin con los de software, y que influenciaron la seleccin del
mismo. A continuacin se exponen junto a una breve explicacin de su importancia e impacto.

Bajo consumo de energa: En el caso de la Carga til, todos los elementos electrnicos se

deban seleccionar bajo una restriccin de energa muy grande. Para garantizar que el sistema
funcionara bajo las condiciones ms difciles de recoleccin de energa, el microcontrolador a
utilizar deba trabajar en estado activo con una potencia mnima y tener estados de bajo
consumo de energa sobresalientes.

Interfaces de Hardware: En este respecto era necesario que el microcontrolador poseyera

dos mdulos de comunicacin serial, un mdulo de comunicacin I2C y un mdulo de

comunicacin SPI, un Convertidor Analgico a Digital y la capacidad de operar sin una fuente
de reloj externa. Estos requerimientos mnimos fueron establecidos cuando se disearon las
arquitecturas (Figura 2 y Figura 3).

Tamao/Variedad de Empaquetados: El espacio disponible para el sistema electrnico

dentro del picosatlite era suficiente, pero estaba restringido durante todo el diseo, a la forma
y posicionamiento del dispositivo XBEE y sensores, los cuales ocupan un rea total
considerable. Adems, el ensamblaje de todos los dispositivos electrnicos se hara a mano,
por lo que era necesario que el empaquetado tuviera pines y fuera sencillo de soldar con un
cautn y estao normales.

Facilidad de Programacin: Este requerimiento es muy subjetivo. En este caso se refiere a

la popularidad del dispositivo a utilizar, la sencillez de la arquitectura, la disponibilidad de

documentacin y la existencia de herramientas que no requieren de mucha experiencia por
parte del desarrollador como prueba de la facilidad para programar.

Memoria interna: En la etapa de diseo inicial no era seguro si se utilizara la memoria

interna del microcontrolador como medio para almacenar toda la telemetra o si se utilizara

39
una memoria externa. Adems el tamao del cdigo podra superar los 10KB por lo que era
necesario una memoria interna de programacin de un tamao similar.

A continuacin se presenta el estudio realizado para la seleccin del microcontrolador. Despus de una
etapa de investigacin se estudiaron tres alternativas distintas de forma objetiva. Estas alternativas fueron:
MSP430F5529 de Texas Instruments, RX100 de Renesas y EFM32 Gecko de Silicon Laboratories.

Cuadro 2. Ponderacin de los criterios utilizados para la seleccin de microcontrolador.

Pondera Ponderacin de Criterios

Variable

Peso (0 - 4)

Consumo de energa

Tamao

Facilidad de Programacin

Memoria Interna

40

Cuadro 3. Valores normalizados de las variables evaluadas para la seleccin del microcontrolador.

Valores Normalizados de Criterios evaludos

Criterios

Consumo
de energa

>200uA/MHz
en Modo Activo
y >= 1uA en
Modo Sleep.

Alto
consumo de
potencia en
modo Activo
pero bajo en
modo Sleep

Bajo consumo en
modo Activo pero
relativamente alto
en modo Sleep.

<=
100uA/MHz
en Modo
Activo y
<=1uA in
Modo Sleep

Tan grande
como para
implicar un
compromiso
entre espacio y
tamao.

Apenas se
puede
acomodar en
el espacio
disponible.

Se puede
acomodar en el
espacio disponible
sin problemas.

Tan pequeo
que su
posicionami
ento es un
problema
menor.
Se puede
programar
por mtodos
similares a
los sistemas
arduino.

Tamao

Facilidad
de
Programa
cin

Memoria
Interna

No existe
documentacin
disponible.

Documen
tacin
obscura.

0 KB

2KB

Amplia
documenta
cin
disponible
en lnea.
5KB

16KB

Cuadro 4. Ponderacin de los criterios utilizados para la seleccin de microcontrolador.

Estudio Normalizado de Criterios

MSP430F5529
Normalized Total
10
10
9
10

40
30
27
10
107

EFM32 Gecko
Normalized
Total
8
10
6
10

32
30
18
10
90

RX100
Normalized Total
8
10
3
10

32
30
9
10

81

10

>=32KB

41

4. Implementacin de la Arquitectura de Hardware

Se desarrollaron varios prototipos del hardware diseado. Estos prototipos incluyen circuitos impresos
de los sensores que se probaron, el dispositivo de comunicacin inalmbrica, los circuitos de alimentacin
y del sistema electrnico integrado. A continuacin se presentan el desarrollo e implementacin del
hardware del sistema electrnico integrado y detalles especficos de los circuitos de alimentacin, el
microcontrolador y

la memoria externa. Detalles de otros circuitos se presentan en los trabajos

desarrollados respecto a dichos mdulos.

42

Figura 26. Diagrama esquemtico Rev. 2 (Final) del circuito de funcionamiento del microcontrolador para la Carga
til.

43

La

44

Figura 26 muestra al microcontrolador y los elementos pasivos que permiten su funcionamiento.

Muchos de estos elementos no se utilizaron en el diseo final pero se consideraron como parte del circuito
para ofrecer flexibilidad al mismo y evitar la necesidad de un rediseo del circuito impreso en caso hubiera
necesidad de colocar un componente que no se consider antes. Un ejemplo son los cristales externos que
sirven como fuentes de reloj para el microcontrolador. Ninguno de ellos se utiliz, sin embargo exista la
posibilidad de necesitar una fuente de reloj mayor a la que el microcontrolador podra generar. Por tanto, se
dise bajo esta consideracin.

Los LEDs mostrados (LED0, LED1, LED2) tiene como propsito ser indicadores de que el Sistema se
encuentra encendido y servir como forma de depurar el programa visualmente. Asimismo, se consider
colocar conectores externos hacia los pines de programacin y alimentacin del microcontrolador, para
permitir la reprogramacin del mismo, una tarea bsica que se realizaba constantemente durante el
desarrollo del software.

El Contenedor tiene un diagrama muy similar: las nicas diferencias son los pines a los cuales estn
conectados los LEDs y otras salidas. Este diagrama no se presentar, pero se encuentra en la seccin XI.
Anexos.

45

Figura 27. Diagrama esquemtico del circuito de conexin del cable para monitoreo/prueba.

46

47
El circuito presentado en la Figura 27 corresponde a la conexin para monitoreo/prueba que tambin
puede alimentar a todo el sistema electrnico de Carga til o Contenedor. Cada uno de dichos vehculos
posee un sistema idntico. Este circuito es capaz de conmutar entre la conexin por el conector USB o una
batera externa para alimentar a todo el circuito. Adems permite recargar la batera externa mientras est
conectada una fuente de alimentacin por el conector USB.

Esto circuito le dio mucha versatilidad al desarrollo y facilit las pruebas de todo el hardware del
sistema electrnico. En una buena parte de las pruebas realizadas en los sistemas electrnicos, se deseaba
validar el funcionamiento de sistemas distintos a la fuente de energa real, por lo que la flexibilidad de este
circuito fue un factor fundamental.

48
Figura 28. Diagrama esquemtico del circuito recolector de energa de paneles solares y regulador de voltaje.

Figura 29. Diagrama esquemtico del circuito de conexin de memoria externa 24AA128.

49

La Figura 28 muestra el circuito diseado e implementado para la obtencin de la energa de los paneles
solares y su regulacin a un voltaje de 3.3V. El diseo de este circuito se bas en el circuito integrado
LTC3105 de Linear Technologies. Este circuito integrado es un regulador de voltaje DC-DC con una
corriente de salida de hasta 400mA y voltajes de entrada de 250mV. Las caractersticas de este componente
que fueron criterio de su seleccin fueron el voltaje de arranque de regulacin tan bajo como 450mV, fcil
ajuste del voltaje de salida a 3.3V, corriente de salida mayor de hasta 400mA (segn las condiciones del
voltaje de entrada) y principalmente control del punto de mxima entrega de potencia. El circuito integrado
fue diseado para uso especfico con paneles solares, y la ltima caracterstica mencionada permite obtener
la mayor energa posible de los mismos. En pocas palabras, el circuito integrado ajusta su impedancia de
entrada para coincidir con la impedancia de salida de los paneles, obteniendo as la mxima entrega de
potencia.

La Figura 29 muestra el circuito implementado para operar y comunicarse con la memoria externa. Esta
memoria es tipo EEPROM con 16KB de almacenamiento (128Kbit = 16K x 8bit). La interfaz de
comunicacin con el microcontrolador es sencilla y no requiere componentes externos adicionales. Esta
memoria y circuitos se utilizaron tanto para Contenedor como Carga til.

50

Figura 30. Diagrama esquemtico del driver del servomotor utilizado para la liberacin de la Carga til del
Contenedor.

La Figura 30 presenta el circuito driver del Servomotor de Contenedor para la liberacin de la Carga
til. Este circuito no es ms que una interfaz para proteger al microcontrolador de cualquier pico de voltaje
proveniente del servomotor. La seal de control utilizada es una seal PWM que cumple con las
restricciones de uso con el servomotor utilizado.

Figura 31. Diagrama esquemtico del circuito de alimentacin de Servomotor.

51

Figura 32. Diagrama esquemtico del circuito de alimentacin del sistema electrnico a bordo del Contenedor.

La Figura 31 muestra el circuito de alimentacin diseado para generar el nivel de voltaje y corriente
necesarios para el funcionamiento del servomotor. Este circuito est basado en el regulador de voltaje DCDC de subida (step-up, boost) LM2623 de Texas Instruments. Solo requiere ciertos elementos pasivos cuya
seleccin es sencilla pero debe ser cuidadosa. Este circuito era crtico en su diseo, ya que junto con el
servomotor, el software y sensor de presin, permite la liberacin de la carga til. Si este circuito no era
capaz de soportar la carga elctrica que representa el motor, este posiblemente no sera capaz de moverse
para liberar la Carga til. Se sobredimension sus requerimientos para asegurar que el sistema fuera
robusto. Finalmente el circuito funcion sin ningn problema satisfaciendo todos los requerimientos y
restricciones que su operacin implicaba.

52

La Figura 32 muestra el circuito diseado para regular el nivel de voltaje a 3.3V y alimentar a la
mayora de componentes electrnicos a bordo del Contenedor en el sistema electrnico. Este circuito est
basado en el circuito integrado TPS61201 de Texas Instruments, un regulador de voltaje DC-DC de subida
(step-up, boost) con voltaje de salida nico de 3.3V.

Figura 33. Primer prototipo del circuito impreso del Sistema Electrnico integrado de la Carga til. Izquierda: Vista
Trasera. Derecha: Vista Frontal y antena de XBEE.

Figura 34. Diseo y presentacin preliminar 3D del circuito impreso del Sistema Electrnico integrado de la Carga
til. Izquierda: Vista Trasera. Derecha: Vista Frontal y antena de XBEE.

53

Figura 35. Versin final del circuito impreso del Sistema Electrnico Integrado de la Carga til. Izquierda: Vista
Trasera. Derecha: Vista Frontal y antena de XBEE.

En la Figura 33, Figura 34 y

Figura 35 se muestran los prototipos y diseo y versin final del Sistema Electrnico Integrado de la
Carga til. El primer prototipo (Figura 33) se utiliz extensamente para probar distintas combinaciones de
hardware bajo la misma arquitectura y validar el funcionamiento bsico de la plataforma diseada. Esto
sirvi como marco para continuar y hacer las mejoras y modificaciones necesarias al sistema electrnico
integrado tomando los resultados de las pruebas de la interaccin de los dispositivos electrnicos y de las
pruebas de funcionamiento integrado de todo el picosatlite.

El diseo de los circuitos en un diagrama esquemtico y el diseo del circuito impreso final se
realizaron utilizando el software de captura de circuitos Altium Designer 13.1. De esta forma se generaron
las vistas 3D de la posible vista final del Sistema Electrnico presentadas en la Figura 34. Las vistas
tridimensionales jugaron un papel importante en el diseo, ya que permitieron validar que no hubiese
interferencias entre componentes y que se mantuviera el espacio ocupado dentro de las dimensiones
mximas disponibles. De las misma forma, permite tener una idea clara del aspecto fsica final del sistema

54
electrnico y la posicin de cada componente, para poder observar otras restricciones de posicin de
algunos componentes y la compatibilidad del diseo con toda la estructura que lo soporta, contiene y
protege.

La
Figura 35 muestra el Sistema Electrnico final para la Carga til. Se puede comparar con la Figura 34.
Para la realizacin de los circuitos impresos se export archivos Gerber y Drill del diseo de los mismos, y
se contrat los servicios de la empresa china Smart-Prototyping para hacer 10 placas, con un valor total de
$11.90 (sin envo). Se sigui este procedimiento tanto la Carga til como para el Contenedor. Para el
contenedor el precio de 10 placas fue de $60.40 debido a que sus dimensiones eran mayores. Ambos juegos
de placas se hicieron bajo las siguientes indicaciones:

Dos capas de cobre

Grosor de placa: 1mm

Espesor de Cobre: 1oz

Acabado Superficial: HASL (Hot Air Solder Leveling)

Color de Pelcula de Soldadura: Verde

Electrical Test: 100%

Plantilla para pasta para soldar: No

El diagrama esquemtico completo del sistema electrnico de Contenedor y Carga til se puede encontrar
en la seccin XI. Anexos.

C. Pruebas
Las pruebas realizadas al software se dividieron en los siguientes conjuntos: integracin de sensores y
software de vuelo, integracin del sistema de comunicacin inalmbrica XBEE y software de vuelo,
Integracin de datos entre estacin en tierra y software de vuelo, pruebas del sistema electrnico integrado
y pruebas del picosatlite en condiciones reales.

1. Integracin del sistema de sensores y software de vuelo

Al momento de desarrollar los algoritmos para que el software de vuelo muestreara cada sensor, se
prob distintos aspectos como la integridad de las seales en el bus de comunicaciones, consideraciones de
tiempo entre cada comando y/o recepcin de datos, cumplimiento del protocolo de comunicacin (I2C,

55
Serial), manejo de configuraciones de sensores y conversin correcta de los datos obtenidos al formato
apropiado para su posterior envo al dispositivo XBEE.
Adems se realizaron pruebas para verificar que los datos proporcionados por los sensores fueran
coherentes con las variables fsicas que medan, pero estas pruebas no son parte de las verificaciones del
software sino de los sensores. Por tanto no se tratan aqu.
A continuacin se muestra imgenes capturadas utilizando un osciloscopio para la verificacin de la
integridad de seales y que se cumplieran las reglas que cada protocolo impone, adems de las dems
verificaciones mencionadas.

Figura 36. Anlisis del intercambio de datos a travs del bus I2C entre el sensor BMP085 y el microcontrolador. Arriba
se presenta el bus utilizando un analizador lgico. Abajo se muestra la seal el bus utilizando un osciloscopio. El bus
est compuesto por una lnea de datos, y una lnea de reloj.

2. Integracin del sistema de comunicacin inalmbrica XBEE y software de

vuelo
La comunicacin con el dispositivo XBEE se realiz a travs de comunicacin serial (definido en la
arquitectura de hardware). Para asegurar que la interaccin entre el dispositivo XBEE y el software fuera
la correc ta, se realiz pruebas en las que se midi la integridad de las seales involucradas, el
cumplimiento con las velocidades de transmisin para las cuales estaban configurados tanto el XBEE como
el microcontrolador y que los datos transmitidos cumplieran siempre con el formato establecido para la
comunicacin entre ellos.

56
Figura 37. Anlisis de la integridad y datos de la seal serial entre el software de vuelo y el dispositivo XBE. Arriba se
muestra la seal de acknowledge utilizada OK/n decodificada utilizando un analizador lgico. Abajo la misma seal
analizado utilizando un osciloscopio para verificar su forma y niveles de voltaje.

3. Integracin de datos entre estacin en tierra y software de vuelo

La definicin del formato para la transmisin de datos implica un acuerdo entre el dispositivo transmisor y
el receptor. Si bien, a nivel fsico, el dispositivo transmisor y receptor es el XBEE del picosatlite y de la
estacin en tierra, respectivamente, a nivel lgico el transmisor era el software de vuelo y el receptor la
estacin en tierra. Estas pruebas eran crticas para asegurar que los datos transmitidos podran ser
interpretados correctamente siempre por la estacin en tierra.

En la Figura 38 se presenta una captura de la secuencia de las seales fsicas que codifican los datos
enviados a travs del dispositivo XBEE a la estacin en tierra. En la Figura 39 se observa una grfica de los

57
datos presentados en la Figura 38 realizada por la estacin en tierra. Esta prueba permiti confirmar que los
paquetes de datos se codificaron, transmitieron y decodificaron de forma satisfactoria.

Figura 38. Evolucin en el tiempo de la seal enviada al dispositivo XBEE.

Figura 39. Graficas de aceleracin generadas por la estacin en tierra. La generacin de estas grficas implica un
funcionamiento integrado correcto.

58

4. Pruebas del sistema electrnico integrado

Estas pruebas implicaron realizar pruebas de sensores y dispositivos de comunicacin inalmbrica
interactuando simultneamente con el microcontrolador y el software. Se conectaron los sensores al bus
I2C y el mdulo XBEE al bus UART para analizar la interaccin completa entre software y hardware y el
flujo de las operaciones, como un sistema electrnico completo y no como mdulos individuales. Estas
pruebas se realizaron inicialmente en un banco de pruebas con el sistema electrnico esttico y alimentado
por fuentes de alimentacin de laboratorio. Esto permiti comprobar funcionalidades bsicas como la
comunicacin entre dispositivos, que el software se ejecutar correctamente bajo condiciones controladas
(temperatura constante, presin constante, sin movimiento). Se realizaron aproximadamente 40 pruebas
completas del sistema integrado en el lapso de 45 das y se realizaban las modificaciones y mejoras
correspondientes Asimismo, se realizaron pruebas bajo las condiciones reales como elementos montados
sobre el mismo circuito impreso y por las fuentes de alimentacin que se utilizara en el diseo final del
sistema electrnico. Se realizaron dejando caer al sistema electrnico desde alturas de 10m hasta 50m. Se
realizaron alrededor de 30 pruebas en el lapso de 45 das. Estas pruebas proveyeron datos sobre cmo las
seales fsicas y dispositivos interactan entre s como parte de un solo sistema, problemas de ruido entre
los dispositivos, desempeo de las fuentes de alimentacin y una visualizacin ms de todo el sistema
integrado.

59

5. Medicin del impacto de la programacin orientada por eventos sobre las

caractersticas de consumo de energa del sistema.
Esta prueba se realiz con el objetivo de medir el impacto y evaluar las ventajas de la implementacin
del software utilizando programacin orientada por eventos. Las pruebas no se realizaron sobre el sistema
electrnico y software del CanSat en s, sino que sobre la plataforma de pruebas Launchpad for
MSP430F5529- la cual contiene le mismo microcontrolador y utilizando otra versin del software que
realizaba las mismas operaciones bajo las mismas condiciones, pero codificado de tal forma que fuera fcil
habilitar o deshabilitar las interrupciones generadas y la entrada del microcontrolador a modo de bajo
consumo. Estas dos ltimas caractersticas interrupciones y modo de bajo consumo- son las que
finalmente permiten al sistema consumir menos energa, o no. A pesar de no utilizar exactamente el mismo
software y hardware, s se puede trasladar los resultados ya que el hardware para la prueba fue muy similar
mismo microcontrolador, sensores, dispositivos de transmisin- y el software tambin misma secuencia
de operaciones, muestreo, paquetizacin, almacenamiento, etc.-.

Por tanto, se realiz un experimento para determinar si existe una diferencia significativa en consumo
de energa y tiempo de funcionamiento la ejecucin de software en un microcontrolador en dos formas de
ejecucin del software: una orientada por eventos que se caracteriza por que el procesador del
microcontrolador se mantiene en modo de bajo consumo de energa durante el mximo tiempo posible en
cada ciclo de operacin, y otro en el que el procesador no se mantiene en modo de bajo consumo de
energa. En cada forma de ejecucin, el microcontrolador realiza exactamente las mismas tareas, est
adaptado al mismo hardware y utiliza de la misma forma los dispositivos perifricos y mdulos internos. La
nica diferencia es efectivamente, el uso o no del modo de bajo consumo de energa.

La importancia de la realizacin de este anlisis radica en que el desarrollo de software orientado a

eventos requiere una programacin ms compleja, que requiere una coordinacin, sincronizacin y
comunicacin compleja entre eventos y acciones para lograr el desarrollo de todas las operaciones de la
forma deseada. Esto regularmente implica mayores tiempos de programacin y ms tiempo de depuracin,
as como mayor probabilidad de errores en el cdigo, pero su beneficio es que se reduce la potencia
requerida para el funcionamiento del microcontrolador y se extiende el tiempo de funcionamiento.

Por el contrario, una programacin en la que el flujo de eventos no est dirigido por eventos, sino que
est determinada por el propio programada (determinista) es ms sencilla. No requiere de coordinacin,
sincronizacin ni comunicacin compleja entre eventos y acciones y es ms fcil de desarrollar ya que el

60
flujo de todo el programa est definido por completo por el diseador. Sin embargo, puede resultar en un
consumo de energa innecesario que puede provocar un tiempo de funcionamiento reducido.

El anlisis fue llevado a cabo utilizando un capacitor de 1F como fuente de alimentacin del sistema, y
analizando el perfil de descarga, potencia requerida, tiempo de funcionamiento y nmero de paquetes
generados por el Dispositivo bajo Prueba DUT- (por sus siglas en ingls). El diagrama esquemtico del
circuito de pruebas se presenta la Figura 40.

Figura 40. Diagrama esquemtico para el anlisis de consumo de energa.

Se realizaron 2 sub-experimentos: Experimentos A y B; en ambos se analiz las caractersticas de

consumo de energa del sistema utilizando el software orientado por eventos y sin este programacin, es
decir, programacin lineal sin interrupciones ni estados de bajo consumo.

Especficamente, las

caractersticas de energa analizadas fueron: perfil de descarga, potencia requerida, tiempo de

funcionamiento y nmero de paquetes generados.

El primero experimento, Experimento A, consisti en alimentar al sistema con el supercapacitor hasta

que se descargara a un voltaje de 2.6V al energizar al DUT. El segundo experimento, Experimento B,
consisti en alimentar al sistema con el mismo capacitor pero hasta que el primero comenzara a transmitir
datos con errores, lo cual se determin de forma visual analizando los datos en la consola de una
computadora conectada al sistema.

En el Cuadro 5 y Cuadro 6, se muestran los resultados de ambos experimentos. Esto resultados se

pueden comparar para el modo de bajo consumo, el cual efectivamente utilizada programacin orientada
por eventos, y el modo normal. Se realizaron dos pruebas en cada modo para cada experimento.

61

Cuadro 5. Resultados del experimento A realizado hasta un voltaje de 2.6V. Se muestra el tiempo de funcionamiento,
paquetes enviados y potencia requerida para ambos modos de operacin en dos pruebas realizadas en cada modo.
Modo de operacin
Normal
Prueba
1
156

Prueba 2

Paquetes

Modo de Bajo
Consumo
Habilitado
Prueba
Prueba
1
2
642
544

Tiempo (s)

316

266

78

78

Vinicial {V}

3.286

3.28

3.28

3.28

Vfinal {V}

2.6

2.6

2.6

2.6

Energia
Consumida {J}
Potencia
Consumida
(Promedio) {W}

2.018

1.99

1.99

1.99

0.00638

0.00751

0.0256

0.0256

Parmetro

156

Cuadro 6. Resultados del experimento B realizado hasta que el DUT enva datos errneos. Se muestra el tiempo de
funcionamiento, paquetes enviados y potencia requerida para ambos modos de operacin en dos pruebas realizadas en
cada modo.
Modo de Bajo
Consumo
Habilitado
Prueba
Prueba
1
2

Modo de
operacin Normal
Prueba
1

Prueba
2

Paquetes

1292

1189

361

355

Tiempo (s)

646

593

183

180

Vinicial {V}

3.286

3.28

3.28

3.28

Vfinal {V}

2.1

2.1

1.95

Energia
Consumida {J}
Potencia
Consumida
(Promedio) {W}

3.19390

3.17420

3.47795

3.3792

0.00494

0.00535

0.01901

0.0187

Parmetro

Tomando los datos del Cuadro 5 y Cuadro 6 se pueden realizar las siguientes relaciones:
Experimento A:
Razn de tiempo de funcionamiento entre modo de operacin de bajo consumo y modo normal para el
mejor y peor de los casos entre pruebas:
=

266
= 3.41
78

62
=

316
= 4.05
78

Razn de paquetes enviados entre modo de operacin de bajo consumo y modo normal para el mejor
y peor de los casos entre pruebas:
=

642
= 4.11
156

642
= 3.48
156

Razn entre potencia consumida entre el modo de operacin de bajo consumo y modo de operacin
normal para el mejor y el peor de los casos:
=

0.00639
= 0.249
0.0256

De los datos anteriores se observa que

0.00752
= 0.294
0.0256
utilizar el modo de operacin de bajo consumo del

microcontrolador y la programacin orientada a objetos incrementa el tiempo de funcionamiento y el

nmero de paquetes enviados en un factor de entre 3.4 y 4 veces, y reduce entre 3.44 a 4 veces la potencia
necesaria para el funcionamiento.
Experimento B:
Razn de tiempo de funcionamiento entre modo de operacin de bajo consumo y modo normal para el
mejor y peor de los casos entre pruebas:
=

593
= 3.24
183

646
= 3.59
180

Razn de paquetes enviados entre modo de operacin de bajo consumo y modo normal para el mejor
y peor de los casos entre pruebas:
=

1292
= 3.64
355

63
=

1189
= 3.29
361

Razn entre potencia consumida entre el modo de operacin de bajo consumo y modo de operacin
normal para el mejor y el peor de los casos:
=

0.00494
= 0.259
0.01901

0.00535
= 0.285
0.01877

De los datos anteriores se observa que utilizar el modo de operacin de bajo consumo del
microcontrolador y la programacin orientada a objetos incrementa el tiempo de funcionamiento y el
nmero de paquetes enviados en un factor de entre 3.24 y 3.59 veces, y reduce entre 3.86 a 3.51 veces la
potencia necesaria para el funcionamiento.

Del anlisis anterior se puede concluir lo siguiente:

El modelo de programacin orientada por eventos y el uso del modo de bajo consumo de energa
del microcontrolador MSP430F5529 permiten:

Aumentar el tiempo de funcionamiento del sistema hasta en un factor de 4.

Aumentar el nmero de paquetes enviados por el sistema hasta en un factor de 4.

Reducir la potencia requerida por el sistema hasta en un factor de 4.

Se ha demostrado que el modelo de programacin orientada por eventos y el uso del modo de bajo
consumo de energa del microcontrolador tuvo y tienen un impacto significativo y positivo en
funcionamiento del picosatlite tipo CanSat.

64

VI. RESULTADOS
A.

Pruebas del picosatlite en condiciones reales

Estas pruebas proveyeron datos sobre el desempeo e interaccin de todo el sistema electrnico y el
software con las dems partes del picosatlite (estructura, mecanismos, fuentes de energa) desde un
enfoque de la misin. Estas pruebas permitieron entender mejor los pasos a ejecutar la misin y el impacto
sobre el software, modificaciones necesarias y una perspectiva del software como parte de un conjunto de
sistemas con el equipo tendra que interactuar durante el lanzamiento final.

65
Figura 41. Prueba de liberacin de Contenedor y Carga til bajo condiciones reales.

(a)

(b)

(c)

(d)

(e)

66

(f)

(g)
La

67

Figura 41 muestra una serie de fotografas en las que se observa el funcionamiento de la liberacin del
Contenedor y la Carga til como una accin producto del trabajo en conjunto de varios sistemas. Esta
prueba se realiz bajo las condiciones reales de interaccin y restricciones del sistema mecnico, el
movimiento del satlite mientras desciende y el despliegue de los sistemas de descenso. Como se observa
entre las tomas (c), (d) y (e), la Carga til se liber completamente del Contenedor y despleg su sistema
de descenso.

Figura 42. Pruebas de envo de datos e interaccin entre sistema electrnico, software y estacin en tierra.

68

Figura 43. Prueba de paracaidismo realizada con el picosatlite diseado en conjunto con la Asociacin Guatemalteca
de Paracadismo.

La Figura 43 muestra fotos de las pruebas en condiciones de descenso reales para todo el picosatlite.
En estas pruebas se verific el funcionamiento del picosatlite como un sistema que cumple la misin
CANSAT 2014. Estas pruebas permitieron verificar bsicamente el rango de los dispositivos XBEEs, su
tiempo de reconexin luego de haber perdido la conexin con la estacin en tierra y el funcionamiento del
sistema electrnico en el Contenedor y la Carga til. Esta ltima prueba y sus resultados se podan
verificar solamente analizando los datos almacenados en la memoria interna de cada uno de los vehculos.

69
Respecto al Contenedor, este se logr recuperar y se logr obtener los datos almacenados en la memoria
interna del mismo, de los cuales se hizo un anlisis posterior. Sin embargo, no se pudo comparar estos
datos con los enviados de forma inalmbrica debido a que esta comunicacin fall durante todo el vuelo.
Esto permiti validar que el software de Contenedor y todo el sistema electrnico funcion realizando todas
sus operaciones con excepcin de la transmisin de datos en tiempo real.

70

B.

Secuencia de Eventos durante la Competencia.

La Annual CANSAT Competition 2014 se realiz en el Rancho Jim Burkett, en la ciudad de Abilene,

Texas. La competencia se realiz del 13 al 15 de julio de 2014. Los resultados del software de vuelo
diseado se pueden presentar dividindolos en los eventos de pruebas y lanzamiento final realizados desde
el 12 de julio (Da 0) al 15 de julio (Da 4). Durante estos das se realizaron revisiones oficiales (requeridas
por la competencia) y extraoficiales (realizadas por el equipo para configurar el picosatlite) de hardware y
software y funcionamiento integrado del picosatlite.

Para que cada uno de estos eventos se realizar de forma ordenada, correcta y sin perder ningn detalle,
se desarroll un Manual de Operaciones de la Misin en el que se detall cada paso a seguir por los
miembros del equipo a partir del Da 0. Este manual permitira y permiti cumplir la misin de forma
sistemtica y considerando los tiempos en que cada actividad se debera realizar as como verificar los
resultados de cada actividad para tomar acciones anticipadas en caso ocurriera algn inconveniente.

A continuacin se exponen los eventos llevados a cabo relacionados con el funcionamiento del software
e vuelo (se realizaron otros eventos que no tienen relacin con el software de vuelo):
1.

Verificacin de arribo de todo el picosatlite y materiales (Da 0).

2.

Pruebas de Hardware y Software Electrnico y verificacin de funcionamiento (Da 0).

3.

Ensamblaje del picosatlite y verificacin de funcionamiento integrado. Pruebas de

Rango y Liberacin de Carga til (Da 1).

4.

Prueba de Seguridad (Da 1).

5.

Lanzamiento del Picosatlite (Da 2).

6.

Recuperacin de Datos (Da 2).

71

C.

Verificacin de arribo del picosatlite y materiales (Da 0)

Debido al viaje realizado, exista la posibilidad de que el picosatlite como tal o algunos materiales y
herramientas necesarios no llegarn al destino. Esta verificacin se hizo para tomar acciones correctivas tan
pronto como fuera posible, aunque no hubo necesidad de tomarlas. A continuacin se expone las
verificaciones realizadas pertinentes al software de vuelo.

Cuadro 7. Verificaciones realizadas durante la competencia para comprobar que todos los elementos relacionados al
funcionamiento del software estuvieran completos.

Cantidad

Descripcin

Sistema Electrnico de Carga til

Status
(xito/Fracaso)
xito

Sistema Electrnico de Contenedor

xito

Sistema Electrnico de Carga til de repuesto

xito

Sistema Electrnico de Contenedor de repuesto

xito

Bateras LiIon 4.2V 1000mAh

xito

10

Cables con conectores Macho-Hembra

xito

Corta-alambres plano

xito

Pinza plana

xito

Launchpad for MSP430F5529

xito

Cables USB - miniUSB para conexin de monitoreo

xito

xito

Cables USB - microUSB para conexin de Launchpad

for MSP430F5529
Bateras CR2032 de repuesto

Cargador de Bateras CR2032

xito

Bases para bateras AAA

xito

Switch ON/OFF para contenedor

xito

Laptop con Software de Vuelo de Contenedor y Carga

til, IAR EW for MSP430 v5.6, Waveforms 2.1,
Sublime Text, Altium Designer 2013, X-CTU.

xito

xito

72

D. Pruebas de Hardware y Software Electrnico y verificacin de funcionamiento

(Da 0).
Se realizaron pruebas para corroborar que el Sistema Electrnico de Contenedor y Carga til
funcionaban correctamente luego del arribo a la ciudad de Abilene, Texas. No se tena alguna sospecha de
que estos fallaran por alguna razn relacionada al viaje, pero se quera descartar cualquier problema. Se
prob la comunicacin entre sensores, memoria, reloj de tiempo real y XBEE con el microcontrolador, la
coherencia y exactitud de los datos y otros procesos relacionados a las operaciones que se deban realizar el
da del lanzamiento.

El Cuadro 8 y Cuadro 9 muestran las pruebas y verificaciones realizadas. Todas ellas demuestran si el
software est funcionando correctamente, ya que es ste el que al final permite que los resultados ah
comprobados sean correctos.
Cuadro 8. Pruebas iniciales realizadas al software y sistema electrnico de Contenedor para verificar su funcionamiento
correcto.

Prueba
Se puede establecer comunicacin con
microcontrolador a travs del programador.

Status
(xito/Fracaso)
xito

El software responde a travs de conexin

serial.
El sensor de presin es muestreado
correctamente y se envan los datos por
conexin serial.
Se arman paquetes de datos sin errores y en el
formato requerido.

xito

Recuperar datos de memoria interna.

xito

Borrar memoria interna.

xito

Enviar un paquete de datos a travs de XBEE.

xito

Inicializar software de Contenedor.

xito

Leer cuenta de nmero de paquetes de

Contenedor.

xito

Leer tiempo de misin.

xito

Verificar que el tiempo de misin se actualice

cada segundo.

xito

Verificar activacin de mecanismo de

separacin a travs de comando externo.

xito

xito

xito

Si todos los pasos arriba fueron exitosos, el Sistema Electrnico de

Contenedor funciona correctamente.

73

Cuadro 9. Pruebas iniciales realizadas al software y sistema electrnico de Carga til para verificar su funcionamiento
correcto.

Prueba
Se puede establecer comunicacin con
microcontrolador a travs del programador.

Status
(xito/Fracaso)
xito

El software responde a travs de conexin serial.

xito

El sensor de presin es muestreado correctamente y se

envan los datos por conexin serial

xito

El sensor de temperatura es muestreado correctamente

y se envan los datos por conexin serial.

xito

El sensor de aceleracin es muestreado correctamente

y se envan los datos por conexin serial.

xito

El sensor de voltaje es muestreado correctamente y se

envan los datos por conexin serial.

xito

Se arman paquetes de datos sin errores y en el formato

requerido.
Recuperar datos de memoria interna.

xito

Borrar memoria interna.

xito

Enviar un paquete de datos a travs de XBEE.

xito

Inicializar software de Carga til.

xito

Leer cuenta de nmero de paquetes de Contenedor.

xito

Leer tiempo de misin.

xito

xito

Verificar que el tiempo de misin se actualice cada

xito
segundo.
Si todos los pasos arriba fueron exitosos, el Sistema Electrnico de Carga
til funciona correctamente.

74

E.
Ensamblaje del picosatlite y verificacin de funcionamiento integrado. Pruebas
de Rango y Liberacin de Carga til (Da 1).
Comprobado el funcionamiento correcto de los sistemas electrnicos de Carga til y Contenedor, se
procedi a ensamblar todo el picosatlite y verificar su funcionamiento. Respeto al software, era importante
comprobar que este funcionaba correctamente estando instalado en la estructura mecnica del picosatlite.
Esto implicaba alimentar el Sistema Electrnico de Carga til a travs de paneles solares y el Sistema
Electrnico de Contenedor a travs de dos bateras AAA alcalinas de 1.5V. Estas pruebas resultaron
importantes para validar el funcionamiento del picosatlite como sistema en un ambiente distintos y bajo
las condiciones solares existentes en dicha localidad. Esto ltimo era una comprobacin crtica de todo el
sistema.

Adems se hicieron dos comprobaciones fundamentales para las operaciones de lanzamiento:

Que el rango de la comunicacin inalmbrica fuera superior a los 100m. Los

organizadores de la competencia indicaron la computadora de control en tierra se
encontrara a 100m mximo del cohete antes del despegue. La comunicacin con el
Contenedor dentro del cohete antes del despegue era una operacin crtica para toda la
misin, ya que se le indicaba de forma inalmbrica que comenzara la transmisin de
telemetra adems del tiempo antes de liberar el contenedor en dado caso fallaran los
sensores de altura en correctamente determinar la altura de liberacin.

Que la liberacin de la Carga til efectivamente ocurriera. Era necesario verificar

nuevamente que no exista ninguna interferencia mecnica o error de software o
hardware electrnico que pudiera evitar que ambos vehculos se separaran.

75

Cuadro 10. Pruebas iniciales realizadas al software y sistema electrnico de Carga til para verificar su funcionamiento
correcto.

Prueba
El Sistema Electrnico de Carga til no
colisiona con la carcasa de proteccin.

Status
(xito/Fracaso)
xito

El Sistema Electrnico de Contenedor til no

colisiona con la carcasa de proteccin.

xito

Los cables de alimentacin de Carga til estn

firmemente conectados.

xito

Al activar el mecanismo de separacin, la carga

til efectivamente se separa del contenedor.

xito

La telemetra transmitida por la Carga til est

en el formato correcto.

xito

La telemetra transmitida por el Contenedor est

en el formato correcto.

xito

El Contenedor es capaz de transmitir y recibir

datos a una distancia mayor a 100m.

xito

La Carga til puede conectarse a la estacin en

xito
tierra y transmitir datos de forma inalmbrica
cuando se encuentran separados por ms de
100m.
La Carga til y el Contenedor se separan de
xito
forma apropiada y luego de transcurrido un
tiempo de espera enviado por la estacin en
tierra.
Si las pruebas anteriores son exitosas, el Sistema Electrnico y
Software del picosatlite estn listos para el lanzamiento.

F.

Revisin de Seguridad
La prueba de seguridad formaba parte de las operaciones de revisin previas al lanzamiento y con una

puntuacin para la calificacin final del lanzamiento. Esta consista en revisar el funcionamiento y
estructura del picosatlite para asegurar que era seguro lanzarlo y que podra cumplir con la misin.
Adems era una verificacin de que el satlite cumpla los requerimientos de diseo establecidos por la
competencia.

76

Se pas con xito todos los puntos de esta Revisin de Seguridad. Los jueces hicieron dos
recomendaciones en cuanto asegurar de mejor manera algunos elementos, pero no se perdi ningn punto.
Las recomendaciones fueron, especficamente: 1) Colocar una atura plstica en la placa de sujecin para el
paracadas del contenedor con el objetivo de aadir seguridad a este sistema y 2) Poner un soporte a los
sensores que estaban montados utilizando circuitos impresos independientes.

En el Cuadro 9 se muestra que dichos criterios se superaron con xito.

Cuadro 11. Criterios evaluados en la Revisin de Seguridad.

Operation Checks (Inspeccin Operacional)

Pass/Fail

Power Switch and Power Indication (Switch de Encendido e

Indicadores de Encendido)

Pass (Satisfactorio)

Communication Test (Prueba de Comunicacin)

Pass (Satisfactorio)

Primary Descent Control Device (Dispositivo de Control de

Descenso Primario)

Pass (Satisfactorio)

Structural Integrity Check (Inspeccin de Integridad

Estructural)
Shell Enclosure Secured to Structure? (Carcasa sujeta a la
estructura?)

Pass (Satisfactorio)

Structure Integrity (Integridad de la Estructura)

Pass (Satisfactorio)

Circuit Board Construction Quality (Calidad de la

Construccin de los Circuitos Electrnicos)

Pass (Satisfactorio)

Circuit Board Mounting (Montaje de los Circuitos

Electrnicos)

Pass (Satisfactorio)

Wire Harnessing (Estructura del Cableado)

Pass (Satisfactorio)

Mechanism Mounting (Montaje de Mecanismos)

Pass (Satisfactorio)

Sharp Edges (Bordes Afilados)

Pass (Satisfactorio)

Exposed Mecanisms (Mecanismos Expuestos)

Pass (Satisfactorio)

Team Operations (Logstica del Equipo)

Mission Operations Manual (Manual de Operaciones de
Misin)

Pass (Satisfactorio)

Crew Assignment (Roles del Equipo)

Pass (Satisfactorio)

77

G.
Lanzamiento del Picosatlite (Da 2)
El lanzamiento del picosatlite es la parte ms importante de toda la misin. Adems es la fase a la que
corresponde el mayor porcentaje de la puntuacin total. Se inici con las operaciones de lanzamiento desde
las 8:00 a.m. del 14 de julio de 2014. Las operaciones realizadas fueron las siguientes:
Ensamblaje de Carga til y Contenedor.
Revisin y Configuracin del funcionamiento de los Sistema Electrnicos.
Preparacin del Sistema de Proteccin del Huevo.
Ensamblaje completo del picosatlite CANSAT.
Entrega del Picosatlite a los jueces y evaluacin de peso y dimensiones
mximas.
Encendido del Picosatlite e instalacin dentro del cohete.
Lanzamiento y recopilacin de telemetra.
Recuperacin del Cohete.

A continuacin se exponen los resultados de las operaciones realizadas relevantes para conocer el
funcionamiento del software de vuelo.

1.

Revisin y Configuracin del Funcionamiento de los Sistemas

Electrnicos
Se realiz nuevamente una inspeccin del funcionamiento correcto y la preparacin del software de
Carga til y Contenedor. Los pasos que se muestran a continuacin son el conjunto de acciones necesarias
suficientes para preparar ambos softwares para el lanzamiento.

78

Cuadro 12. Pasos de configuracin y verificacin realizados para la preparacin del software de Contenedor para el
lanzamiento.

Accin
Instalacin de un par nuevo de bateras Alcalinas AAA 1.5V.

Status
(xito/Fracaso)
xito

Encendido de Contenedor.

xito

Programacin de Presin de Liberacin en Contenedor.

xito

Entrar a modo de monitoreo.

xito

Inicializar software de Contenedor enviando comando de

inicializacin

xito

Muestreo de sensores es correcto.

xito

La memoria se puede borrar.

xito

La memoria se ha borrado.

xito

Software de Contenedor se ha inicializado.

xito

La cuenta de nmero de paquetes es cero.

xito

El tiempo de misin ha comenzado.

xito

Hay comunicacin por XBEE entre Contenedor y Estacin en

Tierra.

xito

Verificar que comando de lanzamiento es exitoso 5 veces.

xito

Verificar comunicacin entre Contenedor y Estacin en Tierra

a una distancia mayor a 100m.

xito

Si los pasos anteriores se han realizado con xito, el software de contenedor y el

sistema electrnico estn listos para ser lanzados.

79

Cuadro 13. Pasos de configuracin y verificacin realizados para la preparacin del Software de Carga til para el
lanzamiento.

Accin
Encender el Sistema Electrnico de Carga til utilizando
Paneles Solares.

Status
(xito/Fracaso)
xito

Muestreo de sensores es correcto.

xito

La memoria externa se puede borrar.

xito

La memoria externa se ha borrado.

xito

Software de Carga til se ha inicializado.

xito

La cuenta de nmero de paquetes es cero.

xito

El tiempo de misin ha comenzado.

xito

Existe comunicacin de telemetra entre Carga til y Estacin

en Tierra.

xito

Si los pasos anteriores se han realizado con xito, el software de Carga til y
sistema electrnico estn listos para ser lanzados.

Varios detalles importantes a mencionar dentro de la configuracin de ambos vehculos son:

La presin de liberacin programada en el software de contenedor fue: 95500 Pa. La presin a

nivel de suelo medida fue de 93000 Pa. La diferencia de presiones correspondiente
corresponde a una altura de 500m sobre el nivel del suelo.

En ambos sistemas era necesario borrar completamente la memoria interna para evitar que
datos de pruebas realizadas anteriormente se quedaran almacenados y parecieran datos del
lanzamiento real. Si esto sucediera, sera imposible distinguirlos si las presiones fuesen
parecidas.

Para el contenedor, era necesario instalar un par de bateras nuevas antes de la entrega del
picosatlite a los jueces de la competencia. Solamente as se podra asegurar que el picosatlite
podra estar durante 30 mins. Mximo en espera dentro del cohete, mientras transmite un dato
de confirmacin a la estacin en tierra y espera por el comando de inicio de telemetra.

Para el contenedor era una operacin crtica probar la comunicacin entre este y la estacin en
tierra a una distancia mayor a 100m. Esto se debe a que ah el sistema se encontraba en las
condiciones reales de posible interferencia con otros dispositivos XBEE, ruido proveniente de

80
mquinas utilizadas por otros equipos o cualquier otra fuente de

ruido posible. Esta

comunicacin era crtica para asegurar que el contenedor sera capaz de recibir el comando de
despegue/lanzamiento y as comenzar la transmisin de telemetra y, ms importante an,
evaluar constantemente la presin para liberar la Carga til y/o iniciar el Temporizador que
provoca la liberacin de la Carga til luego de vencido un tiempo determinado.

El tiempo de misin en ambos vehculos deba comenzar al momento de ser encendidos. Este
momento era distinto para cada uno. Para el contenedor, el tiempo de misin comienza en el
momento en que se conmuta el switch de encendido, para la Carga til comienza en el
momento en que se inicializa a travs de la conexin de prueba y monitoreo, ya que este reloj
es alimentado de forma independiente de la fuente de alimentacin de la Carga til.

2.

Encendido del Picosatlite e instalacin dentro del cohete.

Al momento de encender el picosatlite e instalarlo dentro del cohete era crtico verificar que el
Contenedor, el nico vehculo energizado en ese momento, mantuviera conexin con la estacin en tierra.
Esto fue satisfactorio.

Cuadro 14. Prueba de verificacin de comunicacin entre Contenedor y Estacin en Tierra durante la instalacin del
picosatlite en el cohete.

Accin
La Estacin en Tierra recibe comunicacin de
Contenedor una vez por segundo.

Status
(xito/Fracaso)
xito

Si esta prueba es satisfactoria, el software de Contenedor podr

reconocer comando de despegue/lanzamiento.

Figura 44. Verificacin de conexin activa entre Contenedor y estacin en tierra.

81

En la Figura 44 se muestra la forma en que se verific que existiera una conexin activa entre
Contenedor y la estacin en tierra. El software en la estacin en tierra despliega la hora de la ltima
conexin. En este caso, se muestra la hora en que se envi el comando de despegue/lanzamiento al
Contenedor. Esta hora corresponde a la hora de la Ciudad de Guatemala.

3.

Lanzamiento del Cohete y transmisin de telemetra.

a. Contenedor

El contenedor funcion correctamente durante todo el vuelo. Recibi y respondi correctamente al

comando de despegue/lanzamiento enviado por la estacin en tierra al momento de iniciar la cuenta
regresiva para el lanzamiento. Transmiti datos de telemetra correctamente que fueron interpretados por la
estacin en tierra. En el Cuadro 15 se resume el funcionamiento del contenedor.

Cuadro 15. Resultados de las operaciones realizadas por el Contenedor durante el lanzamiento.

Operacin

xito/Fracaso

Contenedor se liber con xito del cohete.

xito

Separacin de Contenedor y Carga til.

xito

Separacin de Contenedor y Carga til en el intervalo

(490,510)m.
Datos de Altura desplegados en tiempo real y unidades
de ingeniera.
Telemetra de CanSat inici correctamente.

xito

Tiempo de Misin se mantuvo correctamente.

xito

Cuenta de nmero de paquetes se mantuvo

correctamente.
Se almacenaron los datos para anlisis y postprocesado.
Se recuperaron los datos almacenados.

xito

Se enviaron los datos en el formato correcto.

xito

Contenedor recuperado.

xito

xito
xito

xito
xito

82

Figura 45. Grfica generada por la estacin en tierra con los datos de presin enviados por el Contenedor.

La Figura 45 presenta la grfica de altura contra tiempo de misin generada por el software de la
estacin en tierra que reciba los datos enviados por el contenedor. En el eje vertical se muestran los datos
de altura en metros obtenidos a partir de los datos de presin. En el eje horizontal se muestra el tiempo de
misin en segundos. El intervalo de tiempo que se muestra es el intervalo de tiempo en que sucedi el
lanzamiento. De esta grfica se puede observar los siguientes resultados importantes:

El tiempo de misin al ocurrir el despegue del cohete fue de 1125 s, lo que corresponde a 18
min y 15 s. Este tiempo corresponde al tiempo de esperar desde que el picosatlite fue
encendido hasta el momento de despegue. Si este tiempo se hubiese prolongado a ms de 30
minutos, la misin habra estado en riesgo ya que las bateras del contenedor habran fallado en
suministrar la potencia necesaria para el dispositivo XBEE.

El Contenedor estuvo en vuelo entre los 1125 s hasta los 1238 s (tiempo de misin), lo que
corresponde a un tiempo de vuelo de 113 s, qu es aproximadamente 1.88 minutos o 1 min y
52 s.

83

El ascenso inici a los 1125 s y finaliz aproximadamente a los 1133 s, lo que corresponde a
8s en ascenso.

La altura mxima alcanzada fue de 1067 msnm (metros sobre el nivel del mar). El nivel del
suelo se encontraba a 500 msnm aproximadamente, por lo que el picosatlite ascendi a 567m
+- 10m.

La velocidad de ascenso promedio fue de 70.9 m/s.

El descenso inicio a los 1134 s, y finaliz a los 1238 s, para un total de 104 s en vuelo o 1 min
y 44 s.

La Figura 45 muestra que la altura del nivel del suelo final fue menor que la altura inicial. Esto
corresponde a la irregularidad de la propiedad en lo que se realiz el lanzamiento. La
diferencia es de 25 m aproximadamente, por lo que la altura que descendi el picosatlite fue
de 592 m

La velocidad de descenso promedio fue de 5.69 m/s.

Se puede observar que la velocidad de descenso fue constante y, por tanto, una relacin lineal
entre la altura y el tiempo. Eso permiti asegurar que el sistema de control de descenso del
contenedor cumpli su objetivo y logr reducir la velocidad de descenso a menos de 8m/s.

Figura 46. Fotografa tomada en el lugar del lanzamiento en la que se observa el Contenedor (Arriba derecha) y la
Carga til (Abajo izquierda) completamente separados y descendiendo haciendo uso de sus respetivos sistemas de
control de descenso.

84

Figura 47. Fotografa tomada en el lugar del lanzamiento en la que se observa la carga til y el cohete descendiendo.

b. Carga til
El vehculo Carga til no funcion durante el descenso, que era la parte del vuelo en la que deba
funcionar. No se transmiti telemetra, no se almacen datos tiles y no se logr mantener el tiempo de

85
misin. A continuacin se resume las operaciones relacionadas con el software que deba cumplir la carga
til y cules de ellas fallaron.

Cuadro 16. Resultados de las operaciones realizadas por la Carga til durante el lanzamiento.

Operacin

xito/Fracaso

Transmisin de datos de altura en tiempo real.

Fracaso

Transmisin de datos de temperatura en tiempo real.

Fracaso

Transmisin de datos de estabilidad y ngulo de descenso en

tiempo real.
Transmisin de voltaje de la fuente de energa en tiempo real.

Fracaso

Transmisin de tiempo de misin en tiempo real.

Fracaso

Transmisin de la cuenta de nmero de paquetes en tiempo real.

Fracaso

Almacenamiento de telemetra.

Fracaso

Datos de telemetra desplegados en tiempo real y unidades de

ingeniera.
Tiempo de misin y cuenta de nmero de paquetes mantenidos
correctamente.
Se recuperaron datos para anlisis y post-procesado.

Fracaso

Carga til recuperada.

Fracaso

Fracaso
Fracaso
xito

Figura 48. Grfica de aceleraciones en funcin del tiempo generada por la estacin en tierra en base a los datos
almacenados en la memoria interna de la Carga til.

86

Figura 49. Grfica de altura en funcin del tiempo generada por la estacin en tierra en base a los datos almacenados en
la memoria interna de la Carga til.

Figura 50. Grfica de temperatura en funcin del tiempo generada por la estacin en tierra en base a los datos
almacenados en la memoria interna de la Carga til.

87

Figura 51. Grfica de voltaje de la fuente de energa. Esta grfica fue generada por la estacin en tierra en base a los
datos almacenados en la memoria interna de la Carga til.

88
Los datos almacenados en la memoria de la carga til no fueron tiles debido a que el tiempo de misin
se corrompi. Se almacenaron datos de nmero de paquete, presin del aire, temperatura del aire,
aceleracin y voltaje de fuente de alimentacin pero algunos de estos no tienen sentido o no se pueden
hacer corresponder a alguna fase del descenso. Sin embargo, analizando los datos obtenidos se puede
obtener los siguientes resultados.

Durante el descenso solo dos paquetes de datos fueron almacenados.

La corrupcin en el tiempo de misin provoc que los dems datos, cuya

evolucin ocurre en tiempo, no puedan ser analizados en tiempo.

Todos los datos de altura recolectados muestran alturas mayores a 540m, lo cual

es correcto.

La presin atmosfrica muestreada estuvo siempre alrededor de 95,000 Pa, lo

cual es correcto.

Las temperaturas ms baja y alta fueron 25C y 30C, respectivamente, lo cual

es correcto.

Los requerimientos de la fuente de energa de la carga til hacan que el sistema electrnico y con esto
el software, fueran muy dependientes de la misma. Si no se recolectaba energa suficiente para el
funcionamiento adecuado de los dispositivos electrnicos, todo el sistema sencillamente no funcionara.
Durante el vuelo fue esto lo que sucedi precisamente. Se expone un anlisis de estos resultados en la
seccin VII. Anlisis de Resultados.

VII. ANLISIS DE RESULTADOS

El software de vuelo de contenedor funcion de la forma en que se dise para cumplir la misin.
Realiz todas sus operaciones con xito y permiti as cumplir con los requerimientos de la misin
asignados al mismo y, la telemetra que se transmiti y almacen, fue utilizada para conocer detalles del
vuelo requeridos para el anlisis posterior y comprobacin de otros requerimientos, como los relacionados
con las velocidades de descenso.
El xito del software del contenedor en todas sus operaciones indica que la arquitectura de hardware y
software desarrollados as como la implementacin de los mismos fue la apropiada para cumplir con la
misin. Adems, todos los dems componentes del contenedor (dispositivos XBEE, sensores, estructura,
sistema de liberacin de Carga til) funcionaron tambin con xito, lo cual contribuyo al xito completo de
las operaciones del contenedor.
Entre los resultados ms importantes cumplidos por el software de contenedor se encuentra llevar a
cabo con xito la transmisin de telemetra durante todo el trayecto. Fue un reto asegurar que los
dispositivos de comunicacin inalmbrica pudieran comunicarse en el rango requerido, que el sensor de
presin midiera correctamente la presin atmosfrica sin perturbaciones por las entradas de aire a las que
estaba expuesto y as poder relacionar correctamente la presin con la altura, y asegurar que el software al
ejecutarse en el microcontrolador muestreara y codificara correctamente dicha informacin para ser
transmitida. Adems la sinergia lograda en las tres operaciones mencionada fue probada constantemente y
requiri un esfuerzo no solo del desarrollador del software, sino de las dems personas involucradas en la
transmisin de datos, el sistema de sensores y la estacin en tierra. De esta forma, la grfica mostrada en la
Figura 45 y los datos de los que proviene, sirvieron para el anlisis necesario del vuelo y tambin para
futuros anlisis que se deseen hacer respecto al lanzamiento de un picosatlite con un diseo similar al
presentado.
Otro de los resultados importantes logrados por el software de vuelo en conjunto con el sensor de
presin fue la liberacin de la Carga til en el rango de 490m 510m, o ms especficamente, a 500m +10m. Este requerimiento, si bien no estaba especificado como un requerimiento definitivo en la
competencia, se incurrira en la prdida de puntuacin si no se cumpla. Durante la etapa de diseo del
software, se decidi que se tomara este requerimiento como definitivo, para no incurrir en la prdida de
puntos. La carga til fue liberada a 497m sobre el nivel del suelo. Este es un punto de liberacin muy
preciso en el rango requerido. El logro de este punto de liberacin requiri probar con muchos algoritmos
que permitieran determinar con suficiente rapidez que el picosatlite se encontraba en dicho punto.

En pocas palabras, para lograr dicho punto de liberacin se requiri, en conjunto con el algoritmo
presentado en la Figura 21, se requiri posicionar el sensor de precisin en la placa en una ubicacin en que

89

90

las corrientes de aire no fueran fuertes, disear una caja que cubriera solo al sensor de presin y que
disminuyera el efecto de estas corrientes y muestrear el sensor de presin con un periodo de 1/12 s.
Los datos de telemetra se almacenaron en el contenedor sin errores. Esto implica que los algoritmos
desarrollados para esta operacin operaron correctamente. Se logr recuperar dichos datos almacenados a
travs de la conexin de monitoreo.

Los resultados de la Carga til fueron completamente opuestos a los del Contenedor. En este caso,
todas las operaciones del software fallaron durante el vuelo y solo dos paquetes de datos se pudieron
almacenar, en los que el tiempo de misin estaba corrupto. No se pudo hacer un anlisis posterior del
descenso de la Carga til debido a la falta de datos para analizar o la imposibilidad de correlacionarlos en
el tiempo.
Es importante mencionar que si bien tanto el software como todo el sistema electrnico no funcionaron
durante el descenso, s lo hicieron luego del descenso y mientras los miembros del equipo se aproximaban a
la estacin en tierra luego de recuperar este vehculo. Es decir, alrededor de 45 min despus del
lanzamiento, cuando se recuper tanto el Contenedor como la Carga til, esta ltima comenz a transmitir
datos de telemetra conforme los miembros del equipo se aproximaban, y la estacin en tierra comenz a
desplegarlos en el software diseado para este propsito. Esto permiti llegar a una conclusin importante
para el software de vuelo de la carga til, y es que si bien no funcionaron, tampoco fallaron, sino que
sencillamente la falla ocurri en otro sistema vital para que este funcionara.
En total, en la memoria interna del sistema electrnico de la Carga til se almacenaron 356 paquetes,
de los cuales solo 2 pertenecan al descenso, y los dems se recolectaron mientras la carga til se
encontraba en tierra. Sin embargo, todos estos datos contenan tiempos de misin corruptos ya que
presentaban cdigos ASCII que el software de vuelo no genera.
Se realiz un anlisis posterior de todos los sistemas que componen a la Carga til y se determin que
la causa de la falla fue el descenso inestable de la misma. Es decir, mientras la Carga til descenda,
experimento demasiadas oscilaciones y vibraciones, un descenso turbulento. Esto provoc que el ngulo el
que el sol incida sobre los paneles solares montados en la parte superior de la Carga til no recibieran la
energa mnima necesaria para alimentar a los sistemas electrnicos, ni durante el tiempo suficiente para
que estos iniciaran a operar. Esto tuvo como consecuencia que el software, ni todo el sistema electrnico,
pudieran comenzar sus operaciones ni siquiera por un tiempo suficiente para generar telemetra o datos
analizables.
Al haber determinado la causa que provoc que el software de vuelo no pudiera funcionar, se puede
descartar que algn problema relacionado con el software haya sido la causa. Un argumento que puede
soportar esta teora de falla y darle validez es que, como se mencion en la seccin V.B Diseo de
Hardware y Software, el software de Contenedor y Carga til son muy similares en cuanto a la estructura y
modelo de operacin, trabajan con los mismos algoritmos para la comunicacin con dispositivos externos y
se ejecutan sobre el mismo modelo de microcontrolador. El Contenedor, que no tena requerimientos tan

91

fuertes sobre la fuente de alimentacin funcion con xito en todas sus operaciones, sin embargo, la Carga
til, cuya fuente de energa era un sistema crtico, fall.

VIII. CONCLUSIONES
1.

El Software de Vuelo desarrollado e implementado permiti darle autonoma de

operaciones al picosatlite tipo CANSAT para cumplir la misin CANSAT2014.

2.

La arquitectura de hardware definida, desarrollada e implementada permiti la

operacin integrada de todos los elementos electrnicos orientada al cumplimiento de la

misin CANSAT2014.

3.

La arquitectura de software y el diagrama de estados definido, desarrollado e

implementado permiti el cumplimiento de los requerimientos mnimos, funcionales y de

integracin del picosatlite.

4.

Se considera que la causa de las fallas en el software de vuelo de Carga til se

debieron a la falla del sistema de recoleccin de energa para proveer energa suficiente
para el funcionamiento de todo el sistema electrnico.

5.

Se demostr que el uso de programacin orientada por eventos y los modos de

bajo consumo del microcontrolador tuvieron un impacto significativo al darle la

capacidad al sistema de reducir la potencia requerida del sistema en un factor de 4, y
aumentar el tiempo de funcionamiento y nmero de paquetes transmitidos por el mismo
factor.

92

93

IX. RECOMENDACIONES
1.

El software de vuelo debe ser estructurado tambin en un sistema de archivos y

libreras. Esto permitira utilizar la misma base de cdigo de forma ordenada y

estructurada. En esta implementacin, los elementos de todas las capas de software se
escribieron en el mismo archivo main.c tanto de la Carga til como de Contenedor. Si
bien desde el punto de vista del compilador esto es indiferente, desde el punto de vista del
programador facilita la reutilizacin del cdigo, hace ms obvia la estructura del software
y produce una implementacin ms flexible y modular.

2.

Generar documentacin automtica del desarrollo e implementacin del

software utilizando una herramienta automatizada para este propsito. Esto permitir
terminar con una implementacin ms formal y una base de documentacin de la cual
futuros desarrolladores puedan mantener o entender el cdigo escrito sin recurrir a
buscar en el cdigo.

3.

Es necesario determinar de forma sistemtica y basada en nmeros la

confiabilidad de los sistemas integrados trabajando en condiciones reales para eliminar,

reducir, controlar o al menos conocer la posibilidad de que todo un vehculo falle, como
ocurri en este caso. Se recomienda la realizacin de pruebas en las que se someta al
picosatlite a las condiciones reales que se espera, y determinar el nmero de veces que
funciona el sistema contra el nmero de veces que se realiz la prueba, y tener un
porcentaje de confiabilidad.

4.

La etapa de pruebas es, definitivamente, la ms importante de todo el desarrollo

de software para un vehculo que simula una misin espacial. Solo de esta forma se puede
asegurar que las acciones y procedimientos que realiza el software estn adecuadamente
diseados, implementados e integrados para cumplir la misin. Se recomienda prever
una etapa de pruebas de al menos 3 meses antes de la realizacin del lanzamiento final.
Esto deber estar considerado en la calendarizacin del desarrollo de software y es un
tiempo mnimo para la realizacin de pruebas.

94

5.

Para futuras misiones que impliquen la separacin de dos vehculos a cierta

altura, se recomienda que se utilice la tcnica implementada en este sistema que consiste
en tomar muestras consecutivas de presin, sin comparar entre muestras para determinar
si el sistema sube o baja y utilizar las lecturas directamente sin determinar si son
correctas o no. Aunque se est sacrificando robustez, la sencillez y efectividad de la
implementacin la hacen una solucin atractiva y confiable.

6.

Al momento de dimensionar la memoria externa para el almacenamiento de los

datos, se recomienda multiplicar en un factor de 4 o mayor dicho espacio de

almacenamiento. En esta implementacin se utiliz el espacio de almacenamiento 1.2-1.3
veces mayor al requerido, pero esto prob no ser suficiente al llegar a la etapa de pruebas
del sistema integrado, cuando se requiri almacenar datos por ms tiempo del estimado
de la misin.

7.

Se recomienda implementar este modelo de programacin y tcnica de ahorro de

energa (uso de modo de bajo consumo de energa) para sistemas con restricciones fuertes
en su fuente de alimentacin y que utilizan el microcontrolador MSP430F5529. Esta
recomendacin se puede extender a otros dispositivos con caractersticas similares.

95

X.

BIBLIOGRAFA

[1] J. Beningo, Fundamentals of Embedded Software, Digikey Continuing Education Center, 12

Septiembre 2013. [En lnea]. Available: http://www.designnews.com/lecture.asp?doc_id=268860.
[ltimo acceso: 20 Septiembre 2014].
[2] P. Koopman, Better Embedded System Software, de Better Embedded System Software, Washington,
Drumnadrochit Press, 2010, p. 2.
[3] J. Beningo, 7 Tips for Using Interrupts, Electronics Design News, 18 Marzo 2014. [En lnea].
Available: http://www.edn.com/electronics-blogs/embedded-basics/4429534/7-Tips-for-UsingInterrupts. [ltimo acceso: 20 Septiembre 2014].
[4] N. e. a. Dash, Event Driven Programming for Embedded Systems - A Finite State Machine Based
Approach, The Sixth International Conference on Systems, n 6, pp. 19-13, 2011.
[5] C. Competition, CanSat Competition, 01 Agosto 2013. [En lnea]. Available:
http://cansatcompetition.com/Main.html. [ltimo acceso: 20 Septiembre 2014].
[6] Wikipedia, Miniaturized satellite, Wikipedia, 01 Enero 2014. [En lnea]. Available:
http://en.wikipedia.org/wiki/Miniaturized_satellite. [ltimo acceso: 21 Septiembre 2014].
[7]
J. Beningo, Developing Reusable Device Drivers for MCU's, Beningo Engineering, 02
Enero 2013. [En lnea]. Available: http://www.beningo.com/123-developing-reusable-device-driversfor-mcus/. [ltimo acceso: 15 Febrero 2014].
[8]
J. Beningo, An Introduction to Function Pointers, Beningo Engineering, 03 Julio 2012. [En
lnea]. Available: http://www.beningo.com/139-an-introduction-to-function-pointers/. [ltimo acceso:
16 Febrero 2014].
[9]
P. Bourque y R. Fairley, g, Piscataway: IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge.
[10]
T. I. Corporation, MSP430F5529 Mixed Signal Controller, Texas Instruments, Dallas, 2013.
[11]
T. I. Corporation, MSPx5xx Family Reference Guide, Texas Instruments , Dallas, 2013.
[12]
J. Beningo, Compositor, Mastering the Embedded Software Design Cycle. [Grabacin de
sonido]. Digikey Continuing Education Center. 2014.
[13]
M. Barr, Embedded C Coding Standar, New Jersey: Netrino, 2009.
[14]
Eriksson, Interrupt Service Routine calling functions, Sweden: IAR Embedded Systems, 2011.

96

97

XI. ANEXOS
Figura 52. Diagrama esquemtico completo del Sistema Electrnico de Carga til.

Figura 53. Diagrama esquemtico completo del Sistema Electrnico de Contenedor.

98

99