Tutorial emulación/simulación de Arduino en FPGA - Parte III

En esta parte del tutorial se va a utilizar ModelSIM PE o SE. Lamentablemente el Student Edition (gratuito) está limitado a 10.000 líneas de código y sólo el proyecto AVR8 tiene 16.000. Es posible simular unos cuantos ciclos con él pero es muy muy lento.



Antes de abrir ModelSIM, en ISE es necesario seleccionar el nodo xc3s500e-4vq100 del árbol en la ventana de diseño. La ventana de procesos muestra una serie de acciones y seleccionar "Compile HDL Libraries". Esto va a tardar unos minutos.




Ya en ModelSIM, al iniciar un nuevo proyecto hay que seleccionar la configuración generada por ISE. En el mismo fichero del proyecto ISE hay un fichero llamado modelsim.ini, que dice a ModelSIM dónde encontrar las librerías que se han compilado previamente.


Una vez completado el resto del formulario, se añaden ficheros al proyecto. Se seleccionan directamente del directorio del proyecto ISE, excepto FrqDiv.vhd, que no se utiliza.

Aparecerá una lista de ficheros en la ventana Project. En cualquiera de ellos, seleccionar, con el botón derecho, Compile - Compile Order.


Hacer click en Auto Generate. Debería decir "46 compiles, 0 failed with no errors".



Ahora es necesario añadir un testbench. Es un fichero que estimula el proyecto y sin el cual no haría nada. Gestiona la simulación de entradas y salidas físicas y señales como el reset y el reloj. En la carpeta scripts\XilinxISE del AVR8 hay un testbench.vhd, que hay que añadir al proyecto.

Antes de simular se deben hacer algunos cambios, abriendo el testbench con doble click:

Cambiar

constant clk_period : time := 1us;

por

constant clk_period : time := 31.25 ns;

Para que el reloj sea de 32Mhz.

Además hay que comentar estas dos líneas:

portb <= "11111111";
portd <= "10101010";

Que deben quedar de esta forma:

--portb <= "11111111";
--portd <= "10101010";

El programa de Arduino que vamos a grabar para la prueba es el siguiente:

int ledPin = 13; void setup() {
pinMode(ledPin, OUTPUT);
}
void loop() {
digitalWrite(ledPin, HIGH); // set the LED on
digitalWrite(ledPin, LOW); // set the LED off
}

Que simplemente hace parpadear el pin 13 constantemente.

Se edita prog_mem_init.vhd y se reemplazan las siguientes líneas:

constant PM_Inst_RAM_Word0_INIT_00 : bit_vector(0 to 255) := x"00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C008E940C"; constant PM_Inst_RAM_Word0_INIT_01 : bit_vector(0 to 255) := x"00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C"; constant PM_Inst_RAM_Word0_INIT_02 : bit_vector(0 to 255) := x"00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C00B1940C013B940C"; constant PM_Inst_RAM_Word0_INIT_03 : bit_vector(0 to 255) := x"0039000000270023003200350038003B000000280022003100340037003A0000"; constant PM_Inst_RAM_Word0_INIT_04 : bit_vector(0 to 255) := x"0303030303030202020202020202010101010101010100200021003000330036"; constant PM_Inst_RAM_Word0_INIT_05 : bit_vector(0 to 255) := x"2010080402010606060606060606050505050505050504040404040404040303"; constant PM_Inst_RAM_Word0_INIT_06 : bit_vector(0 to 255) := x"2010080402018040201008040201804020100804020180402010080402018040"; constant PM_Inst_RAM_Word0_INIT_07 : bit_vector(0 to 255) := x"0000000000000500000100000000000000000000000080402010080402018040"; constant PM_Inst_RAM_Word0_INIT_08 : bit_vector(0 to 255) := x"BE1F241100000000000000000000000000000000000000000000000000000000"; constant PM_Inst_RAM_Word0_INIT_09 : bit_vector(0 to 255) := x"9631920D95D8C004BF0B9503EF0FE0F3E3E8E0B0E6A0E010BFCDBFDEE0DFEFCF"; constant PM_Inst_RAM_Word0_INIT_0A : bit_vector(0 to 255) := x"940C0134940EF7E107B136AB921DC001E0B0E6A2E010BE1BF7C907B136A2F3C8"; constant PM_Inst_RAM_Word0_INIT_0B : bit_vector(0 to 255) := x"00609180950800EC940EE0600060918000EC940EE061006091800000940C019A"; constant PM_Inst_RAM_Word0_INIT_0C : bit_vector(0 to 255) := x"4F3F57262D9095C82FF92FE84F9F54862F932F82E0302F28950800C4940EE061"; constant PM_Inst_RAM_Word0_INIT_0D : bit_vector(0 to 255) := x"95C896312DA095C84FFF5AE01FFF0FEEE0F02FE8F0A923882D8095C82FF32FE2"; constant PM_Inst_RAM_Word0_INIT_0E : bit_vector(0 to 255) := x"2F952F84E0502F489508938C2B89918C9508938C23899590918CF42923662DB0"; constant PM_Inst_RAM_Word0_INIT_0F : bit_vector(0 to 255) := x"4F5F57462D9095C82FF92FE84F9F54862F952F842D2095C82FF92FE84F9F5186"; constant PM_Inst_RAM_Word0_INIT_10 : bit_vector(0 to 255) := x"B58FF4213024C004778FB58FF4193023F0B12322F16923332D3095C82FF52FE4"; constant PM_Inst_RAM_Word0_INIT_11 : bit_vector(0 to 255) := x"E0F02FE3BD857D8FB585F4193025C005BF837D8FB783F4213021C00BBD8F7D8F"; constant PM_Inst_RAM_Word0_INIT_12 : bit_vector(0 to 255) := x"9508938C23899590918CF42923662DB095C896312DA095C84FFF59E21FFF0FEE"; constant PM_Inst_RAM_Word0_INIT_13 : bit_vector(0 to 255) := x"2411920FB60F920F921FCFFD00B3940E00BE940E0183940E9508938C2B89918C"; constant PM_Inst_RAM_Word0_INIT_14 : bit_vector(0 to 255) := x"006A9130006991B0006891A0006791900066918093BF93AF939F938F933F932F"; constant PM_Inst_RAM_Word0_INIT_15 : bit_vector(0 to 255) := x"939000669380006A93201DB11DA19601572DF020372D5F2D2F231DB11DA19601"; constant PM_Inst_RAM_Word0_INIT_16 : bit_vector(0 to 255) := x"1DB11DA19601006591B0006491A00063919000629180006993B0006893A00067"; constant PM_Inst_RAM_Word0_INIT_17 : bit_vector(0 to 255) := x"BE0F900F912F913F918F919F91AF91BF006593B0006493A00063939000629380"; constant PM_Inst_RAM_Word0_INIT_18 : bit_vector(0 to 255) := x"BD8E6081B58EBD8E6082B58EBF876081B787BF836084B78394789518901F900F"; constant PM_Inst_RAM_Word0_INIT_19 : bit_vector(0 to 255) := x"000000000000000DCFFF94F89508BD856081B585BD856082B585BD8F6081B58F"; constant PM_Inst_RAM_Word0_INIT_1A : bit_vector(0 to 255) := x"0000000000000000000000000000000000000000000000000000000000000000"; constant PM_Inst_RAM_Word0_INIT_1B : bit_vector(0 to 255) := x"0000000000000000000000000000000000000000000000000000000000000000";

El programa sólo ocupa estas líneas, desde INIT_00 hasta INIT_19. El resto de líneas se rellenan con ceros. La explicación de compilar programas Arduino y convertirlos en este formato se hará más adelante.

Botón derecho en cualquier fichero de la pestaña Project - Compile All. Mientras no se está familiarizado con un diseño es recomendable compilar todos los ficheros siempre. Cuando hay más confianza, es más rápido utilizar "Compile out-of-date".

En el menú Simulate, seleccionar "Start Simulation". Se elige work.testbench y se dejan todas las opciones como están.

Se añaden unas cuantas señales al visor de ondas tal y como se indica en la siguiente figura, haciendo click derecho en testbench, Add, To Wave, All items in region.



Si no sale la ventana Wave, seleccionarla desde el menú View. La simulación debería hacer parpadear el pin 13 (pin 5 del puerto B).

(Pendiente de publicar el resultado de la simulación.)


Parte V - Compilar programas Arduino para simulación
Índice del tutorial

Tutorial emulación/simulación de Arduino en FPGA - Parte II

En los siguientes capítulos del tutorial se va a describir la forma de simular un programa Arduino. El objetivo es ejecutar un sketch de Arduino sin utilizar la placa, emulando el microcontrolador en un ordenador.

Para ello se puede utilizar ModelSIM o ISim de Xilinx. El Student Edition de ModelSIM está limitado y no se recomienda. Sin un ModelSIM de pago, utilizaremos ISim, que no es tan completo pero es gratuíto y suficiente para el cometido del tutorial.

Captura general de ModelSIM

Captura general de ISim

¿Qué es simular un diseño de lógica reprogramable?
La simulación en este tipo de software se realiza a muy bajo nivel, visualizando directamente señales digitales dentro del chip, no variables u objetos. El objetivo de la simulación es depurar y comprobar el correcto funcionamiento de un diseño antes de implementarlo físicamente en un chip, ya sea una FPGA o un circuito integrado de propósito concreto.

El funcionamiento de las FPGA u otros dispositivos hardware de lógica reconfigurable está fuera del propósito de este tutorial pero, resumiendo, son circuitos integrados que se configuran para actuar como cualquier otro circuito integrado. Esta versatilidad se paga en precio y en algunos casos, rendimiento.

¿Cómo se carga un sketch en el modelo emulado?
La FPGA utilizada tiene unos cuantos bloques de memoria BRAM. La memoria de programa y datos del microcontrolador también se van a emular, utilizando estos bloques. El código compilado de un sketch se transforma al formato apropiado con una herramienta de Xilinx llamada data2mem.

Uso de Xilinx ISE Webpack
Vayamos a simular con ModelSIM o ISim, antes hay que cargar el proyecto en Xilinx ISE.

El proyecto AVR8 se baja y descomprime en una carpeta temporal. En el momento de escribir este tutorial la última versión es GadgetFactory Arduino Soft Core v1.6-0. Se abre el Project Navigator y se crea un nuevo proyecto. En este paso hay que seleccionar un tipo de FPGA. Si se va a utilizar más tarde la Papilio, habrá que elegir por ejemplo XC3S500E para la Papilio 500k. También es importante elegir en este punto (aunque luego se puede cambiar) el simulador. ModelSIM si se cuenta con una versión de pago e ISim, si no.

En el menú Project se elige "Add copy of source". Todos los ficheros de la carpeta sources del con extensión vhd y ucf se añaden. Son unas cuantas carpetas y hay que ir una por una.

En la ventana Design, con la opción Implementation seleccionada, se genera un árbol de instancias de componentes y componentes sin instanciar: xc3s500e-4vq100 es la FPGA. Papilio_AVR8 es la instancia de la Arduino, o del microcontrolador de la Arduino.



¿Significa esto que es posible instanciar varias Arduinos en una sola FPGA? Sí, en ésta en concreto, caben cuatro.

FrqDiv, XDM*** y XPM*** son componentes que se han añadido y no se han instanciado. El resto de componentes cuelgan de Papilio_AVR8. Al expandir su rama salen una serie de componentes instanciados y otros ficheros de configuración. Hay dos que salen con una interrogación, Inst_DCM32to16 y papilio_core_template_COMP. Uno está en la carpeta descomprimida previamente scripts\XilinxISE\ipcore_dir y otro en submodules\papilio_core_template\sources. Se añaden.

Para entender mejor el microcontrolador es recomendable seleccionar Papilio_AVR8 en el árbol de diseño y seleccionar el proceso "View RTL Schematic", después seleccionar "Start with a schematic of the top-level block".

Se generará el siguiente diagrama:



Haciendo doble click sobre un bloque, se abre. Abriendo Papilio_AVR8 se puede empezar a ver las tripas del microcontrolador. Control + rueda del ratón hace zoom.



Es interesante ver que hay un componente llamado AVR_Core_Inst (instancia de AVR_Core) que gestiona todos los buses, enables, etc. Sus periféricos son módulos como PM_Inst que es la memoria de programa (donde vamos a cargar el sketch) o los módulos de RAM utilizados en la ejecución de programas, en principio vacíos. DCM32to16 convierte el reloj de 32Mhz de la Papilio en 16Mhz, que es la frecuencia correcta para Arduino.




También es interesante fijarse en que hay diferentes tipos de puertos para cada instancia de puerto en la Papilio.



El estudio gráfico de un diseño hardware con esta herramienta es bastante más sencillo que analizar el código VHDL por lo que es recomendable intentar entender qué hace cada módulo si más tarde se va a modificar el hardware para adaptarlo a alguna necesidad concreta.

Siguientes partes:
Parte III - Simulación con ModelSIM (si se usa una versión de pago)
Parte IV - Simulación con ISim (integrado en Xilinx ISE)
Índice del tutorial 

Tutorial emulación/simulación de Arduino en FPGA - Parte I

Introducción
Hay que entender que el hardware de Arduino es un microcontrolador muy común, con su memoria, multiplexores, registros, buses, etc. No es más que un circuito digital. En sitios como opencores.org podemos encontrar modelos RTL de muchos microprocesadores. Es una descripción abstracta de lo que un circuito digital hace.

ATmega2560 por dentro (físicamente)

Ejemplo: un inversor digital da a su salida el valor negado de la entrada. En esta descripción abstracta no se habla de tecnología utilizada de transistores, de encapsulados o de medidas de rendimiento como el tiempo de respuesta.

Representación de un modelo de inversor

Seis inversores en un encapsulado

Si cada componente de un microcontrolador se define de esta forma y se establecen las conexiones entre los cientos o miles de componentes, se puede crear un modelo RTL bastante complejo pero funcional.

Representación esquemática de componentes y conexiones en un ATmega103 modificado

• Un modelo RTL se crea con lenguajes de descripción de hardware (HDL) como son VHDL o Verilog.
• Un modelo RTL sirve para simular el comportamiento de un circuito hardware con ayuda de un ordenador.

Es la forma de diseñar hardware hoy. No puede haber un prototipo físico en cada cambio que haya en el proceso de diseño de un microprocesador o microcontrolador.

Una FPGA es un dispositivo hardware que se configura con un modelo RTL. Esto significa que es posible hacer que una FPGA se comporte como un microcontrolador determinado y, por lo tanto, hacer que se comporte como cualquier circuito digital. Este ejercicio se llama emulación.

• El objetivo de este tutorial es emular un microcontrolador ATmega103 en una FPGA y hacer que ejecute programas Arduino.
• Además, se optimizarán programas para crear procesos paralelos y se personalizará el hardware para, por ejemplo, crear salidas analógicas PWM en cualquier pin.

Software utilizado
Xilinx ISE Webpack 13.1 para sintetizar el diseño. Incluye ISim para simularlo.
Opcional: ModelSIM SE o PE para simularlo (no sirve el Student Edition)AVR8 Source Code V1.6. Código fuente en VHDL del ATmega103 modificado por Gadget Factory.
Butterfly Arduino IDE. IDE de Arduino 0018 modificado por Gadget Factory.



Parte II - Emulación del modelo RTL de Arduino
Índice del tutorial

Taller de electrónica para creación artística @ UC3M

El 27 de abril empezaremos Javier y yo a impartir, de nuevo, el primer taller de electrónica que hicimos en el Aula de Propulsión Escópica.

Fueron cinco días de un esfuerzo mental y creativo brutal donde lo más destacable fue la gente que conocimos, de inquietudes peculiares.

Aunque no podemos recrear exactamente las mismas condiciones nos han llamado de la Universidad por lo que tendremos muchos más recursos.

Hoy (11 de abril) voy a presentar el taller en Leganés a las 17:30. Inscripción y más información en http://control.escopica.net

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í.

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.

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:
• http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A44814
• http://code.google.com/p/quaduino-ng/
• 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.