sábado, octubre 24, 2020

Documentando (0): Algunas ideas previas

Existen muchos artículos y libros que enseñan a documentar el código, e incluso estándares que intentan poner un poco de orden en cómo se tiene que documentar un proyecto de ingeniería. Esta serie del blog no intenta hacer un nuevo estándar o ser una referencia para los demás. Simplemente sirve para ordenar mis propias ideas de cómo lo tendría yo que hacer... Lo único que en vez de guardarlo para mí sólo (como hasta ahora lo estaba haciendo hasta ahora) he decidido exponerlo de forma pública a ver si a alguien más le puede interesar o aportar alguna idea.

Me voy a centrar principalmente las siguientes partes de la generación de un proyecto de electrónica:
  1. Programación del firmware. Aquí se va a utilizar principalmente C
  2. Esquemas (planos)
  3. Documentación de fabricación. Además de los gerbers y el BOM de una PCB yo entrego una serie de documentación adicional.
Las herramientas que utilizo para generar la documentación son:
  • Doxygen (https://www.doxygen.nl/). Para generar la documentación a partir de comentarios en el código. Es fácil de aprender a usar y, si te quieres meter a fondo, tiene un montón de posibilidades. 
  • PlantUML (http://www.plantuml.com/). Se integra muy bien con Doxygen y permite hacer un montón de tipos de diagramas UML simplemente describiéndolos en el texto.
  • Dia (https://wiki.gnome.org/Apps/Dia). Cuando no pueda o no quiera describir un diagrama con PlantUML los dibujaré con esta aplicación.
  • Libre Office (https://es.libreoffice.org/). Algunos documentos tienen que ser escritos a mano así que...
La mayor parte de la documentación se realiza sobre el documento de trabajo (ya sea el código, los esquemas o la PCB) así que además pondré las formas que utiliza para documentar.

También iré añadiendo algunas otras cosas como el control de versiones y organización de los documentos que se generan.

viernes, octubre 09, 2020

Proyecto de fin de semana: purificador de aire

Cuando realizas una soldadura lo que menos apetece es que te venga todo el humo a la cara: es molesto y sobretodo es nocivo. Tener algún sistema que aleje el humo y lo purifique es siempre muy recomendable.

Se puede empezar por mantener una ventana abierta, sin embargo esto depende mucho de si consigues una circulación de aire correcta, es decir, dependerá de la posición de la ventana con respecto a tu lugar de trabajo, de la cantidad de viento y de la dirección de este.

También puedes optar por una mascará que te proteja contra los humos, sin embargo dependiendo de la cantidad de humo que se genere sigue siendo molesto (además de tener una máscara puesta mucho rato).

Al final decidí hacer un purificador de aire...

En realidad es bastante sencillo de crear sólo necesitas un ventilador, una fuente para alimentarlo y un filtro.

Mi primer intento fue un ventilador alimentado a 220V y una tela de filtro para la campana extractora de la cocina

De esta experiencia aprendí varias cosas importantes:
  • Es preferible tener una estructura que fije todo el sistema.
  • Contra más grande sea la entrada de aire mejor.
  • Los filtros de campana de cocina no sirven. Seguia oliendo el humo de la resina y cualquier fuente de calor hacía que se derritiera.
Así que decidí comprar un filtro HEPA con pellets de carbón activo, un ventilador de 14cm,  y montar una estructura de madera para contenerlo todo:
  • Ventilador: ARCTIC BioniX F140. Escogí este porque me daba un mayor flujo de aire y una mayor presión 104 CFM/176 m³/h (@ 1800 RPM) que otros que había estado mirando. Además el hecho de ser de 14cm me daba pie a tener una entrada de aire bastante grande.
  • Filtro: https://www.amazon.es/gp/product/B075CY8GG2/. Lo escogí por tener el filtro HEPA más los pellets de carbón, lo cual hace que limpie el ambiente de humo.
  • Estructura de madera hecha con madera de balsa de 1cm de grosor. Escogí esta por un motivo: ya la tenía, sin embargo, estoy muy contento con el resultado, queda una estructura resistente y muy adecuada al look que tengo en el resto del escritorio.
  • Cola blanca para madera, tornillos para madera, tornillos de métrica 4 y tuercas de métrica 4
Como herramientas sólo necesitas un taladro, una sierra de marquetería con hoja para corte curvo (o en su defecto un cutter/cuttex), un destornillador de estrella y una llave para las tuercas que utilices.

Los pasos son sencillos, a partir de las medidas del filtro y del ventilador cortar las piezas (hay que tener en cuenta el grosor), este es el paso más tedioso y el que más me costó (se rompió la hoja de corte curvo y tuve que improvisar para hacer el corte del agujero del ventilador).


Pegar las piezas y atornillarlas (tornillos para madera). Como se puede ver en esta foto yo añadí un pre-filtro entre el ventilador y el filtro), no es necesario y posiblemente lo quite en el futuro (lo pegué). Además utilicé unos sargentos para mantener las piezas mientras la cola hacía efecto y lo reforcé todo con tornillos.

Por último montar el ventilador (tornillos y tuercas de métrica 4 e insertar el filtro (si las medidas están bien tomadas va a presión)

Lo último es conectar el ventilador a una fuente de 12V y probarlo. En mi caso estoy utilizando una fuente de PC, pero el consumo es muy pequeño (unos 250mA a 12V), así que cualquier fuente de 12V >0.5A (algo bastante común de encontrar) sirve.

Dado que siempre vamos a querer que nuestro ventilador funcione a la máxima potencia que pueda dar sólo necesitamos conectar los pines 1 y 2 del conector (1 <=> GND, 2<=>12V) dejando el resto al aire.

Al final el resultado ha sido bastante bueno: aparta el humo de mi cara, limpia el aire y el ruido no es demasiado molesto (sólo lo enciendo cuando necesito soldar), lo cual es de agradecer.
 



sábado, marzo 12, 2016

Buenas Maneras (II): Errores y excepciones

En C++, en JAVA y en C# (y supongo que en la mayoría de los lenguajes de alto nivel), existe una herramienta muy potente para la gestión de errores dentro de un programa: las Excepciones.

A decir verdad en C++ no pasan más que por ser un retorno de un int por una vía distinta a la habitual, sin embargo sigue siendo un camino a tener en cuenta. Hay que tener en cuenta que las excepciones no son necesariamente errores en una función, sino situaciones excepcionales y distintas al flujo normal del programa (la propia definición de la palabra lo dice).

He observado que algunos programadores utilizan las excepciones para devolver valores o ejecutar un código dentro del flujo normal del programa, y esto a mi modo de ver es un error muy grande.

Para hacerlo más claro voy a explicar un ejemplo:
Un programa que comunica el PC con un microcontrolador vía serie. Al enviar el PC una orden, el micro responde que la operación no se ha podido realizar de forma correcta. Algunos programadores utilizan una excepción para informar al usuario, lo cual es un error. En este caso deberíamos tener en cuenta los posibles casos que el micro pueda informar y tratarlos adecuadamente.
Debemos dejar las excepciones para resolver problemas que nos surjan fuera del flujo normal, e intentar dejar las respuestas de las diferentes partes del programa al margen de las excepciones.

Otro ejemplo un poco menos claro:
En el mismo programa de antes se debe tener en cuenta que el micro pueda estar desconectado u ocupado realizando alguna otra tarea. Esto generalmente provocará un TIMEOUT en la llamada al puerto serie. Muchos programadores utilizan una excepción para informar al usuario que el puerto no responde (en la propia excepción). Si bien el TIMEOUT es una excepción en sí misma, no se debe utilizar para informar al usuario, sino que, lo que se debería hacer es recoger la excepción y tratarla en el flujo normal del programa (reintentos de enviar el comando, informar al usuario, etc.).

En definitiva para una función cualquiera la cabecera debería seguir la siguente pauta:

tRespuesta Funcion(tParametros) throw tExcepcion

Donde tRespuesta definirá las respuestas normales de la función y tExcepcion definirá los errores y excepciones que no hayan podido ser tratados dentro de la función o que deban ser informados a otras funciones.

En C el tema cambia, ya que no existen las excepciones de forma nativa, así que u optamos por utilizar librerías externas que implementan macros para realizar esta función, o directamente nos montamos nosotros el sistema.

En mi caso he decidido hacer esto último de una forma muy sencilla: todas mis funciones devuelven un entero:
int Funcion(tParametros)

de tal forma que si el entero es un número negativo la función está devolviendo un código de error. Si la función devuelve 0 (OK) es un funcionamiento normal y dejo los números positivos para la devolución de otros resultados (por ejemplo números de bytes leidos de un puerto, número de estado de una máquina de estados, etc.)

De esta forma siempre puedo hacer el siguiente código:

#include "error.h"
return = foo(parameters);
if(return < OK) { // Tratamiento de los errores }

He incluso tratar cada uno de los posibles errores por separado con un switch-case-default.

Evidentemente reconocer los posibles problemas dentro de la función (punteros no válidos, indices fuera de rango, etc.) corre a cargo mío, pero es un sistema que me funciona bastante bien y muy simple y rápido de implementar.

Sólo hay que tener en cuenta que los valores a devolver por la función siempre tienen que ser enteros positivos y que si se necesitaran otro tipo de valores se deberá pasar un parámetro por referencia para guardarlos allí.

Un apunte, algunos microcontroladores tienen implementado una serie de traps, es decir funciones a las que se llaman cuando hacemos una operación prohibida (como una división por cero), estas traps ya hacen de excepciones (aunque en realidad son errores graves) por lo que se debería no intentar que saltasen nunca ya que hacerlo debería significar hacer un reset del programa.


S2

Ranganok Schahzaman

sábado, marzo 05, 2016

Entendiendo... los Osciloscopios (III): cuantificación

Una vez que hemos determinado el muestreo, el convertidor analógico-digital (ADC) tiene que cuantificar el valor de la señal recibida (dado que ha de pasarlo a información digital), y como no tenemos una memoria infinita truncará la resolución con la que se adquiere la medida.

Dependiendo del número de bits que resuelva el ADC se tendrán más o menos niveles. Por ejemplo para un ADC de 8 bits se tienen 256 niveles posibles de tensión, para uno de 10 bits 1024 niveles, etc. (a razón de 2^n niveles). Es decir, si ponemos una señal rampa (continúa) a la entrada del osciloscopio, el ADC lo digitalizará de la siguiente forma:

Cuantificacion Midthread
Niveles de cuantificación con 4 bits
Los escalones serán más finos cuantos más niveles (más bits de información por muestra) tengamos. Con cada bit extra se dobla el número de niveles, por lo tanto queda claro que nos interesan un ADC del máximo número de bits posibles.:
2-bit resolution analog comparison3-bit resolution analog comparison
Cuantificación de una
señal senoidal con  2 bits
Cuantificación de una
señal senoidal con  3 bits
Además hay que tener en cuenta que, aunque aquí se muestra todos los niveles de cuantificación disponibles para la señal, en un osciloscopio la cuantificación se realiza para el fondo de escala (es decir para lo que se muestra en pantalla), por lo que para la señal los bits disponibles siempre serán menos.

Aquí nos encontramos con el problema de siempre: no lo podemos tener todo, los ADC's tardan un tiempo en cuantificar la señal, y este tiempo augmenta según augmenta el número de bits, por lo que tener un ADC de 6GS/s y 24bits será tremendamente complicado (y muy muy caro). Así que debemos preguntarnos que cuál es la resolución y la velocidad que necesitamos para nuestra aplicación -evidentemente 6GS/s y 24bits servirán para practicamente todas las aplicaciones que necesitemos, sin embargo ¿necesitamos tantos datos?-.

Por un lado ¿cómo de rápidos serán los cambios? No es lo mismo leer una señal térmica (que toma algunos segundos en variar) que una "glich" en la señal, por lo que necesitamos un ancho de banda suficiente para detectar la señal (ya hemos hablado de esto y como mínimo necesitamos el doble del ancho de banda de la señal).

Además de eso, de que magnitud es el cambio para que sea relevante respecto a nuestra señal principal:
  • En una señal de 5V con 8 bits tendremos 256 niveles, es decir que cada bit corresponderá a unos 20mV (5V/256 = 19.53mV) de resolución
  • Si utilizamos 10bits tendremos 1024 niveles que cada bit corresponderá a unos 5mV (5V/1024 = 4.88mV)
  • Para 12bits, es decir 4096 niveles, la resolución será de aproximadamente 1mV (5V/4096=1.22mV), etc.
¿Realmente necesitamos ver la variación de 1mV sobre una señal de 5V (un 0,02% de la señal)?

Por lo que debemos tener una idea de la variación necesaria de la señal para que esta sea suficientemente importante para ser registrada, sobretodo sabiendo que si necesitamos mayor resolución en un punto aplicaremos una ganancia a la señal analógica antes del ADC, o lo que es lo mismo cambiaremos el fondo de escala a un valor menor (en vez de 5V aplicaremos 2V, 1V, 500mV, etc. en las ecuaciones anteriores).

Por otro lador  en un osciloscopio nos limita la resolución de la pantalla, por lo que si la pantalla es Full HD, es decir, con 1080 pixeles de altura, ¿qué sentido tiene tener 12bits (4096 niveles)? Seremos incapaces de representarlos en la propia pantalla del osciloscopio, y eso sin contar que muchos osciloscopios todavía utilizan pantallas con resolución VGA (o XVGA) de 480 pixeles de altura.

Lo más sencillo es sacrificar la velocidad y tener ADCs de más bits (podemos tener 24bits y 110kS/s muy baratos), o, por el contrario sacrificar los bits y tener major velocidad (8bits y 250MS/s bastante asequibles). Por ejemplo, los osciloscopios modernos de bajo coste (<500€) suelen tener 8bits y 1GS/s de muestreo en total (para los 2 o 4 canales que tienen). Incluso los de marca de coste asequible aumentan la velocidad sin cambiar el número de bits (8bits y 2GS/s). Es decir, los fabricantes en general están de acuerdo que, en un osciloscopio es más importante la velocidad de muestreo que el número de bits aplicados a cuantificar la señal.

S2

Ranganok Schahzaman




sábado, febrero 20, 2016

Buenas Maneras (I): Llaves e identaciones

Inauguro una pequeña guía de estilo de como me gusta encontrar un código cuando trabajo en él (llamadme maniático si queréis).

A la hora de diseñar e implementar un nuevo firmware (o programa) no tengo mucho problema, ya que lo hago a mi gusto, sin embargo a la hora de mantener un programa o firmware realizado por otra persona es donde me suelo encontrar los problemas... Depende de lo hijop#t@ "limpio" que sea el programador anterior, que el código este comentado, indentado correctamente y bien diseñado.

Existen muchas guías de estilo (de hecho todos los proyectos grandes tienen la suya propia), pero yo me he hecho la mía a lo largo de los años y he notado que los errores se reducen y me es más sencillo leer y entender código antiguo.

Para no liarnos escojamos un lenguaje de programación de base: C++. Escojo este porque permitirá hacer comentarios tanto para lenguajes de bajo nivel (C), como para alto nivel (Java o C#).

Hoy vamos ha hacer algunos comentarios del estilo básico a la hora de escribir un programa (lo que llamaríamos la caligrafía).

Antes de empezar

Antes de empezar hay que tener en cuenta ciertas cosas:
  1. La guía de estilo debe ser clara en todas las situaciones. Yo recomiendo partir siempre de alguna guía ya establecida en un proyecto grande, de esta forma habrá muchos temas ya contemplados y que ni siquiera se nos habrían ocurrido en el primer momento (a título personal yo uso la guía de ANSI de base).
  2. La guía de estilo debe ser la misma para todos los participantes de un proyecto. No es nada agradable ver distintas partes del proyecto formateadas de forma diferente, además es confuso y puede llevar a errores.
  3. La guía de estilo debe ser estable en el tiempo de vida de un proyecto. Las guías de estilo no son inmutables, todo el mundo incorpora prácticas nuevas y mejores en su programación, sin embargo en un mismo proyecto es importante mantener la misma guía de estilo a lo largo de todo el tiempo de desarrollo para no crear confusión a la hora de leer el código. Aquí hay dos opciones, o se mantiene el estilo anterior o se cambia en todo el código. Hacer una u otra cosa dependerá de muchas cosas pero si se va a cambiar todo el código hay que tener en cuenta que haremos una pequeña ruptura con el código anterior (sobretodo si utilizamos un control de versiones), y hay que hacerlo de forma muy controlada.
  4. Se debe automatizar el proceso. Independientemente que interioricemos el proceso de escritura es importante usar un IDE que puedas automatizar el proceso de corrección de estilo (la mayoría de los IDEs modernos ya tienen esta opción incluida), de esta forma será mucho más sencillo. Sin embargo, en ningún caso implica que debamos dejarlo todo al IDE, en multitud de ocasiones no tendremos la oportunidad de realizar la automatización, por lo que será bueno que nos acostumbremos a escribir el código según la guía que hallamos elegido.

Llaves e identaciones

Primera regla de las identaciones usad siempre tabulaciones y no espacios esto incluye a no convertir las tabulaciones en espacios. A parte de ser una manía mía, implica desplazarse por el código más rápido y evita desajustes en el código cuando se tocan accidentalmente las teclas Supr o Retroceso. Sólo recomiendo usar los espacios para casos extremos en los que no haya más remedio (cuando no se puedan usar tabulaciones como el caso de esta bitácora). Otra cosa, las identaciones que ocupen el tamaño de 4 espacios (esto generalmente se puede utilizar Veamos ejemplos incorrectos, a mi modo de ver, de usar las identaciones:

¡¡¡ HORROR !!!, esta forma de programar hace que el código sea cada vez más ilegible (sobretodo cuando llevas 10000 líneas de forma similar). La solución correcta sería:

Sí, ya se que queda más largo el código, pero queda más limpio y te deja sitio para poner los comentarios que hagan falta. Por cierto poner !i o poner i==0 no es indiferente, la primera se deberá utilizar cuando sea una variable de verdadero o falso (booleano) y la segunda cuando sea una variable numérica. Otro:

 Esto queda feo con ganas, a parte que (personalmente) le tengo una manía horrible a poner la llaves no de forma identada (que empiece el bloque y lo acaben en la misma columna), y sobretodo cuando en vez de a=0 hay 100 líneas de código te puedes perder. Quedaría así:

o en este caso que tenemos una sóla línea:

fácil limpio y corto. Sin embargo es recomendable utilizar la primera opción para que las llaves limiten el bloque (menos propenso a errores). Otro ejemplo con la instrucción switch, partirmos de:

Cuando tenemos que hay mucho código dentro de los case queda muy sucio y poco comprensible. Una buena forma de no perdernos sería:

Así tenemos alineado el código y dentro de unas llaves, por lo que será más legible y más fácil de seguir. Siguiendo con el switch es bueno que la variable a sea de tipo enum (no siempre se puede), de esta forma podremos hacer un código más descriptivo, y por lo tanto más sencillo de leer.


Más adelante seguiremos avanzando con este y otros temas que nos permitirán aumentar la productividad a la hora de escribir y corregir código.

S2

Ranganok Schahzaman

lunes, octubre 12, 2015

4xcopter. Primer prototipo

Hace pocos días he recibido el primer prototipo del la placa de control.
PCBs empaquetada
El fabricante (elecrow) me las ha enviado en unas 3 semanas (50x50mm, 2 caras con máscara verde) por sólo 13€.
Parches aplicados
La verdad es que estoy bastante contento con el resultado, pero...
  • He visto que he cometido un error en el regulador de corriente: el patillaje es erróneo, cambia la posición de los pines Vin y GND entre el SOT23 y el SOT89. La solución parcial ha sido la de usar un LE33 en formato TO92.
  • Las vías no tienen máscara, si bien esto no es un error y a la hora de depurar incluso es una ventaja, es mejor que estén cubiertas por que dan menos problemas durante la fabricación: se evitan contactos erróneos, sobretodo si se sueldan los componentes a mano.
  • El color de la máscara me gustaría más en negro o azul, el verde está bien para prototipos y para PCBs que no van a la vista, pero para las placas visibles mejor usar otro color.
  • El cable de la foto es simplemente para juntar 3.3V analógico con 3.3V digitales, el un principio se generan con dos reguladores distintos, pero como no he montado todos los componentes me faltaba esa alimentación. En la siguiente versión irá una resistencia 0R para cuando se quiera juntar las pistas (incluso se podría usar una resistencia que formase un filtro paso bajo).
Me faltan hacer bastantes pruebas, y seguramente me surgirán más cosas a cambiar pero por ahora es suficiente para empezar a programar.

S2

Ranganok Schahzaman

lunes, junio 01, 2015

NSd (VII): Sensores

A parte de los sensores de posición y orientación que lleva la IMU la idea de la sonda es que lleve algunos sensores más que permitan medir datos atmosféricos, para ello hemos ideado una batería de pruebas que tenemos que recoger:
  • Iluminación: a parte de llevar una pequeña cámara (que nos dará información de a qué punto estamos mirando), podemos medir la radiación recibida en distintas longitudes de onda, usaremos los canales(con el pico de radiación entre paréntesis):
    • Rojo
    • Verde
    • Azul
    • IR cercano
    • UVA: también se podría medir UVB y UVC pero es más difícil de conseguir los sensores y para una primera sonda creemos que no es necesario.
    • IR térmico: es interesante medir la temperatura del objeto al que estamos apuntando (la Tierra por ejemplo), tambien podríamos usar un array de sensores (8×8 a 32×32) y tener ua pequeña imagen térmica
    • Iluminación/Blanco (“clear”): es una combinación de los canales Rojo, Verde y Azul
  • Temperatura: a parte de medir la temperatura interna para comprobrar el correcto funcionmiento de la sonda y calibrar las medidas de los sensores, podemos hacer una medida directa de la temperatura externa
  • Presión:A parte de obtener la altura barométrica (y la altura real si se tiene un barómetro en tierra), se puede hacer una medida de la presión atmosférica
  • Humedad relativa
  • Concentración de Gases: se puede medir distintos gases, sin embargo para esta medida no hemos encontrado todavía ningún sensor que mida los gases y cumpla con las condiciones de la sonda (excepto CO2).
¿Se os ocurre alguna medida más?

domingo, mayo 24, 2015

NSd (VI): Aplicaciones: Medida de datos atmosféricos

He visto la siguiente noticia, donde unos científicos quieren hacer una medida del viento a 100m para realizar pronósticos más precisos para predecir el comportamiento de los generadores eólicos. La sonda es una buena manera de hacerlo, ya hemos visto que se puede anclar muy fácilmente la sonda al suelo y además esta ya enviará parte de los datos que nos (presión atmosférica, humedad y temperatura), así que sólo nos queda saber la dirección y velocidad del viento.

En tierra y parados, medir la dirección y velocidad del viento sería relativamente fácil de hacer, sin embargo en una sonda colgada de un globo que se mueve y gira en varios ejes hay alguna complicación más… El hecho de utilizar giroscopios y acelerómetros, repartir correctamente los sensores por la superficie, utilizar formas aerodinámicas que impidan el giro libre y repartir el peso correctamente nos ayudará a recoger los datos de una forma ordenada y que luego sea fácilmente procesable.

Por ejemplo si la carcasa es en forma de gota de agua (o el perfil de un ala de avión) la brújula digital nos podría servir como veleta, ya que la forma de la carcasa haría que la sonda girará en dirección del viento. Para medir la velocidad del mismo podemos mirar la inclinación de la sonda o realizar la medida por resistencias o hilos calientes o directamente con un anemómetro de aspas.

domingo, abril 26, 2015

NSd (V): Definición del proyecto

Nos hemos dado cuenta que habíamos empezado a trabajar ya en el desarrollo de la sonda y todavía no habíamos publicado una defición del proyecto en condiciones.

El proyecto NSd trata de construir una sonda meteorológica (sub-espacial) que mida parámetros de la atmósfera y pueda realizar fotografías de gran altitud. Constará de dos partes bien diferenciadas, la sonda propiamente dicha (encargada de la recogida y transmisión de los datos) y la estación de tierra (encargado de la recepción de datos y el procesado y presentación de los mismos).

Sonda
A su vez la sonda constará de 3 partes diferenciadas:
  • La IMU (Unidad Inercial)
  • Los sensores
  • La parte de radiofrecuencia
IMU
La unidad inercial es el cuerpo de la sonda, se encarga de recoger los datos de posición y orientación de la sonda para contextualizar el resto de datos proporcionados por los sensores. Constará de:
  • Un procesador.
  • Un giroscopio (3 ejes).
  • Un acelerómetro (3 ejes).
  • Un magnetómetro (3 ejes).
  • Un altímetro barométrico.
  • Un GPS.
  • Un sistema de almacenamiento.
De esta forma tendremos una medida muy completa y exacta de la posición y orientación de la sonda en todo momento. Además dado que queremos un sistema compacto el mismo procesador que tenga la IMU nos podrá servir para recoger los datos del resto de sensores y para transmitir la información a la estación de tierra.

Sensores
Los sensores irán repartidos en una o varias PCBs dependiendo de la necesidad de espacio que ocupen o de la posición en la que hayan de ir. Nosotros hemos escogido unos sensores para medida atmosférica, sin embargo el diseño podría tener otros sensores dependiendo del uso que se vaya a dar (ver la sección de aplicaciones):
  • Una cámara (QVGA-VGA) a color
  • Sensores de luz para los siguientes canales: rojo, verde, azul, ultravioleta (UV a 400-410nm), Infrarrojo cercano (IR a 850nm), Infrarrojo térmico (IR a )
  • Humedad relativa
  • Temperatura interna y externa.
  • Gases: CO, CO2, O3
Radiofrecuencia
Como ya explicamos antes queremos enviar imágenes/vídeo y los datos de las medidas a la estación de tierra, para ello queremos emplear dos frecuencias:
El empleo de estas frecuencias es debido a que son en la banda de uso libre: 868MHz es para uso de dispositivos de “corto alcance” y 144,8MHz es de servicio de radioaficionado (1), si transmitimos en protocolo APRS podríamos conseguir que los aficionados de la zona de vuelo pudieran seguir la evolución de la sonda.

Módulo de recuperación
Suele ser interesante tener un canal de comunicaciones auxiliar para localizar la sonda en caso de perder el canal principal. Habíamos pensado en utilizar un módem GSM para enviar la posición una vez en tierra para recuperar la sonda. Para que fuera totalmente auxiliar debería funcionar de forma autónoma por lo que sería implementar una PCB independiente con:
  • Un microcontrolador.
  • GPS.
  • Módem GSM.
  • Alimentación independiente.
Sin embargo este módulo no es totalmente imprescindible, ya que tenemos el canal ARPS, por lo que podríamos no usarlo en caso que no tuvieramos tiempo de implementarlo todo.

Estación de tierra
La estación de tierra se encarga de recoger, procesar y presentar los datos. Dado que la sonda lleva un sistema de almacenamiento no es imprescindible hacerlo todo en tiempo real y podríamos espaciar las recepciones para reducir el ancho de banda y, por lo tanto, reducir las interferencias y el ruido (para aumentar la distancia de envío). La estación estará compuesta por:
  • Sistema de posicionamiento.
  • Sensorización en tierra.
  • Recepción de la señal.
  • Sistema de procesado y presentación.
Sistema de posicionamiento
El sistema de posicionamiento será un GPS, con ello podremos saber el recorrido del equipo de seguimiento de la sonda, en caso que esta vuele libre; o afinar la posición de la sonda a un error pequeño, en caso que esté fijada.

Sensorización en tierra
Es muy interesante conocer la presión barométrica en tierra, de esta forma se puede conocer la altura real de la sonda (y no sólo la altura barométrica) y así corregir el error del GPS. Sin embargo los sensores no se tienen porque limitar a eso; se podría tener, por ejemplo, una estación meteorológica completa.

Receptores de la señal
Es lo más importante de la estación de tierra, los receptores de los datos de la sonda nos permitirán saber la posición en cada momento y por lo tanto podremos recuperarla.

Sistema de procesado y presentación
Básicamente es un PC en el que se representarán los datos recibidos (tablas, hojas de cálculo, gráficos, mapas, etc.) y se procesarán (altura real en función de la barométrica, iluminación dependiendo del apuntamiento, etc.).

Si cuidamos un poco el diseño podemos reutilizar algunas PCBs (IMU como sistema de posicionamiento del equipo de tierra, etc.) por lo que bajaremos el precio.

(1) Fuente: Cuadro Nacional de Atribucción de Frecuencias.

EDITADO: Los servicios de radioaficionado no son de transmisión libre, sino que están sujetos a una licencia.

domingo, abril 19, 2015

NSd(IV): Aplicaciones: Fotografía aerea

Una de las posibles aplicaciones que tendrá la sonda es la de poder realizar fotografías aéreas geoposicionadas.

Con la estación base fijada en una posición durante bastante tiempo (>30min) se puede fijar la posición GPS de la sonda con bastante exactitud (<10cm), además el acelerómetro y los giroscópios el ángulo de apunte de la cámara y los movimientos que esta tenga. A partir de aquí se podrían hacer fotos de alta resolución a un bajo coste, incluso juntar varias fotos para realizar una de larga exposición (con los datos de los giroscópios y los acelerómetros se podría corregir las desviaciones por software).

Para elevar el conjunto (la cámara y la IMU) sólo nos hace falta un globo de helio y para anclarla y dirigirla nada más sencillo como una caña de pescar:“Skyfishing” with a GoPro HERO and 30 Helium Balloons from Tom Guilmette on Vimeo.

S2

Ranganok Schahzaman