Diseño y construcción de un microsatélite (CanSat)

Transcripción

1 IES El Burgo de Las Rozas Diseño y construcción de un microsatélite (CanSat) Trabajo de Investigación del Programa de Excelencia Lo importante no es la colonización de Marte, sino la tecnología que se va a inventar para llegar Pedro Duque 6/10/2017 Efrén Boyarizo Carmen Méndez Martín 12/2017 (Revisión 2) 1

2 2

3 1. INTRODUCCIÓN QUÉ ES UN CANSAT? LA BURGONETA ESPACIAL ELEMENTOS DE UN SATÉLITE Y COMPONENTES UTILIZADOS ORDENADOR DE A BORDO ALIMENTACIÓN DEL SISTEMA Panasonic NCR LM Interruptor por luz SENSORES u-blox NEO 6M (GPS) MQ135 (CO2) GUVA-S12SD (UVC) GY-91 (MPU9250 y BMP280 10DOF) BME280 (Humedad, presión, temperatura) ADS1115 (ADC) DHT11/22 (Humedad) Raspberry Pi Camera Module V TRANSMISORES APC ET600R Radiobaliza CIRCUITO SOFTWARE CANSAT PROGRAMA PRINCIPAL GY-91 (BMP280) Y BME GPS (NEO 6M) ADS GY-91 (MPU9250) APC DHT RASPBERRY PI CAMERA ESTACIÓN BASE (GROUND STATION) HARDWARE SOFTWARE PROBLEMAS

4 5. RESULTADOS FALLOS MECÁNICOS MISIÓN PRIMARIA MISIONES SECUNDARIAS Retransmisión en vivo Localización 3D Mapa topográfico Determinar la posibilidad de vida RESULTADO DEL CONCURSO Y CONCLUSIONES ANEXOS PROTOCOLOS Inter-Integrated Circuit (I 2 C) Comunicación Serie (8N1) IMÁGENES CÓDIGO BIBLIOGRAFÍA PROTOCOLOS DATASHEETS CÓDIGO INVESTIGACIONES PRINCIPIOS FÍSICOS OTROS LINKS AGRADECIMIENTOS

5 1. Introducción 1.1. Qué es un CanSat? Un CanSat, como su propio acrónimo indica, es un satélite del tamaño de una lata de refresco de 330 cl, que asciende a una altura de 1 o 2 kilómetros (mediante cuadricópteros, globos, cohetes ) y cae de manera controlada usando paracaídas, parapentes o incluso sus propios motores (simulando un cuadricóptero). Estos microsatélites, a través del concurso organizado por la Agencia Espacial Europea, permiten a estudiantes europeos participar en un proyecto real de ingeniería. Cada instituto puede presentar un equipo, formado por 6 estudiantes (flexible) y un profesor. Los requisitos que el satélite ha de cumplir son los siguientes: - Tamaño, 110x65 mm. - Peso mínimo de 300 gr y máximo de 350 gr. - Las baterías deben durar de forma continua durante al menos 4 horas. - Resistente como mínimo 20 g de aceleración. - Su velocidad de caída debe ser como mínimo de 8 m/s y como máximo de 12 m/s para un paracaídas normal, y alrededor de 6 m/s para un parapente. - Debe medir al menos la temperatura y presión atmosférica, que corresponde con la misión primaria común a todos los equipos. - Enviar datos al menos cada segundo (no es necesaria una comunicación bidireccional). - El precio máximo es de 500 por CanSat (sin incluir los materiales de la estación base, viaje ). Cumpliendo con los requisitos mínimos, el proyecto resulta sencillo. Para incrementar la dificultad, cada equipo debe idear sus misiones secundarias y cumplir con las mismas equipando en su CanSat los sensores necesarios. Por otro lado, la divulgación (no incluida en los requisitos) supone una parte fundamental del proyecto. Ya sea mediante charlas, merchandasing, aparición en las noticias, redes sociales, o cualquier otro medio, los jueces valoran mucho la divulgación del proyecto. También es importante animar a futuros participantes. Es en ambos puntos (misiones secundarias y divulgación) donde de verdad se marca la diferencia entre unos equipos y otros. 5

6 Para acceder al concurso, primero es necesario enviar un documento en donde se relata a grosso modo el proyecto y el equipo. La selección es realizada en cada país por un grupo designado por la Agencia Espacial Europea y en caso de que no haya concurso nacional por la misma ESA. En el caso de España, 2017 fue el primer año en el que se organizó el concurso nacional, haciendo más sencillo participar en el concurso. El objetivo del concurso nacional es seleccionar al mejor proyecto de cada país para así presentarlo al concurso europeo La Burgoneta Espacial La Burgoneta Espacial, ganadora de la fase nacional y la europea, fue bautizada así en relación a la zona donde se localiza el instituto. El equipo lo conformaron el profesor Francisco Viñas y los estudiantes: Samuel Nevado, Pablo Tomás Campos, Fernando Celaya, Jaime Pérez, Enrique Teja, Fernando Bermúdez y Efrén Boyarizo. Además de la misión primaria, la Burgoneta Espacial tuvo tres misiones secundarias: - Determinar la habitabilidad del planeta en donde se lance, mediante mediciones como: temperatura, CO2 (y otros gases potencialmente dañinos), humedad, presión atmosférica, radiación UV y la existencia de un campo magnético similar al de la tierra (cinturón de Van Allen). - Realizar un mapa topográfico de la zona para decidir un buen lugar de aterrizaje para futuras misiones. - Transmitir en vivo toda la información (incluido el video de caída) para crear así una recreación de la trayectoria, gráficas en tiempo real y evitar la pérdida de datos en el caso de que resulte imposible recuperar los datos físicamente. Para difundir el proyecto de La Burgoneta Espacial se: - Creó un blog ( en donde se publicó toda la información, así como links importantes y el progreso del proyecto. - Crearon perfiles en las redes sociales, como Instagram, en donde se publicaron fotos y videos además de interactuar con la comunidad. - Desarrolló una aplicación móvil para Android, la cual integraba el blog, el canal de YouTube y la cuenta de Instagram. Además, incluyó una función especial: el envío de notificaciones a todos los usuarios que la tuvieran instalada, haciendo 6

7 sencillo notificar a los usuarios el momento del lanzamiento, además de hacer tarea fácil entrar al video en directo (con un simple click). - Como el presupuesto del proyecto fue escaso, para ganar un poco de presupuesto, se decidió hacer camisetas y venderlas, permitiendo así financiar la construcción del satélite para la fase nacional. Como La Burgoneta Espacial ganó el concurso nacional de Caesaraugusta, el proyecto no terminó, construyéndose así un segundo prototipo en el que se intentó solucionar los fallos del anterior modelo. En este documento solo se relata la construcción del segundo CanSat además de los problemas que se intentaron solucionar. 2. Elementos de un satélite y componentes utilizados Todos los componentes se adquirieron en placas independientes de manera que no hiciera falta diseñar el circuito de forma completa, facilitando además el reemplazo de los componentes defectuosos. Para la conexión entre los componentes y la placa principal se emplearon conectores de tamaño 22 CAE (AWG) y separación de 2,54 mm Ordenador de a bordo La parte principal de todo sistema informático es siempre la unidad de procesamiento central. Esta se encarga de recoger los datos de los sensores, procesarlos (en caso de que sea necesario) y de realizar las acciones pertinentes con los resultados obtenidos. En el caso de un CanSat, estos pasos se corresponden con recoger los valores de los sensores, convertir los datos a valores numéricos entendibles, enviar los datos inalámbricamente y almacenarlos en un medio. Para la CPU la elección fue un SBC (todos los componentes necesarios para hacer funcionar el ordenador se encuentran en una única placa), fabricada por la Fundación Raspberry Pi. El modelo fue la Raspberry Pi Zero W, cuyas características son las siguientes: - Un procesador Broadcom BCM2835 ARM de un núcleo a 1GHz Mb de RAM DDR2. 7

8 - Conectividad Wi-Fi y Bluetooth. - Puertos de entrada y salida (GPIO, General Purpose Input and Output pins). - Su tamaño, de tan solo 60x30mm. Aunque estas prestaciones puedan resultar un tanto escasas cuando las comparamos con los dispositivos móviles que usamos a diario, para un CanSat son más que suficientes. Para el modelo nacional se utilizaron dos ordenadores de a bordo, la Raspberry Pi y un Arduino Nano con un microcontrolador Atmega 328P. Esto fue debido a la sencillez de programar en Arduino, ya que su comunidad crea y comparte programas que hacen funcionar los sensores. Dado que el Arduino no fue capaz de procesar todos los datos de los sensores debido a su limitada memoria, se emplearon ambos ordenadores en conjunto, distribuyendo así las tareas. Al tener la necesidad de utilizar la Raspberry Pi como ordenador de a bordo debido a la cámara, se decidió eliminar el Arduino al ser el potencial de la Raspberry Pi más que suficiente para completar todas las necesidades del CanSat. Esto ocasionó que se tuviese que añadir al circuito un conversor de analógico a digital además de dedicar más tiempo al proyecto. Por tanto, la versión de Alemania solo equipó un ordenador, la Raspberry Pi Zero W, reduciendo costes, uso de espacio, consumo y aumentando la velocidad de transmisión a dos datos por segundo Alimentación del sistema Debido a la gran cantidad de componentes, el consumo del CanSat para el primer prototipo supuso un gran reto. Si bien se consiguió que funcionara durante al menos 4 horas seguidas, la temperatura interior del CanSat fue tan excesiva que, hasta que no ventiló a la mitad de la caída, los sensores no midieron correctamente. Este exceso de temperatura fue producido en conjunto por el transmisor de video y el regulador de voltaje. El objetivo de la versión de Alemania fue prevenir esto mediante varias modificaciones Panasonic NCR18650 Las baterías escogidas fueron las Panasonic NCR18650 de tecnología Litio- Ion con una capacidad de 3400 mah y voltaje de 3,6 V. Los motivos por los que se usaron son los siguientes: 8

9 La tecnología es un tanto antigua, pero sigue siendo muy utilizada hoy en día debido a su alta capacidad (tres veces superior a las de tipo LiPo), y sobre todo a que son mucho menos peligrosas que las LiPo, que, aunque muchos dispositivos las usen debido a su caída de voltaje mínima (lo que resulta muy cómodo para alimentar equipos electrónicos con un elevado consumo), un cambio de temperatura brusco o simplemente un golpe fuerte, puede provocar una la reacción química de la pila. Son a fecha de este documento las baterías con mayor capacidad (3400mah), en relación a su tamaño. Y es por esto que una variante de estas baterías es usada por la compañía Tesla Motors en sus automóviles eléctricos. Su voltaje normal de 3,6 V es excelente para alimentar el transmisor de video, ya que dos en serie dan 7,2 V que superan el voltaje mínimo de 7 V para alimentar el transmisor de video LM2575 El uso de estas baterías conlleva el problema de ajustar el voltaje a 5V, ya que la mayoría de los componentes del CanSat dependieron de un voltaje fijo con variaciones de máximo ±10%. Para conseguir ese voltaje, en Zaragoza se utilizó el regulador de voltaje lineal LM7805 de uso muy simple. Pero, al basarse la regulación del voltaje en una resistencia variable, la energía sobrante se disipa en forma de calor. Para calcular cuanta energía se pierde, se toma el regulador como una resistencia: P = ΔV I = (7,2 V 5 V) 1 A = 2,2 W η = VOUT / VIN = 5 V / 7,2 V = 0,7 = 70% Esto supone que al regular el voltaje se pierden 2,2 W en forma de calor con un rendimiento del 70%. No muy eficiente si se tiene en cuenta que las baterías al estar cargadas, tienen un voltaje superior, ergo la eficiencia es peor. Tras investigar, se concluyó que la mejor forma de reducir el consumo y el calor era cambiando el regulador de voltaje y el apagado selectivo del transmisor de video. El regulador de voltaje escogido para el segundo CanSat fue el LM2575, un regulador conmutado ajustable de 1ª, que, a diferencia del anterior, requiere de un circuito más complejo, pero añade las siguientes mejoras: 9

10 Protección contra polaridad inversa. Muy útil si uno no tiene cuidado. Un voltaje mucho más limpio de interferencias (las oscilaciones producidas por los transmisores pueden contaminar la alimentación produciendo oscilaciones en la alimentación nada convenientes). El LM2575 puede venir con voltaje fijo, o como en este caso con el voltaje ajustable. Si es esta última, el regulador dependerá de la combinación de dos resistencias para ajustar el voltaje de salida. Una relación de 1/3 es aproximadamente la necesaria para dar 5 V. Para el CanSat se utilizaron dos combinaciones diferentes, pero la que más se ajustó fue con R1=330 Ω y R2=1K Ω. Respecto a la eficiencia de este regulador, resulta bastante compleja de calcular debido a que su eficiencia no varía linealmente (afectan muchos factores, como la calidad de los componentes). La única manera es calcularlo empíricamente. En la siguiente tabla se muestra aproximadamente un rendimiento del 82% para 5 V y 1 A. Aunque la tabla indica una eficiencia similar a la del LM7805, en pruebas reales la bajada de consumo fue mucho más significativa, dado que el CanSat no siempre consume la misma cantidad de energía. Más pruebas quedaron pendientes de realizarse, pero dada su irrelevancia, se decidió utilizar el LM2575 debido a su disipación térmica mucho menor, además de un mejor consumo. 10

11 Interruptor por luz Para reducir el consumo del transmisor de video se diseñó un circuito el cual cerraba la alimentación usando dos Mosfets conectados a dos LDR. La circuito tuvo la función de cortar la alimentación del transmisor de video en la oscuridad. Precisamente el momento en el que el CanSat esperaba dentro del cohete para ser lanzado podría extenderse mucho, y al ser inútil el transmitir el video, el transmisor se apagaba con la oscuridad dentro del cohete, ahorrando en produciendo el apagado selectivo del transmisor de video (al ser el componente con mayor consumo) y suponiendo un ahorro enorme de energía Sensores u-blox NEO 6M (GPS) Para una localización 3-D del CanSat la mejor opción fue un dispositivo GPS (Global Position System), que basándose en una constelación de satélites obtiene una localización más o menos precisa. Una de las marcas más famosas que manufactura estos dispositivos a un tamaño y costo reducido es u-blox. El modelo escogido fue el u-blox NEO-6M, un GPS de muy bajo coste, pero cuyas prestaciones no tienen nada que envidiar a sus hermanos mayores (excepto el soporte para las nuevas constelaciones). Este GPS es muy sencillo de usar, y la única comunicación que hay es a través de un puerto serie (anexo 7.2.2). Tal y como viene de fábrica el GPS es perfectamente funcional: envía toda la información (incluyendo la irrelevante posición de cada satélite) una vez por segundo. El GPS se modificó para que enviase la localización 3-D corregida y la velocidad dos veces por segundo para facilitar el uso del GPS desde el Software. Además de estos cambios, para el modelo de Alemania se sustituyó la antena que venía de fábrica por una de menor tamaño, menor peso, mayor ganancia y mejores soldaduras del cable. 11

12 MQ135 (CO2) El MQ135 es un sensor muy utilizado para detectar gases perjudiciales, aunque su bajo coste se contrapone con su elevada dificultad a la hora de medir precisamente. Cada sensor tiene una resistencia interna diferente, que se tiene que determinar en condiciones especiales. El fabricante del sensor adquirido no proporcionó ninguna información sobre las resistencias, por lo que la primera opción fue calcular las partículas por millón (ppm) utilizando la siguiente fórmula proveniente del datasheet: PPM = Rs/Ro Rs = 1024*(Resistencia Pull-Down)/(voltaje de salida) - (Resistencia Pull- Down) Ro = Resistencia del sensor a 100ppm de NH3 en aire limpio Esta es la manera oficial de obtener medidas exactas, pero resultó imposible calibrarlo al no poder determinar la resistencia Pull-Down que el sensor incorporaba. Como última opción se decidió ir con el método simple que algunos usuarios recomiendan: usar un multiplicador. Dado que el voltaje de salida es más o menos directamente proporcional a la cantidad de partículas por millón, una simple multiplicación basta para obtener una medida aproximada. Para calibrarlo, se aumenta o disminuye el multiplicador. Una primera opción fue buscar alguna estación en Madrid que midiese las ppm de CO2, pero sorprendentemente, ninguna de las listadas en toda la comunidad indica valores diarios. Como último recurso el sensor se calibró usando la media global GUVA-S12SD (UVC) Para el primer prototipo se adquirió un sensor capaz de abarcar desde el rango A hasta el C. La primera idea fue elaborar un filtro para eliminar los rangos A y B. Este primer filtro, obtenido a partir de un cristal tintado, supuestamente bloqueaba los rangos UVA y UVB, aunque debido a la falta de presupuesto para adquirir una lámpara de UVC, se tuvo que confiar en que los valores enviados por el sensor coincidían con el rango UVC sin bloquearlo parcialmente. Así fue el filtro presentado a la fase nacional, que más tarde se comprobó que bloqueaba el rango A y parcialmente el B. 12

13 Para la fase europea se decidió presentar otro prototipo del sensor de UVC, esta vez, en vez de bloquear los rangos UVA y UVB bloquearía el UVC en uno de los dos sensores. De esta forma calculando la diferencia entre los valores de cada sensor se obtendría un valor aproximado de UVC. Para comprobar el funcionamiento, varios miembros del equipo visitaron un laboratorio donde intentaron durante varios días obtener un filtro que solo bloquease lo necesitado. Al final, anecdóticamente, resultó que un film transparente que andaba por allí bloqueaba aproximadamente el espectro necesitado. Los sensores usados para la versión final fueros los sensores UV de Adafruit, los cuales marcan el rango de UV en base a su voltaje, es decir, alimentando el sensor con un voltaje regulado de 5 V, el voltaje de salida multiplicado por 10 indica el índice de UV GY-91 (MPU9250 y BMP280 10DOF) Este sensor diseñado para ser parte de un controlador de vuelo se implementó en el primer modelo y se mantuvo para el segundo. Aunque el modelo adquirido fue una copia china, este funcionó excelentemente. El GY- 91 incorpora dos sensores en una única placa: el MPU9250 (incorpora además el magnetómetro AK8963) y el BMP280 de Bosch. Gracias al protocolo I²C usado (anexo 7.2.1), ambos sensores van conectados a la misma línea y con la misma alimentación BME280 (Humedad, presión, temperatura) El BME280, de la misma serie de que el BMP280 de además de sensor de temperatura y presión uno de humedad, usando el mismo protocolo I²C. Desafortunadamente el sensor adquirido resultó ser el BMP que se ofertaba como BME con descuento, aun así, se instaló en el CanSat añadiendo además como cambio de última hora el DHT22 (mucho menos preciso). 13

14 ADS1115 (ADC) El ADS1115 es un conversor de analógico a digital que usa el protocolo I²C, muy conveniente, ya que el protocolo usado por los demás sensores es el mismo y permite conectar todos los sensores a una misma línea simplificando el circuito. Dado que el Arduino incorpora un ADC (conversor de analógico a digital), la primera versión no necesitó uno externo. Pero, para la segunda versión, eliminar el Arduino supuso la necesidad de añadir un ADC externo debido a la ausencia de uno en la Raspberry Pi (con solo salidas y entradas digitales). Las ventajas y características de este ADC son: Gran velocidad obteniendo mediciones. Mayor resolución de 16 bits a diferencia de 10 bit en Arduino. Sin necesidad de voltaje de referencia, facilitando el diseño del circuito, a diferencia de otros ADC. Un consumo mucho menor respecto a otros ADC del mercado DHT11/22 (Humedad) Ambos DHT son muy usado por su bajo coste. Aunque la precisión deja mucho que desear incluso en el más preciso DHT22. Su uso se limitó a detectar la presencia de humedad, ya que la temperatura se recogió del BMP280. El único problema grave con este sensor es el tiempo de recogida de datos, siendo uno por cada dos segundos. Respecto a su funcionamiento interno, no se invirtió tiempo en investigarlo debido a la gran disponibilidad de librerías Raspberry Pi Camera Module V2 La Fundación Raspberry además de ordenadores, vende también cámaras. Estas se conectan a través del puerto CSI presente en las Raspberry Pi. Estas cámaras permiten al usuario realizar videos y tomar fotografías en alta calidad de manera sencilla. Para el CanSat, se utilizó la segunda versión con un sensor Sony IMX219 de 8 megapíxeles que alcanza a tomar video a 1080p 30 fotogramas por segundo y un filtro IR. Estas cámaras vienen con una tuerca que 14

15 permite ajustar la distancia focal, la cual se ajustó para conseguir la mayor profundidad de campo, o lo que es lo mismo, mayor campo de enfoque. Su uso es relativamente sencillo, se conecta a la Raspberry y se activa la cámara en los ajustes. Por sencillas que parezcan estas cámaras, incorporan múltiples herramientas en las que se pueden ajustar todas las opciones (discutidas con más detalle en el apartado de software). Para el CanSat se decidió tomar videos de 5 minutos a 1080p y 30 fotogramas por segundo para así tener la mayor cantidad posible de imágenes, sin saturar la memoria RAM y procesador Transmisores APC220 Este transmisor se usa para comunicaciones de puerto serie a larga distancia. Su alcance es de máximo 1000 m con velocidad de 2400 bps usando las antenas helicoidales que vienen en el kit. Para el CanSat se necesitó un alcance de máximo 2 km, por lo que se tuvo que elaborar una antena monopolo de longitud ¼ de onda. La ventaja de esta antena es la sencillez y facilidad de adquisición (uno mismo la puede hacer en casa), que, además, al ser flexible ocupa menos espacio. La antena que el CanSat equipó fue hecha a partir de un trozo de cable metálico con longitud de 17,23 cm. Para recibir se invirtió en una antena Yagi de 433 MHz. Costosa, pero con mucha ganancia. En pruebas reales se comprobó que el alcance superaba los 2 km con tan solo 20 mw de potencia. Para transmitir datos se usó la frecuencia de 433 MHz debido a que es la frecuencia legal más baja y más usada, lo que supone un menor coste del equipamiento ET600R Este transmisor fabricado por Eachine es usando en hobbies para FPV (vista en primera persona). Su uso es tan simple como conectar video analógico al transmisor y sintonizar la frecuencia en el receptor. La frecuencia 15

16 escogida para este transmisor fue 5705 MHz. Hay varias razones por las que se decidió usar tan elevada frecuencia: El video a diferencia de los datos, contiene mucha más información. Es decir, frecuencias tan bajas como 433 MHz requieren compresión, lo que eleva el precio del equipamiento. Los primeros transmisores asequibles transmiten a 1,2 GHz, pero no todas las frecuencias son legales para uso libre. Las frecuencias de 1,2 y 1,4 GHz son ilegales por razones propias. La siguiente opción fue usar un transmisor de 2,4 GHz, pero al estar tan extendida globalmente es inevitable sufrir interferencias. La siguiente banda legal es 5,8 GHz, y al ser la más popular tiene la ventaja de un coste muy reducido del equipamiento. La frecuencia de 5,8 GHz tiene menor penetración que otras frecuencias, requiriendo mayor potencia para transmitir. El transmisor que equipó el CanSat transmitió a una potencia de 600 mw a diferencia de los 20 mw del APC220. Esto supuso un consumo mucho mayor de energía, además de una gran disipación térmica. Estas potencias son ilegales en muchos países, por lo que se solicitó permiso a la organización. Aunque afirmaron que su uso está prohibido, al ser la ocasión especial y por un corto periodo de tiempo no debería haber problema alguno Radiobaliza Aunque en un principio se planeó incluir una baliza que transmitiría una señal a 315MHz, se tuvo que descartar debido a problemas de espacio Circuito Para conectar los componentes, se necesitó de un circuito. Las primeras versiones se realizaron en una protoboard conectada a una Raspberry Pi 1 B+, que junto a jumpers conformaban un circuito. Como este no era viable, se decidió diseñar una PCB (placa de fibra de vidrio con un circuito impreso encima). En un primera fase se intentó diseñar 16

17 con un programa llamado Fritzing, y posteriormente con KiCad, desafortunadamente su aprendizaje requiere de tiempo y dedicación. Como última opción, se elaboró un primer circuito a mano, resolviendo las conexiones de cabeza, cuyas medidas se escanearon posteriormente para elaborar el circuito con un programa de edición de fotografía llamado GIMP. Las conexiones son las siguientes para el modelo de Alemania: Las dos baterías van en serie para aumentar el voltaje a 7,4 V, necesario para el transmisor. Para regular el voltaje a 5 V se usó un LM2575. La Raspberry Pi, el APC220, MQ135 y sensores de UVC fueron conectados a 5 V, el resto se alimentaron del regulador de 3,3 que incluye la Raspberry Pi. El interruptor por luz se posicionó entre medias de la alimentación y el transmisor. Todos los sensores que utilizan el protocolo I2C, van conectados en serie a las mismas conexiones. El GPS va conectado al pin de recepción (RX) del puerto serie de Hardware y el APC220 en la salida (TX). De esta forma se aprovecha el único puerto por Hardware que hay evitando tener que recrear uno por Software (elevado uso de CPU). El DHT va conectado a un pin digital cualquiera. El más conveniente fue el pin

18 La cámara va conectada directamente a la Raspberry Pi mediante su propio cable diseñado por la fundación Raspberry. El transmisor de vídeo va conectado a la salida de video analógica de la Raspberry Pi. Dado que la alimentación de la Raspberry pasa a través del regulador, a no ser que se conecte el retorno directamente de la Raspberry Pi al transmisor (negativo del video) se pueden producir interferencias en el video. Se conectó el negativo del video al negativo del interruptor lumínico. Para la elaboración del circuito se tuvo en cuenta los pines de cada sensor además de los cambios que tuvieran que hacerse eléctricamente (cambio de dirección del BME280). El circuito final es el siguiente: 3,3V 7,2V 5V GND / NC I2C Serie Analógico Notas sobre el circuito: El circuito impreso se elaboró a mano usando una PCB de revelado fotosensible a doble cara y atacador. El BMP280 fue alimentado en el pin SDO con 3,3 V para cambiar la dirección evitando conflictos con el GY- 91. El circuito tiene la mayor superficie posible de masas para evitar interferencias. Las conexiones antes del transmisor de datos son para unos deep switches que lo desconectan en caso de que se necesite reprogramarlo. El DHT, que no aparece en la imagen, iría por la cara posterior conectado a la izquierda del APC

19 El transmisor de video y los sensores de UV, fueron conectados mediante cables a la placa. El cable azul es la masa del video conectada al negativo del transmisor de video para prevenir interferencias. El circuito que corta la corriente del transmisor de video fue añadido a la placa, pero desafortunadamente falló momentos antes del lanzamiento, por lo que se decidió desactivar haciendo un puente. El circuito constó de dos Mosfets y dos LDR, los cuales activaban el paso de corriente cuando la luz era detectada. El resultado final es el siguiente: Respecto a los componentes, se tuvo en cuenta lo siguiente: En un principio no se tenía planeado colocar el DHT22, pero como no hubo ninguna otra opción para medir humedad, se colocó encima del APC220. El GY-91 fue configurado para que la brújula funcionase cuando estuviera horizontal, por lo que se colocó de tal forma. El núcleo de ferrita (en blanco) usado en el regulador de voltaje tuvo que ser aislado primero con una funda de cinta aislante y por fuera con un trozo de chapa metálica. Esto evitaba interferencias con el transmisor de video, datos y sobretodo GPS. El cable que conecta a la cámara con la Raspberry Pi fue asegurado haciendo una U debajo del MQ135, además de ser forrado en una funda aislante. Esto prevenía la desconexión del cable, así como posibles daños. 19

20 Los últimos pasos son soldar los cables del transmisor de video y baterías. Con eso la placa ya estaría terminada. Para un mayor detalle de como montar el CanSat, puedes visitar el canal de YouTube en donde encontrarás dos animaciones: 3. Software CanSat La Raspberry Pi como ordenador precisa de un sistema operativo. El mejor de todos los que hay disponibles es una versión de la distribución Debian GNU/Linux llamada Raspbian. Este S.O. viene con una gran cantidad de herramientas preinstaladas entre ellas la utilidad para la cámara y un entorno de desarrollo en Python que permite la utilización de los pines GPIO. Gracias al software, la Raspberry Pi resulta muy atractiva para desarrolladores. El primer paso en la elaboración del software es poner en funcionamiento de manera individual cada sensor. Debido a la plataforma escogida (Linux), las llamadas librerías (software que permite al usuario acceder de forma sencilla a las funciones del sensor) escasean. Esto forzó a usar el Arduino para la primera versión, pero para la segunda versión, se decidió dedicar más tiempo y crear librerías propias, o modificar las ya existentes. El software del CanSat está diseñado para aprovechar la capacidad del ordenador a bordo de ejecutar varios programas al mismo tiempo (multitasking). El motivo de este diseño es debido a los problemas encontrados al portar el código desde Arduino. A diferencia de Arduino, en Python un error significa la terminación del proceso. Para solucionar este problema se utilizaron dos métodos: 1. Captar todos los errores e ignorarlos con la siguiente función: try: catch: pass Aprovechando el apartado de captar errores (catch), se puede incorporar además los comandos que inician el sensor, de tal manera que, si el sensor se desconecta, el programa intentará de manera indefinida reconectarlos lo que 20

21 brinda la posibilidad de reconectar los sensores en caliente. Para evitar aún más errores, dentro de la función catch se volvió a incluir una función try. 2. Independencia entre sensores, teniendo un programa único para cada sensor. De esta manera si uno falla, no ocasionará ningún problema a los demás programas. Aprovechando la capacidad de multitasking se puede además mejorar la velocidad (hasta un cierto límite), ya que, si fuese un único programa, tendría que ir sensor por sensor recogiendo los datos, ralentizando la recogida de datos Las desventajas de este diseño vienen a la hora de hacer que todos los programas cumplan un objetivo conjunto. La solución más sencilla es un programa encargado de controlar a los demás. Para la Burgoneta Espacial, el programa encargado de recoger, enviar y guardar los datos fue también el encargado de iniciar, controlar el estado y reiniciar los programas independientes. Para transferir la información al programa principal se necesitó de una base de datos (lugar en donde los datos se almacenan de forma que sean accesibles al mismo tiempo desde diferentes localizaciones). Como no se necesitó nada extraordinario, se utilizaron documentos.txt como simple forma de almacenamiento temporal de datos. Este fue el sistema escogido debido a que los archivos son fáciles de acceder, no requieren de ningún programa externo y ocupan poco espacio en el disco. Un total de 7 documentos se usaron como base de datos. El siguiente esquema corresponde al funcionamiento del software del CanSat: 21

22 3.1. Programa Principal El programa principal se encargó de: Comprobar el estado de los sensores. Iniciar los programas individuales en base al estado de cada sensor. Controlar el estado de cada programa individual. Recopilar los datos desde la base de datos. Enviar la información procesada al transmisor de datos. Guardar todos los datos en un archivo. El programa principal consta de tres partes, la primera de ellas entra en acción cuando se enciende la Raspberry Pi. Este programa.sh está programado para iniciarse automáticamente una vez el S.O. se inicia. Como algunos módulos del programa pueden ocasionar problemas con el inicio, el programa esperará hasta que se haya completado el inicio. Una vez hecho esto, ejecutará en un loop la segunda parte escrita en Python de tal forma que si el proceso termina ejecutará la tercera parte del programa. Esta tercera y última parte se encarga de limpiar los procesos terminando todos aquellos con el nombre de python (para un reinicio limpio). La segunda parte ejecutada realiza lo siguiente: 1. Importa las librerías necesarias: utilidades del sistema, operaciones complejas de matemáticas y puerto serie. 2. El programa llama a la tercera parte la cual contiene una clase encargada de comprobar sensor por sensor si se encuentran conectados y funcionando. Para comprobar el estado de cada sensor se usaron los siguientes métodos: a. Para los que usan el protocolo I 2 C, basta con leer las direcciones que hay disponibles, ya que si un sensor no aparece en el listado es porque no funciona. b. Para el DHT, una simple lectura digital del pin al que está conectado basta para determinar si funciona. c. El GPS se comprueba leyendo a través del puerto serie. Si se recibe algún dato es porque hay algo conectado que manda información. 3. Una vez realizadas las comprobaciones, la clase devuelve al programa principal un numero comprendido por 7 dígitos, cada uno correspondiente a cada sensor. Si el dígito es 1, entonces el sensor funciona y por lo tanto se puede proceder con el inicio del programa encargado del sensor. Por el contrario, si el dígito es 22

23 0, el sensor presenta algún problema. En este último caso, el programa del sensor no se iniciará, evitando así problemas en el inicio (si se inicia el programa del sensor sin estar conectado conlleva a un bucle infinito en el que el programa principal nunca completa el inicio). Esta línea es también enviada por el transmisor de datos para ser recibida en la estación base. 4. El segundo paso es decidir que programas iniciar, y ejecutarlos en segundo plano. Esto se realiza mediante el módulo subprocess de Python, el cual permite la ejecución de otro programa en segundo plano sin interferir en el bucle del programa principal. La ventaja de este módulo es la posibilidad de ejecutar varios programas desde uno solo, además de que, si el servicio finaliza sin haberlo autorizado, el módulo lo reiniciará. Es este módulo el que permite una redundancia mucho mayor del sistema. Aun así, cada programa independiente tiene la capacidad de recuperarse de un error por sí mismo. 5. Tras iniciar los programas independientes, esperará hasta que todos se inicien correctamente. Y, por último, el programa pasa a un bucle, en donde realiza lo siguiente: a. Desde la base de datos, recoge los datos de cada sensor, siempre que hayan dado positivo en el chequeo inicial. En caso contrario, pondrá los valores como 0. b. Agrupa todos los datos que se van a enviar (exceptuando algunos datos debido al límite del ancho de banda): localizador, hora, latitud, longitud, altura GPS, velocidad horizontal, roll, pitch, yaw, humedad, temperatura, presión, altura barométrica, velocidad vertical, CO2 ppm, UV1, UV2 y el voltaje de la batería. c. Comprueba la longitud de la variable a enviar, y le añade al final el número que indica los dígitos totales de la variable a enviar. d. Envía la variable a través del puerto serie. e. Crea otra variable que une todos los datos recogidos de los sensores. f. Guarda la variable en el documento de texto. g. Espera 0.5 segundos para realizar de nuevo el bucle GY-91 (BMP280) y BME280 La librería del sensor barométrico y de temperatura fue modificada a partir de la librería de Adafruit. Las modificaciones fueron las siguientes: 23

24 Cambio de la dirección I2C, para cada uno de los sensores, creando dos programas idénticos a excepción de la base de datos y la dirección I 2 C. Ampliación de los datos para incluir también velocidad vertical, que se calcula usando el reloj del sistema (se almacena el tiempo y altura anterior, y calculando los incrementos de alturas y tiempo se obtiene la velocidad vertical). Seguridad y la base de datos. La rutina del programa es la siguiente: Los datos se recopilan en una única variable. El documento de la base de datos se borra entero. Se suben los datos al documento. Espera 0,5 s para iniciar de nuevo GPS (NEO 6M) El GPS, fabricado por u-blox, envía la información a través del puerto serie. Para ello, usa un sistema de comandos llamado NMEA (concretamente NMEA 0183 V2.1, creado por la National Marine Electronics Association). Este sistema tiene la siguiente estructura: Como se puede apreciar en la imagen, los comandos que el GPS envía vienen encabezados por un identificador (address) que indica el tipo de datos. Los datos vienen separados por comas. Y al final de la línea hay un checksum el cual 24

25 no sirve a ningún propósito, dado que el canal por donde circula la información tiene muy poca probabilidad de que se produzcan errores. Una vez conocido el sistema a usar, el siguiente paso fue determinar qué datos son los relevantes: hora, latitud, longitud, altura y velocidad horizontal. Para ello, las líneas relevantes son: GGA datos esenciales arreglados que proveen una localización 3D y datos precisos. $GPGGA,123519, ,N, ,E,1,08,0.9,545.4,M,46.9,M,,*47 Hora Latitud Longitud Satélites Altura VTG Velocidad arreglada. $GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48 Velocidad (Km/h) Como se puede ver, las coordenadas que usa el sistema NMEA no son las usadas por Google Earth, por lo que hizo falta convertir de grados y minutos en un único número a solo grados. La conversión es la siguiente: º Latitud: ,N 48º ' Norte = 40º /60 Norte = º * (1) = Longitud: ,W 11º 31' Oeste = 11º + 31/60 Oeste = º * (-1) = º En función de la dirección hay que multiplicar los grados por 1 (Norte y Este) ó -1 (Sur y Oeste). La rutina del programa encargado del GPS es la siguiente: 1. Comienza importando las funciones necesarias del sistema. 2. Inicializa todos los servicios a usar. 3. Comienzo del bucle: a. Lee los datos del puerto serie hasta el final de línea. b. Si los datos leídos empiezan con $GPGGA, entonces: i. Separa los datos en variables independientes 25

26 ii. Si la latitud no contiene datos, entonces eso indica que el GPS no recibe aún señal, por lo que hace los datos 0 (en caso de que no haya datos anteriores). iii. Si la variable latitud contiene datos, entonces procesa los datos. c. Si los datos leídos empiezan con $GPVTG, entonces: i. Extrae la velocidad, y la convierte a metros por segundo d. Junta los datos en una variable. e. Borra la base de datos. f. Sube los datos a la base de datos. El GPS de u-blox de por defecto viene configurado para retransmitir toda la información cada segundo. Como mucha de esa información es irrelevante, se desactivó a través del software u-center para que solo enviase las dos líneas anteriormente mencionadas, evitando ralentizaciones (distinciones entre las líneas relevantes). Además, se aumentó la velocidad a 2 datos por segundo (un cálculo cada 0.5 segundos) ADS1115 Dado que los sensores analógicos fueron conectados a este ADC, se encuentran agrupados bajo esta categoría. El programa que pone a funcionar el ADC fue modificado a partir del escrito por Adafruit para que realizase las tareas necesarias, aunque se necesitó un análisis superficial de su funcionamiento. El ADS1115 envía las lecturas en números de 16 bits, por lo que el voltaje se indica en números desde el 0 hasta el (2 16 ). Para obtener mediciones se un rango de voltaje, de tal forma que ajustando ese rango se obtiene una mayor o menor resolución. En la siguiente tabla se muestra el rango de voltajes a los que se puede ajustar (FSR), además de la resolución correspondiente (LSB): 26

27 Como el voltaje de salida del MQ135 puede alcanzar los 5V, el rango de voltajes se ajustó a ±6.144 V. Como del sensor se recibe un número desde 0 hasta y se necesita el voltaje, hizo falta realizar la conversión con el siguiente multiplicador:,, = 0, Este valor es el que se utiliza para obtener el voltaje, ya que cada bit corresponde a μv como muestra la tabla anterior. Una vez se tienen los voltajes, el siguiente paso es convertir el voltaje al valor necesitamos de cada sensor: En el caso del MQ135, como se explicó anteriormente (2.3.2), se usó el multiplicador de 4882,814. Los sensores de UV son mucho más sencillos, para obtener el índice de UV basta con multiplicar el voltaje por 10. Como sobraba un pin analógico se decidió emplear en monitorear el voltaje de la batería obteniendo así un porcentaje aproximado de la energía restante. El procesado del porcentaje se realizaba en la estación base. El CanSat solo enviaba el voltaje GY-91 (MPU9250) El programa para controlar y obtener datos desde el MPU9250 es uno de los más complicados. No solo por los cálculos que realiza para obtener los movimientos de Roll, Pitch y Yaw, sino también por la complejidad del sensor en sí mismo. Afortunadamente, un usuario de GitHub llamado Zenju Daisuke publicó su trabajo sobre este sensor. No solo ponía el sensor en funcionamiento, sino que, además, calculaba los tres movimientos necesarios. Los cambios realizados al código fueron los siguientes: Como se explicó anteriormente, el sensor vino con el orden de los datos alterado. Un simple cambio de orden en la recogida de datos bastó para solucionar el problema. Se añadió la integración de la base de datos, así como la seguridad del programa. Una vez realizado los cambios, el sensor no volvió a dar problemas y funcionó perfectamente en el lanzamiento, aunque seguimos a la espera de recuperar los datos al completo que incluye mucha información recogida por el MPU

28 3.6. APC220 El APC220 es el componente más sencillo de utilizar. La única dificultad se encuentra a la hora de configurar la frecuencia y potencia. Para esto, hay que conectarlo usando el adaptador que viene en el kit, y con el programa RF Magic se ajustó la frecuencia a 434,88 MHz con la máxima potencia de 20mW. Lo único que hay que hacer para comunicarse es mandar la información a través del puerto serie. Lo complicado quizás de este sensor es la implementación de un sistema de seguridad para determinar que los datos recibidos se encuentran al completo y que no han sido alterados. Aunque el fabricante establece que el propio transceptor tiene mecanismos internos para evitar alteraciones de los datos, en pruebas reales se demostró que algún que otro cambio o pérdida se producían. Para evitarlo, se desarrolló un sistema de seguridad que verificaba los datos (4.2) en la estación base, dependiendo solo de que el CanSat contara el número de dígitos y lo añadiera al final de cada línea. El problema con este transmisor fue la cantidad de datos que pudo mandar (ancho de banda), ya que, para un mayor alcance, la velocidad en el aire se tuvo que bajar al mínimo (2400 baudios = 240 caracteres por segundo) sacrificando el envío de los datos del segundo BMP280 y los datos completos del MPU9250 (magnetómetro, giróscopo y acelerómetro). Esto significó que al no recuperar el CanSat se tuvo que trabajar con la información limitada que se recibió. A diferencia de la velocidad en el aire, la velocidad del puerto serie se mantuvo en 9600bps debido a que el GPS necesitó de esa velocidad DHT22 Este sensor de humedad y temperatura es tan barato y conocido que hay millones de programas escritos para él. La librería usada fue la de Adafruit. El programa se adaptó para que recogiese los datos cada 2 segundos (tiempo mínimo entre medidas) y subiese sólo la humedad a la base de datos Raspberry Pi Camera Para usar la cámara, hay dos opciones: Mediante una herramienta del sistema que pone todas las utilidades de la cámara a través de un comando ejecutado en el terminal. Una completa integración de la cámara en Python, que pone todas las utilidades en comandos ejecutados en Python. 28

29 Si bien en un principio se decidió ir con la segunda opción, esta demostró ser la errónea. Por algún motivo, tras varias horas de estar encendido, el programa escrito en Python bloqueaba el sistema por completo, teniendo como única opción que reiniciar el sistema manualmente. En cambio, la integración de la cámara a través del terminal demostró ser muy estable en las pruebas. Por lo que se decidió integrar el comando raspivid en Python. Al igual que los programas independientes, el comando fue ejecutado usando subprocess. El script encargado de la cámara se ejecutó de forma independiente al programa principal. La línea que grababa y mostraba lo que la cámara veía fue la siguiente: sudo raspivid -w h v -t fps 30 -o /home/pi/videos/" + data + ".h264 g" sudo Concede permisos de administrados al comando raspivid Comando a ejecutar -w 1920 indica la anchura del video a 1920 píxeles -h 1080 indica la altura del video a 1080 píxeles (Full HD) -v Saca toda la información de lo que está ocurriendo con la cámara incluyendo una visualización en la pantalla, enviado a través de la salida de video de la Raspberry Pi al transmisor de video. -t Graba un video por 5 minutos (300000ms = 300s = 5m) -fps 30 graba el video a 30 fotogramas por segundo -o /home/pi/videos/" + data + ".h264 guárdalo en el directorio /home/pi/videos/ con nombre de la variable data y extensión.h264 -g Una opción nueva que permite a fotogramas muy similares (como todos negros) incluirse en uno solo ahorrando muchísimo espacio. La integración de este comando en Python permitió también la opción de guardar los videos con nombres diferentes. El nombre fue un número guardado en un documento, recordando así el último nombre usado tras apagar el sistema. Muy conveniente para no sobrescribir ningún dato de video. 29

30 4. Estación base (Ground Station) Para recibir los datos enviados por el CanSat se decidió desarrollar una aplicación para Windows, de tal forma que procesara los datos en tiempo real dibujando varios elementos con estos. Esta aplicación fue la parte del proyecto que más tiempo consumió. Para desarrollar la aplicación se utilizó el sencillo, pero no tan simple, entorno de desarrollo llamado Processing. Este entorno usa su propio set de comandos basados en Java, aunque también se puede programar en Java de forma directa. Processing es fantástico para desarrollar interfaces gráficas debido a su simplicidad de comandos gráficos, pero puede quedar escaso de utilidades si se necesita ir más profundo. La aplicación pasó por muchas versiones, pero en este documento solo se describe la última de ellas Hardware La estación base constó de varias partes que juntas hicieron posible la retransmisión de los datos de forma visual. El siguiente esquema describe el funcionamiento general de la estación base: Los datos se reciben por un canal diferente al del video. Es por eso que dos antenas y dos receptores son necesarios. Para los datos se usó una antena tipo Yagi de 433 MHz que iba conectada al receptor/transmisor APC220 (el mismo que 30

31 equipó el CanSat). El video fue transmitido por el CanSat en analógico a una frecuencia de 5.8 GHz. Para recibir en un principio estaba planeado usar una antena helicoidal, pero debido a las interferencias que la antena Yagi producía (ambas iban colocadas una junto a la otra para apuntar bien), se hizo un cambio de última hora sustituyéndola por una de tipo parche, también directiva. La antena fue conectada al RC832, un receptor de 5.8 GHz con salida de video analógica. El APC220 usa el protocolo serie como comunicación, para ello se conectó a un FTDI (conversor de UART a USB), que conectado al ordenador permite extraer los datos a través de un puerto COM (comunicación). El RC832 fue conectado a una captura de video (EasyCap) que junto a un decodificador de vídeo permitió ver en el ordenador el video enviado por la cámara del CanSat Software La parte más complicada de la estación base fue la aplicación escrita en Java que se encargó de recoger los datos, procesarlos y dibujar una interfaz gráfica sencilla (7.2.1). En este documento no se describe el funcionamiento al completo ya que el código se encuentra comentado en el repositorio oficial. El funcionamiento general del programa es el siguiente: 1. Los datos se reciben en el módulo de puerto serie de Java, el cual copia en una variable todos los datos hasta el final de línea ( /n ). Esta variable es después descompuesta en un array (conjunto) de variables tipo string (texto). 2. Para comprobar los datos, el programa compara el tamaño del array (número de variables en el conjunto) con el que debería ser, además cuenta los caracteres de la variable recibida y lo compara con el último número. Por último, el identificador, o el primer dato debe coincidir (datos) (diagnóstico de los sensores) usado para identificar los datos enviados por La Burgoneta Espacial y no otro CanSat. Como se sabe que todos los datos han de ser numéricos, una segunda comprobación convierte las variables de string a float (numéricas), de tal forma que, si se convierte un dato no numérico, este inducirá a error, momento en el que el programa cancelará el procesado de datos (en este caso, se usarán los valores anteriores para continuar las gráficas). Por último, una tercera comprobación va todavía más profundo. Como 31

32 los datos del giróscopo oscilan entre 180 y -180, comprobar que el valor se encuentra entre dichos valores da todavía más fiabilidad al test. 3. Una vez comprobados los datos el programa los utilizará para continuar las gráficas, dibujar los velocímetros, el estado de los sensores, la capacidad de la batería, la altitud, además de un horizonte artificial y una brújula. 4. Para una correcta localización temporal, el programa obtendrá la hora y fecha desde el reloj del ordenador y la dibujará. Esto permite a futuros espectadores localizar temporalmente el lanzamiento. 5. El programa además de lo descrito anteriormente consta de dos módulos: a. El primero de ellos es una barra de progreso que permite al espectador saber en qué fase del descenso se encuentra la retransmisión. b. El segundo módulo más llamativo fue la integración de Google Earth a la estación base, dibujando una trayectoria en tiempo real de la caída del CanSat. El código original fue escrito y publicado por Andrew Herman. Teniendo el concepto en mente, el código fue rescrito y adaptado completamente para hacerlo más simple además de añadir varios detalles más como la línea de la trayectoria, los colores, el icono de la lata y el nombre indicando la velocidad horizontal. El funcionamiento interno es el siguiente: o Recoge los datos recibidos desde el GPS del CanSat. La latitud, longitud y altura son importados a una variable que añade los datos a los anteriores en el formato correcto y la velocidad horizontal especifica el nombre. o Cambia el ángulo de rotación de la cámara que observa la trayectoria en 5 grados. o Guarda toda la información en un formato concreto (para que la aplicación Google Earth pueda interpretar) en un documento de extensión.kml. o Ejecuta el archivo a través de un terminal oculto usando el.exe de Google Earth, lo que resulta en una importación en tiempo real de la trayectoria que Google Earth dibuja sustituyendo la anterior. El ciclo se repite cada vez que se recibe una línea nueva. 32

33 Para decodificar el video proveniente de la capturadora EasyCap, se usó el reproductor de video Media Player Classic, el cual permite reproducir el video en directo desde una capturadora y guardarlo en un archivo. La siguiente y última parte de la estación base consiste en la captura, creación y retransmisión del video en directo. Para la realización de dichas tareas se usó un programa llamado Open Broadcaster Software (OBS). Este programa permite capturar ventanas de forma independiente, aplicar filtros tales como recorte o color de fondo, y crear una pantalla independiente (pudiendo tener varias intercambiables) la cual se retransmite a sitios web como YouTube. Para retransmitir el video, OBS capturó: 1. El programa hecho en Java, que fue recortado en diferentes partes aplicando filtros de transparencia. 2. Google Earth, recortando la ventana a solo la trayectoria. 3. La cámara web, que fue intercambiada manualmente por el vídeo recibido del CanSat en los momentos en los que no se recibía nada. 4. Media Player Classic recortando la ventana a solo la reproducción del video recibido. Todas las partes se pusieron en orden en la aplicación ajustando la resolución a 1920x1080 píxeles. Que junto a la imagen de fondo y el logo conformaron lo que los espectadores visualizaron el día del lanzamiento (7.2.2) Problemas En las horas previas al lanzamiento se tuvieron varios problemas con la retransmisión. Investigando se llegó a la conclusión de que el ancho de banda de la conexión a Internet era inferior al esperado, ya que, al estar conectado con el móvil en roaming la velocidad se vio reducida. La solución fue disminuir la calidad del video enviado de 1080p a 720p, manteniendo la resolución de 1080p en la creación del vídeo. Además de esto, se tuvo que reducir el bitrate (cantidad de bits por segundo del vídeo). Aunque el vídeo si se transmitía bien tras estos ajustes, seguía habiendo pequeños parones. Tras analizar el espectro, se determinó que en un espacio tan reducido como el hangar, y con tanta gente usando sus teléfonos como módem, ocasionaba que las Wi-Fi transmitieran unas encima de otras, reduciendo notablemente la velocidad. La solución fue cambiar la banda de Wi-Fi de 2,4GHz a 33

34 la menos ocupada de 5GHz. Con estos ajustes el video se retransmitió sin problema alguno. 5. Resultados De todos son conocidas las luces y sombras de los programas en Marte y la suerte que las distintas misiones han corrido. Nuestro CanSat no iba a ser una excepción y además de los fallos mecánicos que se explican a continuación, la mala suerte quiso que el CanSat no pudiese recuperarse al caer sobre una zona edificada ajena al aeropuerto. Es ya evidente que los datos no se pudieron recuperar al completo lo que deja, una lección muy importante: el coste de las misiones espaciales es alto, por lo que cuando una situación como esta se presenta lo poco que se puede hacer es aprovechar los datos y sacarles el máximo partido obteniendo la mayor cantidad de parámetros y conclusiones posibles. Siguiendo la lección, uno debe en este tipo de situaciones obtener una conclusión, y hacer valer la inversión en el proyecto. Por muy lejos que estas se encuentren de la realidad, al menos se sabe algo más sobre lo desconocido Fallos mecánicos He de admitir que aun estando el CanSat diseñado para evitar el mayor número posible de errores, sufrimos de igual manera fallos críticos en el día del lanzamiento. Dadas las condiciones climáticas del día del lanzamiento, se tuvo que encapsular el CanSat. Usando un plástico flexible transparente, se dejó solo un pequeño agujero para la entrada de aire del MQ135, así como para la antena GPS. Esto supuso un enorme sacrificio en la precisión de los sensores. El segundo de los errores fue la fiabilidad de los portapilas. Antes del lanzamiento se realizaron múltiples pruebas de aceleración, y aun pasándolas la aceleración del cohete provocó la desconexión de las mismas. El problema de los portapilas fue, que al no saber bien la orientación del CanSat en el interior del cohete se colocaron los muelles en la parte equivocada, provocando su compresión durante el ascenso que desplazó las pilas desconectándolas de la chapa metálica 34

35 en el polo contrario. Afortunadamente, el CanSat estaba programado para reiniciarse solo, perdiendo la mitad de los datos y un tercio del video. El tercer error está basado en la hipótesis de que las tapas en de los portapilas en el interior del CanSat saltaron al chocar lateralmente con el edificio (probablemente debido al descuido de no soldar el plástico con super-glue), provocando una pérdida de energía permanente. Esto trajo consigo la consecuencia de no poder descargar los datos remotamente del CanSat, al ir este equipado con Wi-Fi Misión primaria La misión primaria de medir temperatura fue un fracaso. El CanSat equipó dos sensores de temperatura. El primero de ellos en orientación horizontal y el segundo junto a la entrada de aire. El error de no cambiar los datos Temperature & Altitude , , Altitude Temperature enviados al cercano a la única entrada de aire supuso malas mediciones de temperatura. Confié además en la recuperación del CanSat, ya que la temperatura de ambos sensores se guardaba. De los datos recibidos, la temperatura obtenida fue demasiado alta, aunque cabe mencionar la disminución de la misma durante el descenso. Muy probablemente indicando que la temperatura exterior es menor a la interna del CanSat. Por otro lado, la presión obtuvo buenas mediciones. Las mediciones del barómetro coincidieron con las del GPS, aun estando el CanSat cerrado herméticamente. La conclusión que se puede obtener es que la presión es mucho más susceptible que la temperatura a los cambios, ya que la regulación del medio interno es mucho más rápida. 35 METROS Altura de GPS y barómetro LÍNEA RECIBIDA (0,5S) Altura GPS Altura Barómetro Presión MILIBARES

36 5.3. Misiones secundarias Retransmisión en vivo Esta parte del proyecto fue todo un éxito. Si bien nuestro proyecto no tuvo la misma repercusión que un lanzamiento de la NASA, los más de 300 espectadores durante la retransmisión fueron más de los esperados. Y junto con las más de 2000 visualizaciones posteriores, esta parte del proyecto fue un rotundo éxito. El video fue mucho más entendible que el anterior. De hecho, muchos espectadores se dieron cuenta del fallo en las baterías. Cabe destacar la trayectoria en directo, que fue muy bien recibida Localización 3D Las mediciones del GPS fueron muy precisas, llegando hasta decímetros de precisión. Esto se sabe tanto por el número de satélites que usó para el cálculo de la posición (8 durante todo el descenso) como por la ausencia de obstáculos que puedan reflejar la señal. Esta precisión sirvió de ayuda para determinar las alturas incluso con más precisión que el barómetro, ya que este es mucho más preciso por lo general que el GPS. La Burgoneta Espacial fue el único CanSat capaz de mandar la información del GPS de forma precisa, permitiendo una localización exacta del punto de caída, que por mala suerte fue el porche de un almacén sin ningún método de acceso Mapa topográfico Elaborar un mapa topográfico 3D con las imágenes recibidas resultó imposible debido a la mala calidad del video recibido provocada por el sellamiento hermético colocado en frente del objetivo de la cámara. Aun sabiendo el fracaso de 36

37 esta misión, se decidió intentar hacer una reconstrucción de la zona en 2D. Para ello se extrajo fotograma a fotograma del video recibido, y desechamos los de mala calidad se obtuvieron unas 20 imágenes, con ayuda del mapa desde Google Earth, se fue ajustando la perspectiva a mano con Gimp reconstruyendo gran parte del mapa. Aunque la calidad de las imágenes no fue la deseada, estas pueden servir para determinar un buen lugar de aterrizaje para futuras misiones. Como dato anecdótico, en la reconstrucción del mapa se determinó la aparición de nuevas construcciones en la zona no presentes en el mapa de Google Earth Determinar la posibilidad de vida La misión más importante de La Burgoneta Espacial fue la de determinar la posibilidad del planeta de sustentar vida basándose única y exclusivamente en los datos recolectados por el CanSat. Gravedad La primera de las propiedades a determinar fue la aceleración de la gravedad en la superficie del planeta. Esta es elemental en muchos aspectos para el desarrollo de la vida, pero también esencial para la habitabilidad humana. Se tenía previsto calcular la aceleración de la gravedad en los segundos previos a la apertura del paracaídas, que corresponden con una caída libre. Desafortunadamente, el CanSat se reinició en el ascenso, perdiendo el único momento evidente. Tras mucho pensar e investigar se decidió calcular la gravedad de una manera más enrevesada. Lo primero que hay que tener en cuenta son las fuerzas que se aplicaron en el CanSat durante su descenso: 37

38 Como se puede apreciar, solo dos fuerzas afectaron al CanSat de manera directa durante su descenso (despreciando todas las demás al ser mínimas o estar en la normal del movimiento). La primera de las fuerzas es la de rozamiento, para calcularla se puede usar la ecuación experimental de resistencia aerodinámica: En donde F r es la fuerza de rozamiento, v la velocidad en m/s a través del fluido, S la superficie en m 2 en contacto con el fluido de forma frontal y C r el coeficiente de rozamiento del objeto. La densidad del fluido (en este caso atmósfera) no fue recogida por el CanSat, al igual que la superficie y coeficiente de rozamiento (marcadas en rojo). Pero al ser una ecuación experimental, y ser dependiente de la densidad, se puede replicar el lanzamiento en otro fluido y obtener el coeficiente. En pruebas antes del lanzamiento se determinó un coeficiente aproximado de 1,3 para los 0,1 m 2 de superficie (incluye también la base del CanSat). Lo único que queda entonces por determinar es la densidad de la atmósfera. Para calcular la densidad, se puede emplear la ecuación barométrica obtenida a su vez de la ley de los gases ideales y las constantes moleculares: En donde P es presión en Pa, ρ la densidad en Kg/m 3, g gravedad en m/s 2 y h la altura en m Con esta ecuación se puede obtener la densidad, pero requiere además de la gravedad, el incremento de presión y la altura real. Sabiendo que el CanSat descendió 175,4 m en 27 segundos momento en el que la presión aumentó 1624 Pa, queda por saber la densidad y la gravedad. 38

39 Para resolver el problema, hay que fijarse en las alturas enviadas por el CanSat: Vertical Speed & Altitude Series1 Series2 Como se puede apreciar la velocidad fue aproximadamente constante de 6,5 m/s (las variaciones entran dentro de la imprecisión del GPS), lo que significa que el descenso fue controlado. La no disminución o aumento de la velocidad implica que la fuerza de reacción (rozamiento) fue equivalente a la fuerza de la gravedad, siendo esa la velocidad equilibrio. Ahora sí, sabiendo que la masa del CanSat fue de 0,3 Kg se puede convertir a una aceleración la fuerza y realizando un sistema de ecuaciones se resuelven las dos incógnitas (gravedad y densidad de la atmósfera): F = F = m g ; 1 2 ρ P v S C = m ρ h ; 1 2 ρ 6,5 m s 0,1 m 1624 Pa 1,3 = 0,3 Kg ρ 175,4 m ; g = P ρ h = ρ = 1,006 Kg/m 3 1,006 Kg m 1624 Pa = 9,21 m/s 175,4 m Ambas son similares a las de la Tierra de ρ =1,2 Kg/m 3 y g =9,8 m/s 2, lo que indica que son adecuadas para sustentar vida, pero sobre todo, correctas para ser habitado el planeta por humano. 39

40 Atmósfera Una vez obtenida la densidad de la atmósfera (en la superficie), usando la ley de los gases ideales, con la presión media de Pa, la temperatura registrada de 310 K y la constante correcta, se puede calcular la masa molar de la atmósfera: m = =,, = 0,0264 Kg mol = 26,4 g mol La masa molar es similar también a los 28.7 g mol de media en la Tierra. Una vez que tenemos la masa molar, junto a la temperatura podemos determinar aproximadamente qué gases pueden componer la mezcla del aire en el planeta (si es que es una mezcla). De la tabla periódica el Hidrógeno, Nitrógeno, Oxígeno, Flúor, Cloro y todos los gases nobles son gases a la temperatura de 37ºC registrada por el CanSat. La mezcla es mucho más difícil de determinar, pero desde luego, la probabilidad de que haya Oxígeno en la atmósfera es alta. Para futuras misiones sería bueno incluir un sensor de oxígeno para determinar el porcentaje en la atmósfera. Volviendo a la masa molar, sabiendo que la mayoría de los elementos dañinos para el ser humando tienen una mayor masa molar, exceptuando el flúor y cloro. En cualquier caso, su masa molar en estado gaseoso es mucho mayor a la obtenida, asegurando que su concentración es poca en la mezcla o que incluso no se encuentran presentes. El sensor de CO2 midió también gases contaminantes como hidrocarburos. Su medición media de 303,51 ppm nos indica que la concentración de estos gases no es nula. Como a partir de este punto no se puede determinar ningún dato fiable, podemos suponer que gran parte de medición corresponde con CO2 al ser este uno de los compuestos más comunes en otros planetas, y, sobre todo, que el sensor es más sensible a este gas. Si el CO2 se encuentra presente, entonces es probable que se produzca el efecto invernadero en el planeta, muy importante para la vida. HASTA AQUÍ Agua El agua es vital para la vida. Cuando se descubre un planeta nuevo, la primera pregunta es siempre la misma, hay agua líquida en la superficie? El 40

41 CanSat incorporó un sensor de humedad, cuyo objetivo fue el de medir la presencia en la atmósfera y no la cantidad. Las mediciones de 5,5% de humedad relativa implican que en la atmósfera si existe vapor de agua, pero al no saber exactamente las propiedades del aire, no se puede determinar la concentración. Una vez conocido la presencia del agua, lo relevante no es su estado gaseoso, sino el líquido. Usando la temperatura de 37 ºC y presión de 982 hpa se puede aproximar el estado predominante del agua en la superficie del planeta: Para el planeta visitado, el punto se situa dentro del triángulo triple de los tres estados, indicando que, aunque su mayor concentración sea en forma líquida, también puede presentarse en forma de vapor y sólida, que confirma el sensor de humedad. El planeta es muy probable que tenga presencia de agua líquida, lo que lo convierte en un muy buen candidato habitable. Campo magnético Otro factor muy importante para la vida es la presencia de un campo magnético en el planeta. Como sucede en la Tierra, el campo magnético atrapa a partículas cargadas provenientes del Sol (Viento Solar) en el llamado cinturón de Van Allen. Esto es muy importante, ya que su ausencia provocaría la extinción de la biología tan y como la conocemos. El CanSat equipó un magnetómetro para determinar la intensidad del campo magnético en tres ejes. Desafortunadamente la intensidad del campo magnético no se obtuvo debido al límite de datos enviados. 41

42 Aun así, si se recibieron datos de la brújula, obtenidos a partir de la intensidad del campo magnético. Y al mostrar esta una determinación por una dirección concreta, indica que en este planeta en cuestión si existe un campo magnético, del que se desconoce su intensidad. Radiación UV La radiación UV es un factor muy importante para la habitabilidad humana en la superficie. Las mediciones de radiación UV del sensor sin protección (UVA + UVB + UVC) mostraron picos de 1,4 en el índice UV, lo cual es insignificantes al encontrarse estas dentro del rango bajo (un día soleado en la tierra puede alcanzar 10 o incluso más en el índice de UV). UV 1,6 1,4 1,2 1 0,8 0,6 0,4 0, UV UVA+UVB UVC El UVC es el espectro más dañino al ser las ondas más energéticas. El CanSat calculó el UVC haciendo la diferencia entre el sensor sin filtro y con filtro. Las mediciones de UVC fueron de aproximadamente 0,5 en el índice de radiación UV que es igual a aproximadamente 12 mw/m 2. Poca información hay sobre los valores máximos de radiación UVC, pero la media en la Tierra en pleno día soleado es de 200 mw/m 2. Según un estudio de 26 personas expuestas a grandes dosis de radiación UVC, alrededor de 1400 mw/m 2 serían dosis letales a largo plazo. Si bien los estudiantes sufrieron quemaduras entre otros síntomas, después de dos a cuatro días se recuperaron. Esto demuestra que dosis de alrededor y más de 1400 son cancerígenas para el ser humano, pero no letales si es durante un pequeño periodo de tiempo. Por lo que, según las medidas obtenidas por el CanSat, el planeta presenta algún tipo de protección contra la radiación UVC en la atmósfera, haciendo posible la habitabilidad sin una capa protectora. 42

43 Conclusión Esto es lo máximo que se pudo concluir a partir de los datos recibidos, que, aunque no son suficientes para determinar la habitabilidad del planeta, sí que son indicadores que este planeta es de momento un muy buen candidato para sustentar vida, ergo futuras misiones a este planeta es muy probable que ocurran. 6. Resultado del concurso y conclusiones En ningún momento se tuvo claro la posibilidad de presentar el prototipo el día del lanzamiento, ni mucho menos ganar el concurso. La semana anterior, no había ningún prototipo montado, teniendo inacabado el diseño de la lata y el software de la estación base. El tiempo disponible para desarrollar el CanSat fue escaso, ya que se perdió mucho tiempo ideando el proyecto. Una mayor dedicación habría supuesto un diseño más elaborado al permitir la realización de la muy importante fase prueba-error, cuya ausencia mostró más tarde sus consecuencias. Al no tener el CanSat montado, la tensión durante los primeros días del concurso y el ajustado horario conllevaron a múltiples errores: El mal montaje de los portapilas. El diagnóstico del sistema enviado tras el reinicio indicó el perfecto funcionamiento de todos los sensores, lo que implica que el CanSat se reinició debido a la desconexión de las pilas durante el ascenso, perdiendo así una gran suma de datos importantes. Los muelles se colocaron en la parte incorrecta, lo que provocó la desconexión del polo opuesto durante el ascenso al comprimirse estos debido al peso de las pilas. Aunque se puede considerar un problema, el reinicio fue satisfactorio sirviendo como demostración del correcto diseño del Software. El fallo mecánico del circuito de apagado selectivo para el transmisor de video, obligando a la permanentemente conexión del transmisor de video, acortando la vida útil del CanSat y generando una gran cantidad de calor en el interior del CanSat, que a su vez provocó las malas mediciones del sensor de temperatura. Mal encaje de la tapa inferior y mala distribución de los componentes en el interior provocando tensión en la tapa superior. Esto hizo que el tamaño fuese más de lo permitido. Ambos se solucionaron acortando los muelles. 43

44 El descuido de no pegar las tapas de los portapilas, desconectando las pilas en el momento del aterrizaje haciendo imposible recuperar los datos inalámbricamente mediante Wi-Fi. Otros problemas vinieron a raíz de sellar herméticamente el CanSat para evitar cortocircuitos con la lluvia: Nula regulación del medio interno del CanSat, provocando las malas mediciones del sensor de temperatura y humedad. La mala calidad de la cámara de video al poner el plástico por encima de esta. Respecto a los aciertos, cabe mencionar: El software de la estación base, que demostró ser fiable y funcionar de manera correcta. Un posterior análisis del video retransmitido a través de YouTube demostró que todo, a excepción de unos pequeños errores con las unidades y la primera gráfica, funcionó de manera correcta. Respecto al hardware del CanSat, todos los sensores funcionaron perfectamente y el diseño demostró ser robusto y resistente. El único problema fue el DHT22, cuyas mediciones no coinciden con las medidas por otros equipos. El calor pudo ser el responsable de tan bajas mediciones, pero hasta que no se recuperen los datos del CanSat, no hay forma de averiguar qué lo provocó. De los datos recibidos cabe mencionar que desde el reinicio se recibieron todos los datos enviados por el CanSat exceptuando una única línea, demostrando el correcto funcionamiento de las antenas. Como puntos negativos destacan: El lugar de aterrizaje. Aunque a fecha de este documento no se ha recuperado el CanSat, se espera poder recuperarlo en algún momento, no por los datos, sino más bien como recompensa del trabajo realizado. La tarjeta SD en donde se guardó la información es resistente tanto al agua como al calor. Las conclusiones presentadas al jurado. Cabe mencionar que lo redactado en este documento es una revisión mucho más exhaustiva, y las conclusiones presentadas al concurso no fueron las mismas. Se cometieron errores debido al poco margen de tiempo, presentando así información incorrecta o mal explicada. 44

45 Aunque el jurado no expuso los motivos que nos llevaron a ganar, a mi parecer fueron los siguientes: - Un modelo robusto que sobrevivió las condiciones medioambientales del día. Así como a la pérdida de energía en el lanzamiento. - La ayuda que ofrecimos a otros equipos, aunque supusiera darles ventaja además de agradecer a aquellos equipos que nos ayudaron. - La recuperación hábil de datos aún sin recuperar físicamente el CanSat. - El intento en la presentación de llegar a conclusiones coherentes en el tiempo que se tuvo la noche anterior, así como el intento de hacer un mapa topográfico con las fotos recibidas del CanSat aun sabiendo el fracaso de la misión. - La innovadora idea de retransmitir el momento en vivo haciendo accesible el proyecto a cualquiera. - La increíble precisión del lugar de aterrizaje, al ser el único equipo cuyo GPS funcionó de manera correcta. Esto es debido a que todos vienen con un límite de aceleración, si lo sobrepasan se apagan. Tuvimos la suerte de que el GPS escogido se reiniciaba tras la aceleración, lo que nos dio una gran ventaja sobre aquellos que se apagaron permanentemente. Los datos que recibimos se encuentran en un documento disponible en nuestra web ( y los videos relevantes en el canal de YouTube ( En caso de necesidad de algún dato concreto, contacte al correo: efren@boyarizo.es 7. Anexos 7.1. Protocolos Inter-Integrated Circuit (I 2 C) El I 2 C es un protocolo muy usado para la comunicación entre pequeños componentes. Necesita tan solo dos cables (SDA y SCL) para comunicarse (a parte de la alimentación). Funciona de la siguiente manera: 45

46 Hay un maestro quien controla todos los sensores y por lo tanto controla el SCL que corresponde con el reloj, que transmite los pulsos correspondientes con la frecuencia del envío de datos. De esta manera se sincronizan el cliente y maestro para recibir y enviar la información, lo que permite el uso de varias velocidades para componentes conectados a una misma línea. Por el cable SDA se manda la información. Cada componente usa una codificación diferente para los datos, normalmente detallada en el datasheet. El funcionamiento del protocolo se explica mejor con un ejemplo: se quiere recibir un número de un sensor, correspondiente con el voltaje. Para ello, lo primero es bajar el voltaje del cable de datos, que indica el principio de una comunicación. Acto seguido, el voltaje varía en base a si es un 1 o 0, siempre sincronizado con las oscilaciones del reloj. El primer dato que se envía es la dirección, como si fuese la calle en la que vive el sensor. Esta dirección es un número de 7 bits que se convierte a hexadecimal para ser leído con mayor facilidad por el usuario. En el caso del GY- 91, el MPU9250 tenía la dirección 0x68 (los dos primeros dígitos no tienen utilidad alguna para el usuario y los dos últimos indican en hexadecimal la dirección). Después de la dirección se indica con un 1 que se va a leer. Acto seguido se baja el SCL y se vuelve a subir indicando el comienzo de la transferencia de datos, es aquí donde el sensor nos mandará el dato en binario. Al ser un único número, el byte se convierte a decimal para ser leíble. Este es un ejemplo muy simple, y en la realidad cada sensor incorpora una forma diferente para obtener la información. 46

47 En los datasheet se puede encontrar información muy detallada de cómo manejar el protocolo para un sensor concreto. Afortunadamente, la comunidad de Arduino ofrece una posibilidad mucho más sencilla, el uso de librerías. Estas librerías incorporan todas las funciones del sensor de manera que sean mucho más accesibles al usuario Comunicación Serie (8N1) El protocolo serie consta dos cables (además de la alimentación), uno para transmitir y el otro para recibir información. A diferencia del protocolo I2C, en este la velocidad se tiene que ajustar manualmente en ambos componentes, pero a cambio permite trasmitir información al mismo tiempo en ambas direcciones sin necesidad de identificaciones o secuencias de peticiones. Como aspecto negativo se sacrifica la posibilidad de conectar más de un dispositivo (suele usarse solo para comunicación entre dos dispositivos). La versión 8N1 usado en el CanSat (y la mayoría de Arduinos), consta de un funcionamiento relativamente sencillo. Imaginemos que se quiere enviar la letra O en mayúsculas y la letra K también en mayúsculas. El primer paso es convertirlos a binario: O K Para enviar la información solo se tiene que añadir dos caracteres, uno que indica el inicio de cada byte que es siempre un 0 y otro que finaliza el byte y es siempre un 1. En el osciloscopio se vería de la siguiente forma: 47

48 Cuando la línea está en reposo, en esta versión el voltaje se mantiene alto. La mayoría de los microprocesadores actuales incorporan en su interior lo que se denomina un puerto serie por hardware. Esto no es más que un pequeño módulo añadido al procesador para hacer el protocolo mucho más sencillo- de usar y sin consumir muchos recursos, los microcontroladores y el CPU de la Raspberry Pi incorporan lo que se denomina puerto serie por hardware. Esto no es más que un módulo integrado en el interior del circuito integrado que se encarga de manejar el protocolo liberando al CPU de esta tarea. Algunos incluso poseen un búfer en donde se almacena los datos recibidos hasta que son solicitados. El puerto serie se puede recrear por Software, pero requiere que el procesador esté atento en todo momento para leer la información, lo que provoca una carga innecesaria si se posee puerto serie por hardware Imágenes 48

49 49

50 7.3. Código Por problemas de espacio y formato, este anexo se encuentra en el repositorio oficial de la Burgoneta en GitHub: 8. Bibliografía Protocolos Serie: NMEA: I 2 C: Datasheets ADS1115: BMP280: 11.pdf BME280: 10.pdf MPU9250: MPU-9250A-01-v1.1.pdf MQ135: MQ135/resources/SNS-MQ135.pdf APC220: Raspberry Pi Zero: u-blox NEO 6: blox.com/sites/default/files/products/documents/neo-6_datasheet_(gps.g6-hw ).pdf DHT22: UV: LM2575: 50

51 LM7805: Código MPU9250: BMP280 y BME280: ADS1115: DHT11/22: Raspberry Pi Camera: Google Earth kml: Investigaciones Principios físicos Otros links Agradecimientos Me gustaría agradecer a todos aquellos que ayudaron de alguna manera u otra a hacer posible este proyecto. Especialmente a: 51

52 Carmen Méndez Martín por ser la directora del proyecto y ayudándome en todo. Mis compañeros por haber trabajado tan duro. Nada habría sido posible sin su trabajo. Y por dejarme realizar este trabajo de un proyecto conjunto. Francisco Viñas, dedicando muchas horas de su tiempo libre en hacer posible este proyecto. Ventura que sacrificó su cuadricóptero por el bien de este proyecto. Eugenio que corrió en el último momento para comprar componentes minutos antes de que cerraran la tienda. Enrique que se quedó con nosotros en aquellas interminables tardes ayudando en lo necesario. Javier Machón, por dejarnos en las clases de lengua probar el CanSat y corregirme ortografía y sintaxis del proyecto. También quiero agradecer a la dirección del centro por mostrar ese apoyo, que consiguió que saliésemos adelante. Gracias a todas las empresas, asociaciones y especialmente al ayuntamiento por apoyarnos, aun siendo un equipo tan pequeño y poco conocido. 52