sábado, 4 de diciembre de 2010

Introducción al PFM


Ya tengo elegido tema para el proyecto fin de máster que estoy haciendo. No tiene título pero va a ser algo así:
  • FPGAs en Open Hardware
  • Hardware reconfigurable abierto
  • Arduino en FPGA
  • Plataformas de Hardware de altas prestaciones y bajo coste
O cualquier combinación de esas palabras. El objetivo del proyecto va a ser sacar una conclusión del estado en el que el hardware reconfigurable por si alguien hubiese sido tan inteligente de haberlo adaptado a la moda: Arduino (que parece que sí y pretendo ayudar a ello).

El hardware reconfigurable abierto es lo contrario a un core 2 quad.

Primero, es abierto en el sentido que todos sus componentes están conectados de un modo que es del dominio público y no cae sobre él ninguna patente ni secreto. Además, las herramientas para conseguir programarlo también son abiertas en el sentido de que puedes bajarte la herramienta y su código fuente por si necesitases hacerle algún cambio. Para que se entienda en oposición al core 2 quad, los esquemas de un microprocesador de Intel son un secreto mejor guardado que el de la coca-cola.

Segundo, es reconfigurable. El core 2 quad tiene cientos de instrucciones simples. Sumar, cargar desde la memoria, comparar con cero, etc. Éstas se aplican contra una serie de memorias (llamadas registros) que hay dentro del chip y sus resultados se guardan en otras.Tras un complicadísimo proceso van pasando de chip en chip hasta que sus resultados se muestran en pantalla o se envían por bluetooth o lo que sea. Está creado de tal forma que las instrucciones se ejecutan muy deprisa. En el hardware reconfigurable las instrucciones son preparadas por nosotros: hacer la raíz cuadrada de un número A y luego restarle la mitad de otro número B para devolver la cotangente de su inversa. A y B se pueden poner directamente en los pines de una FPGA (ejemplo de hw reconfigurable) y el resultado sale en otros pines de forma casi instantánea.

Cada operación se hace en menos tiempo que en el Intel. Pero esto no siempre es mejor. No es que las FPGA sean mejores que los microprocesadores o más rápidas. Simplemente hacen ciertas cosas a un coste mucho más bajo. Coste es tiempo, energía y, en algunos casos, peso y volumen.

Tienen otras ventajas, como que al ser reconfigurables nunca están obsoletas. Puede dejar de fabricarse una FPGA pero será perfectamente reemplazable por otra de la misma marca o de otra, porque es totalmente personalizable. Por esta razón se usan en aviones, que son máquinas que tienen que durar 25 años y es necesario garantizar que siempre va a haber repuestos y piezas.

La única razón por la que las FPGA se estudian en la universidad es porque las marcas (básicamente Xilinx y Altera) morirían si no donaran miles de aparatos cada año a los laboratorios para que los alumnos hagan un semáforo. Estas placas cuestan de doscientos a miles de euros. Tienen de todo, Ethernet, salidas VGA, audio, botones, switches, potenciómetros, pantallas LCD, LEDs...

Yo siempre he estado obsesionado con las FPGAs. Uno de los requisitos de elección del máster fue que aparecieran en algún lado del programa porque me apetecía volver a programarlas, ahora que las entiendo y no como pasó en la carrera. Lo que me molesta, razón principal por la que me he inventado este proyecto, es que yo no pueda comprar una placa, programarla en el entorno que yo quiera, con el lenguaje que yo quiera y usarla para lo que yo quiera.

¡Hasta ahora! Gracias a la revolución iniciada por Arduino (bueno, iniciada por el open-source hace treinta años), la gente está pensando que aprender a programar hardware en la comodidad de un hogar no tiene comparación con la presión, olor y frío de un laboratorio en una universidad. Y lo que es más importante: puedo programar lo que yo quiera y no el semáforo de la práctica de teleco o industriales.

Pues lo que me hizo decidirme por la investigación en este ámbito es que, como era de esperar, ya hay alguien que está aprovechando este tirón y aplicándolo a las FPGA. Hace una semana me compré una placa Papilio Platform a Gadget Factory y ahora mismo tengo un LED parpadeando cada 600 milisegundos programado desde el entorno de desarrollo de Arduino, como si estuviera programando una duemilanove o una Arduino Uno.

He comprado la más potente (500.000 puertas, que es una cantidad media) y me ha costado $70.

Ahora, lo que toca, es comprobar qué programas y shields de Arduino son compatibles con esto, detectar por qué no lo son los que fallan e intentar corregir esas cosas para facilitar a otros, con más capacidad creativa, crear cosas increíbles.

Por ahora he comprobado que no se puede escribir un valor analógico. Esta parte requiere cierto dominio de los temporizadores del Atmega103 que se emula en la placa y como ya me peleé en su momento con ellos voy a intentar empezar por aquí.


domingo, 21 de marzo de 2010

Veinte curiosidades (técnicas) del mundo aeronáutico


  1. Los estabilizadores horizontales de cola (las alas de la parte posterior de los aviones) más que sustentar, empujan hacia abajo la cola de los aviones.
  2. No es lo mismo la ignición que el arrancado de un motor. Se arranca con fuerza hidráulica (líquido a presión) y una vez se alcanza una velocidad, se inicia la combustión.
  3. Donde menos gasto de combustible se hace es en el límite de la troposfera. Por debajo hace más calor (es más difícil refrigerar) y por encima no hay suficiente aire para empujar el avión. [Edit: sólo aviones turbofán]
  4. En el Ecuador se vuela a 20km sobre el nivel del mar. En los polos a 11.
  5. La temperatura del exterior de un avión comercial es de -65ºC y la presión 0.2 bares.
  6. La medición de altitud de los aviones se basa en la presión y depende de ésta por lo que no es real. Los aviones no se chocan porque todos llevan el mismo error, al compartir el mismo entorno. [Edit: ahora hay radioaltímetros]
  7. Con aire seco es más fácil despegar.
  8. Una persona sin suficiente oxígeno puede pensar que está haciendo todo bien cuando no es para nada así. En ciertas situaciones es obligatorio que los pilotos usen máscara de oxígeno.
  9. Algunos aviones tienen un sistema de emergencia de generación eléctrica consistente en un pequeño molino de viento (aerogenerador) que sale del fuselaje. Se llama RAT.
  10. El RAT cae por gravedad cuando ninguno de los generadores funciona.
  11. El aire acondicionado debe compensar el calor que produce cada pasajero, que es equivalente a una bombilla de 100W.
  12. En los lavabos, se tira del aire desde fuera, a diferencia del resto de la cabina, que se empuja para renovarlo. Así si hay algún problema, el olor no se cuela a la cabina.
  13. Peor que el hielo, para los aviones, es el agua superenfriada. Las gotas sin impurezas no cristalizan bajo cero hasta que impactan en el avión. Para estos casos se montan sistemas anti-hielo.
  14. Lo malo de tener los motores detrás de las alas es que el hielo acumulado en ellas puede desprenderse de golpe y dañarlos.
  15. Los motores funcionan mejor en lluvia, porque tienen más capacidad de empuje con agua que con aire (no se puede nadar en el aire). [Empujan más pero no gastan menos]
  16. Un avión se estrelló porque, al aterrizar, la lluvia apagó un motor. Desde entonces hay que tomar tierra con los motores en un régimen del 45%.
  17. El botón más difícil de accionar en cabina es el de extinguir fuego en un motor. La razón es que sale muy caro reparar la acción del extintor.
  18. Antes del amerizaje del Hudson (causado por pájaros en el motor), en la cabina olía a pollo frito porque el aire acondicionado se saca del motor. Este proceso se llama sangrado.
  19. El Boeing 787 es revolucionario por (casi) no utilizar aire sangrado del motor. Por ello, necesita generar cuatro veces más de potencia eléctrica que un A330 para aire acondicionado, sistemas antihielo, etc. Airbus decidió seguir usándolo en su A350. Esta diferencia puede hacer interesante la competencia en un futuro cercano.
  20. En el ala derecha hay una luz verde y en la izquierda una roja. Aunque parezca que sirven para saber si un avión va o viene, las luces de navegación no se ven desde atrás. Su cometido es actuar de semáforo en un cruce de dos aviones en el aire. Si un piloto ve la luz verde (del ala derecha del otro avión) tiene preferencia. Si no, verá una luz roja. Como en los coches, tiene preferencia el que viene por la derecha.
Estos datos son apuntes que estoy recogiendo de comentarios de profesores y algo de wikipedia por mi parte en un módulo del Máster en Integración de Sistemas de Aeronaves de la Universidad Carlos III, que nos están dado a empleados de EADS/CASA.

La foto que ilustra el post tiene licencia Creative Commons bajo condición de reconocimiento. Es del usuario individuo de flickr.

martes, 2 de marzo de 2010

Controlar un vehículo aéreo no tripulado desde Android

Este post no es un tutorial, sólo una recopilación de apuntes.


Un Vehículo Aéreo no Tripulado (UAV - Unmanned Air Vehicle, desde ahora) es un avión, helicóptero, quadcóptero o cualquier cosa que vuele sin la supervisión en tiempo real de un humano. La diferencia entre un UAV y un vehículo radiocontrolado es que el último necesita la intervención y supervisión continua de algún ente que lo domine y el primero tiene los sistemas típicamente electrónicos que le confieren la inteligencia suficiente para ejecutar órdenes, lidiando con los obstáculos o impedimentos (viento, fallos de comunicación, etc.) por sí mismo.

Hay gran cantidad de proyectos de UAVs, desde los de bajo presupuesto hasta los utilizados en operaciones militares, capaces de transportar y disparar armamento (UCAV, Unmanned Combat Air Vehicle). Además, teniendo en cuenta que los aviones de transporte civil aterrizan de forma automática en la mayoría de las situaciones, habría que tenerlos en cuenta al hablar de vehículos no tripulados.

En lo que estoy trabajando desde hace unos meses con un compañero del trabajo es en crear la -ya clásica- estructura para un quadcopter. Gracias a lo que ha avanzado la tecnología en motores R/C, es bastante económico hacer un vehículo volador con cuatro motores brushless y un controlador tipo Arduino.


Las características del sistema que hay que maximizar en principio son:
  • Duración del vuelo
  • Peso que es capaz de levantar
  • Dureza y tolerancia a los choques
  • Capacidades (GPS, cámara, acelerómetro, brújula, telemetría, etc.)
Lo que hay que minimizar es:
  • Peso de todo el sistema
  • Tiempo de respuesta (en general)
  • Coste
Un móvil moderno tiene las siguientes capacidades y características, por orden de importancia:
  • Peso reducido
  • Procesador de 300Mhz-1Ghz
  • Puerto de comunicación USB
  • Conexión GPRS/UMTS
  • Batería de larga duración
  • Acelerómetro de tres ejes
  • Brújula
  • GPS
  • Altavoz
  • Pantalla gráfica
  • Dispositivo de almacenamiento
  • Cámara de fotos y vídeo
  • Cierta dureza
  • Micrófono
Es una elección lógica, por lo que no soy el primero en pensar que es un controlador perfecto para un UAV. Si elegimos un móvil Android para el proyecto, dado que es Open-Source y se basan en hardware potente, el equipo parece tener un potencial impresionante (y bastante divertido).

Temas resueltos:
  • Aunque la electrónica de control y comunicaciones se realice en el móvil, un controlador externo basado en Arduino (con chip AVR) deberá lanzar las órdenes a los motores.
  • Desde Android se cambian los parámetros de vuelo, no se controlan directamente los motores.
  • La comunicación con el móvil se hace por GPRS/UMTS o Wi-Fi indistintamente.
  • Aunque se cuente con un GPS, el control se debe hacer en base a datos de un sensor de altura o barométrico, externo al sistema.




Los asuntos que aún hay que tratar son (algo así como un TO-DO List):
  • Habilitar la comunicación serie en el móvil, modificando el kernel del móvil: http://code.google.com/p/android-serialport-api/ y http://forum.xda-developers.com/archive/index.php/t-496976.html
  • Crear el circuito interfaz entre móvil y el controlador externo. http://www.instructables.com/id/Android_G1_Serial_Cable/
  • Dotar al software de prioridad suficiente en el móvil para evitar que otras aplicaciones lo saturen
  • Conseguir un quadcopter totalmente funcional radiocontrolado con Arduino y alguno de los proyectos libres disponibles:
  • Probar si el acelerómetro del móvil es suficientemente:
    • Sensible
    • Rápido detectando cambios,
    • Rápido comunicándose con el software
    • Rápido comunicándose con la Arduino
    Puesto que es bastante posible que falle en alguno de estos pasos, habrá que tener en cuenta la posibilidad de adaptar un acelerómetro externo conectado directamente a la Arduino.
  • Crear un protocolo de comunicaciones que admita comandos desde un portatil como:
    • Ir a un punto con el GPS
    • Pararse, manteniendo una altura.
    • Tomar una foto
    • Empezar un vídeo
    • Terminar un vídeo
    • Calibrar a 0
    • Aterrizar
    • Desplegar un paracaídas (por qué no)
  • Crear un sistema de telemetría que envíe datos por el mismo canal de comunicación al portatil.
    • Datos del GPS
    • Datos del acelerómetro
    • Vídeo en tiempo real
Nota sobre licencias: todas las fotos son CC de fuentes mencionadas y vinculadas en el post.