Xpider: Desarrollo de un Vehículo Aéreo No Tripulado de Cuatro Motores

Transcripción

1 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA INFORMÁTICA Curso Académico 2010/2011 Proyecto Fin de Carrera Xpider: Desarrollo de un Vehículo Aéreo No Tripulado de Cuatro Motores Autor: Óscar Higuera Rincón Tutor: Carlos Agüero Durán

2

3 A Su.

4

5 Agradecimientos En primer lugar quiero dar las gracias a mi familia por su apoyo y comprensión constante. También a Iván, Jacob, Antonio y el resto de mis eternos compañeros, siempre fieles. Sin olvidarme de toda la buena gente que forma el Departamento de Robótica de la Universidad Rey Juan Carlos, por su disposición y ayuda, especialmente a Carlos Agüero. v

6

7 Índice general Índice general VII Índice de figuras XI Resumen XV 1. Introducción Historia Aplicaciones Militares Civiles Clasificación Carga de Pago Estación de Tierra Situación en España Objetivos Descripción del Problema Requisitos Requisitos Hardware Requisitos Software Embarcado Requisitos de Estación en Tierra Metodología Estudio de Alternativas Mikrokopter Aeroquad vii

8 viii ÍNDICE GENERAL 3.3. Ardupilot Entorno de Desarrollo Arduino Processing Análisis Principios de Sustentación y Movimiento Pitch Roll Yaw Plataforma Hardware Estructura Física Incremento V Incremento V Incremento V Sensores Acelerómetros Giróscopos Magnetómetros Sónar y Barómetro Unidad Central Incremento V Incremento V Incremento V Software Embarcado Arquitectura Software Drivers de EntradaSalida Interfaz I2C Módulo ADXL345Driver Módulo ImuAdc Módulo DigitalCompass

9 ÍNDICE GENERAL ix Módulo AltimeterDriver Comunicaciones Módulo IMU Algoritmo DCM Módulo de Estabilización PID Parametrización PID Aplicación de PID a la estabilización Evolución de los Incrementos Estación de Tierra (GCS) Arquitectura Software SerialComms MainMenuDisplay PrimaryDisplay GraphicMotor GraphicAHorizon HeadingIndicator GraphicModel BatteryMonitor ValueIndicator GraphicPID JoystickControl CalibrationDisplay Grabador Reproductor Evolución de los Incrementos QSearch Antecedentes en búsqueda optimizada Métodos numéricos Algoritmos basados en muestras Cuckoo Search Descripción del algoritmo QSearch

10 x ÍNDICE GENERAL 9.3. Experimentos Pruebas Pruebas en banco Pruebas en vuelo Conclusiones y Trabajos Futuros Conclusiones y Objetivos Alcanzados Plataforma Hardware Software Embarcado Estación de Tierra (GCS) QSearch Trabajos Futuros Bibliografía Apéndices 107

11 Índice de figuras 1.1. Raven RQ-11B de AeroVironment Scan Eagle UAV IAI Eitan Nothrop Grumman Fire Scout Aeryon Scout de Aeryon Labs RQ-4 Global Hawk UAV Sensor electro-óptico térmico GSC del Predator neuron ATLANTE UAV Diagrama de componentes Diagrama iterativo-incremental Diagrama de Incrementos Mikrokopter de 8 motores Módulo central de Mikrokopter NAV Module de Mikrokopter NicoletoMK basado en Mikrokopter Aeroquad radiocontrolado Ardupilot IMU Ardupilot Easyglider Plataforma hardware Arduino UNO Arduino Nano Arduino Mini xi

12 xii ÍNDICE DE FIGURAS 4.4. Seeeduino Entorno de desarrollo Arduino Entorno de desarrollo Processing Análisis de fuerzas Componentes inerciales resultantes Inercial y momento angular total Relación de ángulos pitch, roll y yaw Esquema Giro Pith Esquema de giro Roll Esquema de giro Yaw Chasis básico de Mikrokopter Conjunto motor/hélice Detalle ESC Primer banco de pruebas Detalle de plataforma aislante Protector de poliestireno Relación orientación del acelerómetro IMU 6DoF Razor ADXL345 con breakboard de Sparkfun Esquema giróscopo IMU 6DoF sin filtros hardware Placa breakboard con LPY530AL Magnetómetro HMC Barómetro SCP1000 de MBED Sónar LV MaxSonar EZ-1 de MaxBotics UC V Módulo Xbee Placa: conexiones Placa: cortes Placa V Prototipo V

13 ÍNDICE DE FIGURAS xiii Placa: pistas V UC V Arquitectura Software Proyecciones de una base sobre otra de referencia Diagrama del controlador PI DCM Esquema de controlador PID Parametrización PID Componente gráfico Serial Comms Componente MainMenuDisplay Componente GraphicMotor Componente GraphicHorizon Componente HeadingIndicator Componente GraphicModel Componente BatteryMonitor ValueIndicator Componente GraphicPid Componente JoystickControl PrimaryDisplay Espacio de Búsqueda Calibration Config Representación visual de un Test CalibrationDisplay Grabador/Reproductor Diagrama de clases principal GCS Vuelo Levy convencional Michaelwicz Landscape Qsearch de Michaelwitz (3-6-3) y (2-7-3) Qsearch de Michaelwitz ( ) y ( ,200) Primer banco de test Segundo banco de pruebas

14 xiv ÍNDICE DE FIGURAS Plano pieza adaptadora QSearch iteración QSearch iteración Datasheet de la placa del ADXL Datasheet de la placa del LPY530AL Datasheet de la placa del HMC Datasheet de la placa del SCP Datasheet de la placa del IMU 6DoF de Razor

15 Resumen El Proyecto Fin de Carrera expuesto en este documento presenta la definición, diseño e implementación de un vehículo aéreo autónomo de corto alcance basado en una configuración de cuatro motores con capacidad de vuelo estacionario. El Proyecto abarca tanto el diseño e implementación hardware (la elección de los componentes electrónicos, tanto sensores como microprocesador y diferentes actuadores, la construcción física de la estructura del vehículo y el diseño e implementación de la placa base y las interfaces hardware) como el diseño e implementación software, tanto de aquel que ejecutará embarcado en el vehículo como el software de la aplicación de monitorización, mando y control que se ejecutará en lo que se conoce como Estación de Tierra (Ground Control Station o GCS). Dentro de las capacidades del vehículo que han sido implementadas en este Proyecto se encuentra la capacidad de vuelo estacionario estable adecuadamente monitorizado y controlado. Para ello el vehículo debe interpretar adecuadamente todos los datos procedentes de los diferentes sensores, procesar estos datos y ejecutar las diferentes rutinas de control que permiten la capacidad de mantener un vuelo estable, el control automático y estabilización de altura, el control automático y estabilización del rumbo y la capacidad de mantener comunicaciones inalámbricas con la estación de monitorización, mando y control. También se ha introducido alguna rutina de navegación y se han esbozado las capacidades de navegación que no ha sido posible implementar por motivos de calendario. Para la realización del proyecto se ha partido de cero, desde la elección de los entornos de desarrollo, la plataforma hardware, el diseño e implementación del software embebido, y el diseño e implementación del software de mando y control. Puntualmente se han utilizado como referencia fragmentos de algoritmos de cálculos matemáticos especificando en todo caso la fuente. xv

16 xvi CAPÍTULO 0. RESUMEN

17 Capítulo 1 Introducción Un vehículo no tripulado es todo aquel vehículo capaz de realizar diferentes tipos de tareas sin la necesidad de contar con un tripulante humano. Los vehículos aéreos no tripulados UAV (Unmanned Aerial Vehicle) han cobrado una gran importancia en la industria aeronáutica debido a que son capaces de cubrir un gran número de necesidades y posibilidades no exploradas hasta hace bien poco. Aunque aquí nos centremos en vehículos aéreos también existen vehículos no tripulados en tierra y mar. Dentro de los vehículos no tripulados se encuentran vehículos controlados remotamente (Remotely Piloted Vehicle o Drones) y vehículos autónomos AV (Autonomous Vehicle). En el caso de este proyecto, nos centraremos en UAVs autónomos, capaces de realizar gran parte de las tareas sin la intervención de un humano. Este tipo de vehículos son muy útiles en circunstancias en las que contar con un tripulando humano puede ser peligroso para su integridad, o en aquellos casos en los que por movilidad, maniobrabilidad o flexibilidad es imposible contar con un tripulante Historia Si echamos un vistazo a la historia de los UAVs [21] y [31], los primeros UAVs eran aeronaves simples pilotadas remotamente a través de sistemas de radio control. Su uso comenzó a introducirse dentro del campo militar tras la Primera Guerra Mundial, usándose en la Segunda Guerra Mundial como blancos móviles para el entrenamiento de sistemas antiaéreos y de diferentes armas. A finales de los años 60 y debido al riesgo potencial de bajas de pilotos en misiones de reconocimiento en territorio enemigo, y debido al alto número de vuelos de este tipo que se realizaron durante la Guerra Fría, los oficiales norteamericanos fijaron su interés en las posibilidades de los vuelos no tripulados. Esta necesidad se amplió con la entrada de Estados Unidos en la Guerra de Vietnam donde se produjo el primer uso de UAVs en misiones de combate. Al mismo tiempo, Israel comprendió la necesidad de invertir en el desarrollo de vehículos no tripulados al perder gran cantidad de aeronaves debido a las baterías de misiles antiaéreos que desplegaban sus múltiples enemigos en los distintos conflictos armados que se intensificaron a partir de los años 70. En los años 80 y 90 se produjo un gran avance en este tipo de vehículos, dotándolos de mayor capacidad autónoma. También los diferentes avances en las tecnologías hicieron 1

18 2 CAPÍTULO 1. INTRODUCCIÓN posible el abaratamiento de costes, así como la posibilidad de crear vehículos más pequeños y versátiles. Con la llegada del siglo XXI y los nuevos escenarios de guerra moderna llegó el boom de los UAVs, tanto de reconocimiento como de adquisición de blancos y combate. El nuevo escenario de guerra urbana contra enemigos dispersos hizo necesario, por un lado, el uso de pequeños y versátiles UAVs de reconocimiento que podían ser usados en campo para asistir a las tropas en diferentes tareas, y por otro lado, de sofisticados UAVs de medio y largo alcance capaces de fijar blancos móviles e incluso abatirlos con un riesgo mínimo. Las capacidades autónomas han ido aumentando cada vez más, desde asistir en vuelo a un piloto situado en una estación remota, hasta el vuelo completamente autónomo siguiendo un determinado plan de vuelo precargado, y el seguimiento de un plan de misión avanzado con gestión de la carga de pago (conjunto de elementos y dispositivos destinados a adquirir datos de inteligencia). Actualmente los UAVs siguen siendo utilizados mayoritariamente en entornos militares, donde han conseguido hacerse un hueco como sistemas de vigilancia, inteligencia, reconocimiento y adquisición de blancos (ISTAR, Intelligence Surveillance Target Adquisition and Reconnaissance). Paulatinamente van haciéndose hueco también en aplicaciones civiles, sobretodo en los campos de vigilancia, seguridad, y reconocimiento Aplicaciones Militares Tal y como se ha adelantado en la introducción, la mayor parte de las aplicaciones de los UAVs se centran en el campo militar. Dentro de las aplicaciones militares destacan la vigilancia y reconocimiento del entorno, incluyendo la detección y clasificación de posibles amenazas, reconocimiento y adquisición de blancos, obtención de un mapa completo geográfico del campo de batalla, e incluso el combate directo, aunque en este último caso siempre guiado y monitorizado por un piloto humano. De entre todas las aplicaciones, dos de ellas han sufrido un profundo avance en los últimos años: Por un lado, las aplicaciones de vigilancia y reconocimiento de corto alcance, llevadas a cabo por pequeños UAV s desplegados en campo por los propios soldados. Estos cuentan con una pequeña Estación de Tierra para recopilar datos y generar inteligencia. Estos UAVs proveen a los combatientes de información casi en tiempo real, de manera que pueden generar un mapa tanto geográfico como de amenazas y blancos. Estos UAV s son pequeñas aeronaves generalmente propulsadas eléctricamente, que pueden ser desplegadas a mano por los soldados y que en algunos casos no retornarán nunca. Cuentan con baja autonomía, muy bajo coste y proporcionan una información muy valiosa a corto plazo. Por otro lado se encuentran UAV s de mayor tamaño usados tanto en misiones ISTAR como de combate. Estos vehículos en algunos casos tienen casi el tamaño de un avión de combate convencional, con autonomías que cubren grandes distancias y alturas. La información que proporcionan puede ser, en algunos casos, directamente usada por sistemas de artillería o incluso pueden contar con armamento embarcado. Los UAVS ISTAR generalmente proporcionan información táctica muy valiosa en inteligencia que puede ser usada también a largo plazo. También pueden tener la capacidad de

19 1.3. CLASIFICACIÓN 3 sincronizarse entre diferentes UAV s para aumentar el valor de dicha información. El estado de Israel ha realizado verdaderos progresos en UAV s capaces de adquirir blancos móviles a distancias enormes, sin apenas ser detectados, o generando alertas de riesgos y amenazas mientras patrullan regiones críticas, como la Franja de Gaza, o las fronteras con Líbano, repletas de terroristas ocultos entre población civil y en poblado Civiles El ámbito de aplicación de los UAVs no se limita al área militar, poco a poco, comienzan a demandarse aplicaciones y servicios en el campo civil. Los UAVs civiles de largo alcance son utilizados en tareas de identificación de riesgos y vigilancia de zonas amplias en espacios de difícil acceso, como vigilancia de grandes instalaciones de canalización de gas, gasóleo, o similares. También en tareas de identificación de conatos de incendios en grandes zonas boscosas, incluso en los servicios de protección de fronteras, ayudando a las Fuerzas y Cuerpos de Seguridad del Estado en la identificación y seguimiento de embarcaciones que pretenden entrar ilegalmente en el país a través del mar, ya se trate de inmigración ilegal, o tráfico ilegal de diferentes sustancias o materiales. Estos vehículos abaratan considerablemente el coste de las misiones de control y vigilancia, ya que antes de estos vehículos estas tareas eran llevadas a cabo por aviones pilotados o helicópteros, cuyo coste de adquisición, mantenimiento y entrenamiento, es muy elevado. Los cuerpos de seguridad también comienzan a demandar pequeños UAVs de corto alcance para tareas de vigilancia de perímetros, o incluso reconocimiento del campo de acción, por ejemplo, por parte de la Policía o Guardia Civil. Estos vehículos son similares a los usados en campo por el ejército, suelen tener un alcance limitado y un coste muy bajo, proporcionando una gran cantidad de inteligencia a los cuerpos desplegados en campo. También existen otras aplicaciones civiles como servicios de fotografía o captura de vídeo aéreo, útil para conformar mapas actualizados de parcelas para la construcción o rehabilitación de inmuebles, así como otros usos dirigidos hacia el entretenimiento. Por ultimo, también se usan vehículos no tripulados en aplicaciones científicas de investigación, sustituyendo, por ejemplo, a globos sonda, incluso para el transporte de pequeñas cargas en trayectos cortos que serían muy costosos si tuvieran que ser realizados de otra manera. Podemos decir que el campo de los vehículos no tripulados en general, y el de los aéreos en particular es un mercado en expansión, en el que van apareciendo nuevos ámbitos de aplicaciones y usos constantemente Clasificación Los UAVs pueden ser clasificados tanto por su ámbito de aplicación como por su alcance y capacidades [20]. Por su ámbito de aplicación, tal y como ya se ha definido, los UAVs pueden ser clasificados básicamente en cinco categorías: ISTAR (inteligencia, vigilancia, adquisición de blancos y reconocimiento), logística, combate, investigación y desarrollo, y UAVs civiles. Dentro de esas cinco categorías se pueden encontrar UAVs de diferentes tamaños, alcances

20 4 CAPÍTULO 1. INTRODUCCIÓN Figura 1.1: Raven RQ-11B de AeroVironment. De lanzamiento manual y motorización eléctrica. Puede ser controlado remotamente u operar de manera completamente autónoma, monta cámaras de vídeo y de visión infrarroja, es utilizado para reconocimiento y adquisición de blancos. Su autonomía es de 40 minutos y pesa 2 kilos. El coste de cada unidad es de $ por separado y de $ con el sistema completo incluyendo estación de control de tierra. (Entrada en servicio: 2006). y capacidades. Si se tiene en cuenta simplemente el tamaño y alcance de los vehículos, estos pueden ser clasificados en las siguientes categorías: Handheld: Se trata de pequeños y ligeros vehículos que pueden lanzarse de manera manual, con alcances limitados a menos de 2000 metros y que pueden alcanzar no más de 500 metros de altura. Close: De alcance cerrado o corto alcance, son capaces de alcanzar 1500 metros de altitud y cuentan con una autonomía por debajo de los 10 kilómetros. Su despegue puede ser manual, ayudados por catapulta o mediante despegue autónomo. De tipo NATO: UAVs medios capaces de alcanzar 3000 metros de altitud y llegar a los 50 kilómetros de autonomía. Generalmente su tamaño ya no permite el lanzamiento manual. Tácticos: Capaces de alcanzar 5500 metros de altitud y con autonomías que pueden llegar a los 160 kilómetros. MALE (Medium Altitude, Large Endurance): UAVs capaces de alcanzar altitudes medias si hablamos con terminología aeronáutica, aproximadamente sobre los 9000 metros de altitud, y con autonomía suficiente para poder cubrir grandes distancias, aproximadamente sobre los 200 o 300 kilómetros. HALE (High Altitude, Large Endurance): UAVs capaces de alcanzar altitudes superiores a los 9100 metros y con alcances indefinidos (pueden llegar hasta kilómetros o más). Hipersónicos y Orbitales: Por último aquellos vehículos capaces de alcanzar velocidades supersónicas (de MATCH 1 a MATCH 5) o hipersónicas (superior a MATCH 5), o aquellos capaces de ponerse en órbitas bajas alcanzando velocidades de más de MATCH 25.

21 1.3. CLASIFICACIÓN 5 Figura 1.2: Scan Eagle: UAV desarrollado por Boeing de tipo NATO. Cuenta con una autonomía de hasta 20 horas o 100 kilómetros, entre su carga de pago cuenta con cámara auto-estabilizada infrarroja de alta resolución. Es capaz de alcanzar 60 nudos de velocidad media (110 Km/h). En la foto lo vemos en su plataforma de lanzamiento móvil. (Entrada en servicio: 2006). Figura 1.3: IAI Eitan desarrollado por Israel Aerospace. Se trata de un UAV de tipo MALE con capacidades ISTAR. Capaz de mantenerse en vuelo durante 36 horas a pies de altitud ( metros), albergar una carga de pago de kilos y cubrir hasta 7000 kilómetros. Es la joya de la corona de los UAVs del ejército israelí, su tamaño es comparable a un Boeing 737. (Entró en servicio en 2009).

22 6 CAPÍTULO 1. INTRODUCCIÓN Figura 1.4: Northrop Grumman Fire Scout. Helicóptero UAV usado por la fuerza aérea estadounidense en tareas de reconocimiento, identificación de amenazas y fijación precisa de blancos. Autonomía de 8 horas y rango de acción de 200 kilómetros. (Operacional desde 2006). Dentro de los diferentes tipos de UAVs introducidos, y en el marco de este Proyecto, es interesante diferenciar los UAVs con capacidades de vuelo estacionario y aterrizaje/despegue vertical VTOL (Vertical Take-Off and Landing) del resto. Una aeronave VTOL es capaz de mantener vuelo estacionario en altura y dirección, es decir, sin avanzar en eje alguno de coordenadas. Las más comunes son los helicópteros. Si hablamos de vehículos no tripulados, existen diferentes modelos de UAVs de tamaño medio basados en helicópteros, las particularidades de este tipo de aeronave hacen que sean ideales para determinadas misiones de reconocimiento, rescate, e incluso de combate cerrado. Sin embargo, es en los UAVs de corto alcance donde este tipo de vehículos ha logrado mayor acogida debido a la flexibilidad que proporcionan. Los vehículos VTOL con capacidades estacionarias vuelan gracias al impulso directo que ejercen los motores, generalmente aplicado a una o más hélices, sobre el aire. Esto hace que los motores deban estar en constante funcionamiento para mantener el vehículo en vuelo, por el contrario, en los vehículos de despegue ordinario con alas, gran parte de la fuerza necesaria para mantener el vuelo es ejercida por la resistencia de la carga alar sobre el aire, por lo que el consumo es menor. Dentro de los UAVs de corto alcance con capacidades estacionarias encontramos diversos modelos de vehículos de cuatro hélices, aunque también se encuentran en configuraciones de seis y ocho motores. Estos vehículos son especialmente interesantes al ser capaces de conseguir vuelos muy estables y tener una maniobrabilidad destacada. Son vehículos propulsados por motores eléctricos con autonomías que rondan los minutos, cubriendo de 2 a 5 kilómetros Carga de Pago En entornos aeronáuticos, se denomina carga de pago a aquella carga que es capaz de cargar la aeronave y que no es estrictamente parte de los sistemas de navegación y control de la misma. En el caso de los aviones de transporte de pasajeros o mercancías, la carga de

23 1.4. CARGA DE PAGO 7 Figura 1.5: Aeryon Scout de Aeryon Labs. UAV de cuatro motores con su estación de tierra. Rango de acción de 3 kilómetros a partir de la estación de tierra, cuenta con una cámara FLIR de visión nocturna autoestabilizada. Figura 1.6: RQ-4 Global Hawk UAV desarrollado por Northrop Grumman para la fuerza aérea estadounidense. Se trata de un UAV de tipo HALE capaz de cubrir distancias de hasta kilómetros, metros de altitud y hasta 36 horas de vuelo. Incluye capacidad de cargar con radar de alta resolución SAR (Synthetic Aperture Radar) y sensor electro-óptico e infrarrojo capaz de cubrir áreas de kilómetros cuadrados. Con un coste de 35 millones de dólares entró en operación en la guerra de Irak a finales de 2006.

24 8 CAPÍTULO 1. INTRODUCCIÓN Figura 1.7: Sensor electro-óptico térmico. Es uno de los sensores más demandados en los UAVs por su capacidad de tomar imágenes a grandes distancias y en diferentes condiciones ambientales. pago la conforman los pasajeros y las mercancías a transportar, en el caso de un UAV, se denomina carga de pago a los sistemas y equipos que son usados para generar información de utilidad táctica o de inteligencia. Una característica muy importante de los UAVs es el peso en carga de pago que es capaz de soportar la aeronave, ya que cuanto más carga de pago mayor número de sensores, cámaras, equipos de comunicaciones o armamento será capaz de soportar el UAV. Evidentemente, a mayor carga de pago, mayor consumo, por lo que los UAVs con menor autonomía soportan menores cargas de pago. Entre los equipos más utilizados como carga de pago en los diferentes UAVs contamos con todo tipo de sensores y equipos de medición, incluyendo cámaras fotográficas y de captura de video, cámaras de visión nocturna y con lentes capaces de captar diferentes espectros, sónar, rádar, sistemas láser, etc. También equipos y computadores encargados del procesamiento de dichas señales de manera embarcada son parte de la carga de pago, así como el armamento, en caso de que lo hubiera, como por ejemplo, ametralladoras, cohetes y hasta misiles de diferentes alcances. Los sensores y equipos con los que el UAV cuenta y que son usados por los propios sistemas de control y navegación del vehículo no son tomados en cuenta a la hora de definir la carga de pago del UAV. Entre estos sensores se pueden contar acelerómetros, giróscopos, completas unidades de medición inerciales, magnetómetros, barómetros, sistemas de posicionamiento tales como el GPS 1, y sistemas de comunicaciones por radio. Estos equipos no forman parte formalmente de la carga de pago, aunque también proporcionen información que unida a la de los equipos de la carga de pago puedan generar información útil o inteligencia Estación de Tierra En cualquier caso, además del vehículo no tripulado, es necesario contar con una estación en tierra o GCS (Ground Control Station) capaz de recibir la información que percibe el vehículo, y a través de la cual se pueda monitorizar y controlar toda la actividad del UAV. En algunos casos, esta estación está formada por una estación fija, en otros por una unidad móvil. En el caso de los vehículos militares, lo más común es contar con una unidad movil desplegable, desde la cual monitorizar y comandar al vehículo. 1 Global Positioning System (

25 1.6. SITUACIÓN EN ESPAÑA 9 Figura 1.8: Estación de Tierra GCS del UAV estadounidense de combate Predator. En el caso de UAVs de corto alcance, esta estación de tierra debe ser lo suficientemente flexible como para poder ser desplegada en campo por los operarios. Quizás cargada en una mochila dentro de un maletín debidamente protegido del exterior siguiendo los estándares militares, de modo que sea fácilmente desplegable y con una interfaz adecuada, de manera que sea capaz de proveer de información útil en unas condiciones de combate Situación en España En el caso de España existen diferentes proyectos para el desarrollo de UAVs con capacidades tanto de combate como de reconocimiento [27]. Actualmente la empresa Cassidian, perteneciente al grupo EADS 2 está desarrollando un demostrador tecnológico UAV de largo alcance con capacidades de vuelo sigiloso y combate llamado neuron. Se trata de un proyecto en el que participan distintos países europeos y en el cual España desarrolla toda la estación de control en tierra y el software asociado (incluido comunicaciones). España también participa en el programa Talarion (también a través de Cassidian) para el desarrollo, a nivel europeo, de un UAV ISTAR, aunque con la crisis iniciada en 2008 los presupuestos han sido congelados y las posibilidades de continuación del proyecto están en el aire. Adicionalmente existe un programa para el desarrollo de un UAV ISTAR de tipo MALE completamente nacional llamado ATLANTE, del cual tanto el Ministerio de Defensa como múltiples organismos civiles han mostrado interés en adquirir y cuyo primer vuelo está programado para Septiembre de Con el proyecto ATLANTE tanto la industria española como el Ejército están interesados en construir un demostrador tecnológico que desarrolle todas las capacidades necesarias para la construcción de este tipo de vehículos y, de esta manera, poner a España en la punta de lanza en lo que a tecnología UAV se refiere. La participación en el pastel de los UAVs a nivel nacional ha despertado el interés de pequeñas empresas y grandes corporaciones como Indra o Thales. 2 European Aeronautic Defence and Space Company

26 10 CAPÍTULO 1. INTRODUCCIÓN Figura 1.9: Demostrador tecnológico neuron. Un UAV de combate con capacidades de vuelo invisible (STEALTH). (Primer vuelo programado para 2012). Figura 1.10: ATLANTE UAV. Proyecto de UAV tipo MALE totalmente español que pretender ser un demostrador tecnológico de las capacidades del ejército y la industria española. (Primer vuelo programado para Octubre de 2011).

27 Capítulo 2 Objetivos 2.1. Descripción del Problema El objetivo de este Proyecto Fin de Carrera es la definición, diseño y construcción e implementación de un UAV de corto alcance (tipo Close) con características VTOL (despegue y aterrizaje vertical). En este capítulo se realizará primero una descripción general del objetivo a resolver. A continuación se resumirá la colección de requisitos impuestos al proyecto para, por último, definir la metodología utilizada durante todo el proceso de desarrollo. El proyecto en cuestión se divide en tres partes o subobjetivos bien diferenciados: 1. Diseño e integración hardware. Esto incluye la selección de dispositivos a integrar, el diseño de las placas de circuito, las conexiones y la integración con el microcontrolador. También el diseño y construcción del chasis del vehículo, la elección de componentes, así como la solución de los diferentes problemas técnicos derivados de la construcción física del vehículo y de su puesta en funcionamiento. 2. Especificación, diseño, implementación e integración del software que ejecutará en el microcontrolador embarcado del vehículo. Incluyendo la parte de comunicaciones, tanto aquellas destinadas a la telemetría, como las interfaces hardware para interactuar con todos los sensores y actuadores del vehículo, así como los módulos software encargados de la estabilización y navegación. 3. Especificación, diseño, implementación e integración del software correspondiente a la estación en tierra, incluyendo la interfaz gráfica de usuario. En este caso una completa aplicación gráfica que permite al operador monitorizar e interactuar con el vehículo. Sin olvidar las utilidades de depuración y pruebas. Estas tres partes diferenciadas suman características y dificultades muy diferentes, que abarcan desde el diseño e integración de componentes electrónicos, motores, baterías, sensores, etc., a la implementación de protocolos de comunicaciones por radio, algoritmos que sean capaces de procesar la información de los sensores de modo que pueda ser usada por algoritmos de estabilización, la implementación de esos mismos algoritmos de estabilización, pasando por el diseño e implementación de interfaces gráficas amigables y útiles. Sin olvidar 11

28 12 CAPÍTULO 2. OBJETIVOS Figura 2.1: Diagrama de componentes la costosa tarea de integración, depuración y pruebas de toda la plataforma que conforma el UAV, que por supupuesto ha de ser realizada con rigor. Aunque el objetivo principal es lograr que el vehículo resultante de este PFC sea funcional, el segundo objetivo, y no menos importante, es estudiar y poner en práctica todas las fases de desarrollo necesarias para la implementación de un proyecto de Ingeniería tan completo. Es decir, analizar las diferentes fases que conllevan este tipo de proyectos, los problemas encontrados, las diferentes maneras de resolverlos, los costes de desarrollo, la capacidad necesaria para poder desarrollarlos, y al final, estudiar y concluir, sobre el resultado obtenido, las características y peculiaridades de este tipo de proyectos. Al tratarse de un proyecto con una complejidad y dimensión elevada, ha sido necesario poner un límite al proyecto estableciendo unas características y funcionalidades bien delimitadas de modo que sea posible implementarlas en el marco de tiempo de un proyecto fin de carrera Requisitos En primer lugar se procederá a definir una serie de requisitos funcionales de alto nivel referidos a las capacidades y características del UAV que se desea implementar. En segundo lugar se definirán, para cada una de las tres partes que componen el proyecto, una colección de requisitos funcionales con un nivel de especificación mayor, que serán los que definan y limiten el marco del PFC. Dentro de estos requisitos se mezclarán requisitos funcionales, no funcionales y software (de bajo nivel). La intención no es presentar un documento de especificación de requisitos software (SwRD 1 ) sino orientar y limitar la dimensión del desarrollo. Los requisitos de alto nivel definen los aspectos que convierten al proyecto en un UAV 1 Software Requirements Document

29 2.2. REQUISITOS 13 de tipo Close: REQ1. El vehículo debe ser capaz de volar de manera autónoma, es decir, no radiocontrolado. REQ2. Debe ser capaz de despegar y aterrizar verticalmente, así como tener capacidades de vuelo estático estable. REQ3. Se debe contar con una estación en tierra para monitorizar el estado del vehículo, tanto parámetros de estabilización como de navegación. También se deben poder comandar determinados parámetros de navegación que se cargarán en el vehículo. REQ4. El vehículo debe ser capaz de seguir y mantener de manera autónoma un plan de vuelo comandado a través de la estación de tierra (dicho plan de vuelo se limitará en el marco del PFC a un vector de dirección). REQ5. Debe tener una autonomía de 2 kilómetros desde el punto de lanzamiento, con un techo de altitud de 300 metros. REQ6. La estación de tierra debe poder ser ejecutada en un portátil, de manera que el UAV pueda ser fácilmente desplegable. REQ7. El vehículo debe ser capaz de soportar una carga de pago útil de 200 gramos. Estos requisitos de alto nivel se convierten en las siguientes tres colecciones de requisitos de bajo nivel para cada una de las tres partes en las que se divide el proyecto Requisitos Hardware REQ8. El vehículo contará con cuatro motores con sus controladores de velocidad electrónicos ESC 2 encargados del impulso del modelo. REQ9. Contará con un chasis principal con cuatro brazos en forma de cruz de manera que los motores queden en los extremos de los brazos, la separación de los motores puede variar entre 40 y 70 centímetros. REQ10. Dispondrá de un soporte para mantener una batería de alta capacidad que alimentará tanto los motores como la unidad central de procesamiento UC. REQ11. La unidad central de procesamiento (UC) se situará en el centro del chasis e incorporará un microprocesador encargado de realizar todo el procesamiento. REQ12. La UC contará con una unidad inercial IMU (Inercial Measurement Unit) conformada por tres acelerómetros y tres giróscopos. También contará con un compás digital y un barómetro. Todos los sensores deben quedar perfectamente integrados en una placa de circuito consistente. REQ13. La UC dispondrá de un módulo de radio encargado de comunicar el vehículo con la estación de tierra. Dicho módulo debe tener la suficiente autonomía como para cubrir el techo de distancia del vehículo. 2 ESC: Electronic Speed Controller

30 14 CAPÍTULO 2. OBJETIVOS Requisitos Software Embarcado REQ14. El software debe ser capaz de comunicarse con los controladores de velocidad ESC s de cada uno de los cuatro motores de modo que sea capaz de inicializarlos y calibrarlos. REQ15. El software debe ser capaz de leer y procesar las lecturas de los sensores de modo que sea capaz de calcular a partir de las mismas el ángulo de inclinación que forma el modelo con los tres ejes de coordenadas. REQ16. También debe ser capaz de obtener adecuadamente los datos de altitud barométrica y temperatura. REQ17. El software debe implementar un protocolo de comunicaciones adecuado para poder comunicarse de manera inalámbrica a través del módulo de radio con la estación de tierra. Debe ser capaz de enviar datos de telemetría con la información disponible a través de sus sensores, así como recibir y procesar comandos a través de los cuales se pueda cambiar el vector de dirección a seguir. Así como otros parámetros como la potencia total de los motores y comandos especiales de reinicio, parada de emergencia, o configuración de estabilización. REQ18. El software debe ser capaz de transmitir diferentes tipos de mensajes a través del módulo de comunicaciones, incluyendo mensajes de depuración, warnings, alarmas, etc. REQ19. El software contará con un módulo de estabilización y otro de navegación. REQ20. El módulo de estabilización debe ser capaz de, tomando como entrada los valores leídos y procesados de la IMU, elegir la potencia adecuada a aplicar en cada uno de los motores para mantener el vehículo estabilizado en vuelo. REQ21. El módulo de navegación debe ser capaz de, tomando como entrada los valores leídos y procesados de la IMU, elegir los cambios en la potencia de cada uno de los motores de modo que el vehículo sea capaz de adquirir el vector de dirección demandado manteniendo el modelo estabilizado (módulo de estabilización tendrá mayor prioridad que el de navegación). REQ22. El software debe ser capaz de recibir y procesar un plan de vuelo consistente en una serie de vectores de dirección separados en el tiempo. REQ23. El software debe implementar algoritmos de emergencia (con alta prioridad), tales como aterrizaje de emergencia, estabilización en altura y otros del estilo que puedan ser comandados desde la estación de tierra, con independencia del plan de vuelo precargado con anterioridad. REQ24. El software debe estar lo suficientemente optimizado como para que en cada ciclo de ejecución el microprocesador sea capaz de realizar todas las tareas de lectura de datos, posterior procesamiento y comando de los actuadores, así como las tareas de comunicaciones y procesamiento de comando recibido, sin que ninguna de estas tareas sufran un retraso en su ejecución Requisitos de Estación en Tierra REQ25. El software de la estación en tierra (GCS) debe proporcionar una interfaz gráfica que permita al operador interacturar con el vehículo.

31 2.3. METODOLOGÍA 15 REQ26. La GCS debe proporcionar información del estado del enlace de datos con el vehículo, así como los comandos necesarios para establecer el enlace de datos. REQ27. La GCS debe proporcionar información sobre el estado del modelo, incluyendo los ángulos que forma con los ejes de coordenandas (Pitch, Roll y Yaw), también información sobre el rumbo actual del modelo (Heading), y de las diferentes medidas sin interpretar de los sensores de la IMU (aceleraciones lineales y velocidades angulares en los distintos ejes). REQ28. La GCS debe proporcionar una representación simplificada del vehículo en 3D de manera que el operador pueda conocer el estado del modelo sin tener visión directa del mismo. También debe contar con un PFD 3 en el que se represente un horizonte artificial con el alabeo (Roll) y cabeceo (Pitch) del modelo, así como una rosa de los vientos 4 que indique el rumbo (heading) del modelo respecto al norte magnético. REQ29. La GCS debe proporcionar la información de potencia comandada a cada uno de los motores, así como la posibilidad de cambiar manualmente la potencia total e individual de los mismos. REQ30. La GCS debe proporcionar una interfaz de calibración y pruebas donde se puedan realizar diferentes test de estabilización. REQ31. La GCS debe contar con una consola de texto a través de la cual se puedan recibir mensajes con diferente información del vehículo, incluyendo información de depuración y test, así como diferentes tipos de avisos y alarmas (Warnings). REQ32. La frecuencia de refresco de los valores de telemetría deben ser suficientes como para obtener una visión realista del estado actual del modelo por parte de los operadores. REQ33. La GCS debe poder ser ejecutada en un portátil con recursos limitados (Procesador Intel Atom N260 y 512 MB de RAM) de forma ágil y práctica Metodología Al tratarse de un proyecto con una carga de hardware muy elevada y con dos desarrollos software bien diferenciados (parte embarcada y estación de tierra) la metodología debe ser suficientemente flexible como para poder ser aplicada con éxito a cada uno de las partes del proyecto. Se decidió seguir una metodología basada en un proceso iterativo e incremental utilizado comúnmente en entornos guiados por un desarrollo ágil de software. De esta manera los incrementos del desarrollo software pueden servir para probar el desarrollo e integración de la parte hardware, permitiendo el avance y depuración de la parte hardware mientras se continúa el desarrollo del siguiente incremento software, tanto en su versión embarcada como de la estación de tierra. Para ello se definieron cuatro incrementos principales que suponen pequeños pasos tanto en software y hardware. Estos cuatro incrementos se definieron para cada uno de los tres subsistemas; hardware, software embarcado y estación de tierra. 3 Primary Flight Display 4 Rosa de los Vientos: circulo que tiene marcados alrededor los rumbos en que se divide la circunferencia del horizonte.

32 16 CAPÍTULO 2. OBJETIVOS Figura 2.2: Diagrama iterativo-incremental: Cada incremento pasa por las cuatro fases Figura 2.3: Cada uno de los tres componentes evolucionan simultáneamente en los incrementos, coincidiendo a la finalización de cada incremento en la fase de Integración y Pruebas.

33 2.3. METODOLOGÍA 17 Para cada uno de los incrementos se establecen cuatro fases: 1. Objetivos y Planificación 2. Análisis 3. Desarrollo (Implementación/Construcción) 4. Integración y Pruebas Siendo el punto de nexo común entre las tres partes la fase de pruebas e integración. El primer incremento se llamo V0 y se corresponde con la primera toma de contacto y aprendizaje sobre las diferentes plataformas de desarrollo software y hardware. Incluye la familiarización con los diferentes sensores y plataformas hardware a utilizar, sus interfaces, conexiones, etc. Por parte del software embarcado la familiarización con la plataforma de desarrollo elegida (Arduino), su entorno de ejecución, peculiaridades de depuración e integración con las comunicaciones serie. Por parte del software de la GCS supone una introducción al lenguaje de programación utilizado (Processing), la programación de interfaces 2D/3D con OpenGL 5 y las comunicaciones serie con la plataforma Arduino. El segundo incremento o V1 es el primer incremento con funcionalidad específica derivada de requisitos para cada uno de los subsistemas: Plataforma Hardware: Construcción de la primera versión del chasis del vehículo, integración de motores y ESC s, integración del módulo de comunicaciones radio con el microprocesador, conexiones eléctricas y primera versión de IMU. Software Embarcado: Descomposición preliminar en módulos, primera versión del protocolo de comunicaciones para permitir la transferencia de los primeros datos de sensores e información de depuración a la consola de la GCS, implementación de la adquisición de datos de aceleraciones y velocidades angulares, e inicialización y gestión de la potencia de los motores. Software GCS: Primera versión de la interfaz gráfica, modelo 3D del vehículo, primera versión del horizonte artificial, interfaz de comunicaciones, primera versión del protocolo de comunicaciones, enlace activo de datos con el vehículo tanto por radio como por cable serie (conexión directa a través de USB). El tercer incremento o V2 cuenta ya con una versión avanzada de prácticamente todas las funcionalidades de comunicaciones, estabilización y depuración del UAV: Plataforma Hardware: Segunda versión del chasis, integración en una placa de circuito de todos los sensores y microprocesador con las conexiones adecuadas, todo empaquetado en una caja. Desarrollo de una plataforma de test segura para realizar pruebas de estabilización. Posibles mejoras en sensores, interfaces, conectores, etc. Integración de la batería en el chasis. 5 OpenGL: Especificación estándar que define una API multiplataforma para producir gráficos 2D y 3D

34 18 CAPÍTULO 2. OBJETIVOS Software Embarcado: Mejoras en protocolo de comunicaciones, procesamiento de las lecturas de sensores, fusión de los datos para obtener los ángulos del vehículo con los ejes (Pitch, Roll y Yaw). Diseño e implementación del módulo de estabilización para la selección de salida a los motores a través de controladores de bucle cerrado PID s. Esta versión incluye la interfaz de calibrado y test dinámico de parámetros de estabilización. Software GCS: Mejoras en modelo 3D, desarrollo de PFD definitivo, herramientas de depuración y test, módulo de grabación y reproducción de datos con la capacidad de reproducir una sesión de calibrado y de vuelo. En el último incremento o V3 se añade la funcionalidad necesaria para poder llegar a realizar vuelos de prueba con la suficiente solidez, añadiendo pequeños detalles y solucionando posibles problemas encontrados: Plataforma Hardware: Tercera versión del chasis, integración del barómetro y sónar, cambios de conectores para mejorar montaje final, construcción de un paragolpes protector que facilite las pruebas de vuelo, instalación de la antena de telemetría definitiva. Software Embarcado: Integración de barómetro, sónar y compás digital. Integración en los bucles de control para controlar el rumbo. Optimización de los diferentes algoritmos, incluyendo comunicaciones. Software GCS: Optimización de la interfaz de mando y control, mejora de la disponibilidad y robustez de la aplicación, así como la inclusión de las utilidades necesarias para soportar las pruebas de vuelo.

35 Capítulo 3 Estudio de Alternativas Antes de entrar de pleno en el proceso de desarrollo es necesario realizar un breve repaso de los proyectos más significativos en el campo de los UAV s, ya que gracias a ellos se pueden eliminar alternativas no válidas en el diseño, o solventar problemas ya resueltos sobre los que no se desea profundizar demasiado. Se pueden encontrar, por un lado, proyectos de vehículos radiocontrolados que cuentan con cierto grado de autonomía, entre estos, se encuentran proyectos de aeroplanos radiocontrolados con microprocesador embarcado para facilitar y mejorar el control de vuelo. También vehículos de despegue vertical VTOL muy similares en configuración al objeto de este proyecto como [35],[1] o [45]. El grado de autonomía del vehículo es variable en cada proyecto, y va desde pequeñas funcionalidades de auto-estabilización para facilitar el control, hasta la plena autonomía del vehículo desde el despegue al aterrizaje, pasando por vehículos radiocontrolados con capacidades de vuelo en primera persona (haciendo uso de cámaras) e implementando módulos de telemetría muy completos [15] Mikrokopter Mikrokopter es un proyecto no libre de origen alemán desarrollado por la empresa HiSystems [24] con un estado muy avanzado de desarrollo. El objeto del proyecto es un UAV VTOL de tipo Close muy similar al objeto de este proyecto, aunque con diferentes configuraciones de motores, entre 4 y 8. Para controlar el Mikrokopter han utilizado un microprocesador Atmel ATMEGA644 a 200MHz como unidad central, la unidad inercial es un desarrollo cerrado propio. Las principales ventajas de este proyecto es que comenzó su desarrollo en 2006, por lo que tras 5 años de desarrollo tanto la plataforma hardware como el software son muy robustos y funcionales. Además de la unidad inercial, cuenta con un módulo de navegación opcional con GPS, 3 magnetómetros y soporte de tarjetas de memoria Flash, gestionado por un microcontrolador ARM9. La principal ventaja frente a proyectos similares es la capacidad de usar interfaces I2C 1 1 I2C:Inter-Integrated Circuit, bus de comunicaciones serie de dos lineas desarrollado por Phillips 19

36 20 CAPÍTULO 3. ESTUDIO DE ALTERNATIVAS Figura 3.1: Mikrokopter con una configuración de 8 motores. Figura 3.2: Módulo central de Mikrokopter. Figura 3.3: Módulo de navegación con GPS, el acabado de las placas está muy conseguido.

37 3.2. AEROQUAD 21 Figura 3.4: NicoletoMK basado en Mikrokopter (de los que se hablará en profundidad más adelante 7.2.1) para comandar potencia a los controladotes de velocidad, ya que esto permite tasas de actualización del orden de 450 Hz en la salida a los motores, lo que les permite tener un control muy fino sobre la potencia de los mismos, desembocando en un régimen de estabilización muy alto. Además cuentan con la experiencia de haber realizado gran cantidad de pruebas con diferentes configuraciones, por lo que las características de potencia de los motores, distancia entre los mismos, tamaño de las hélices, capacidad de las baterías, así como otras características físicas del vehículo son aspectos a tener en consideración. Por lo menos para tener la seguridad de que es posible llegar al objetivo con hardware y configuraciones similares. El estado de desarrollo es muy alto, cuentan con una estación de tierra muy completa, y el sistema es muy configurable, de modo que se puede desde radiocontrolar el vehículo apoyadándose en su control de estabilización, hasta realizar un plan de vuelo completo con waypoints editables desde la GCS, pasando por la implementación de rutinas acrobáticas automáticas. También es un buen proyecto para comparar el rendimiento conseguido con el desarrollo de este PFC, teniendo en cuenta las diferencias en presupuestos y recursos, tanto de tiempo, como de desarrolladores. Sobre la base de Mikrokopter existen otros proyectos orientados a explotar comercialmente las posibilidades del vehículo, como NikoletoMK [35] 3.4, que ha mejorado el chasis y ha añadido una plataforma auto estabilizadora avanzada dedicada a la grabación de vídeos aéreos en alta definición Aeroquad Aeroquad es un proyecto open source de un UAV con las mismas características que Mikrokopter. Cuenta con la ventaja de que es open source y que además la plataforma hardware sobre la que se desarrolla también es abierta [1]. Aeroquad se basa en la plataforma Arduino para construir la unidad central (ATmega 328 a 16 MHz), sobre esta plataforma se profundizará en el capítulo de plataforma de desarrollo 4.1.

38 22 CAPÍTULO 3. ESTUDIO DE ALTERNATIVAS Figura 3.5: Aeroquad radiocontrolado Aunque no cuenta con el nivel de finalización que tiene mikrokopter es un proyecto interesante en cuanto a que todo el código es accesible y los resultados obtenidos son muy buenos, si bien, es cierto que estos resultados dependen de la calidad de los sensores y circuitos utilizados, siendo necesario un alto desembolso económico para poder replicar el proyecto original. Además, una de las desventajas de este proyecto es que, pese a ser un proyecto libre, intentan comercializar tanto con el hardware como con el soporte, por lo que es complicado obtener ayuda de la comunidad alrededor del mismo Ardupilot Ardupilot es un proyecto open source dedicado a obtener una unidad de navegación inercial libre, basada en la plataforma Arduino. Esta unidad de navegación puede ser utilizada en diferentes proyectos, por un lado en aeronaves radiocontroladas, por otro en proyectos de vuelo en primera persona (radiocontrolado pero sin visión directa del vehículo y controlándolo a través de cámaras instaladas en el vehículo), y por último en todo tipo de UAV s, tanto de despegue vertical como tipo aeroplano. Es un proyecto maduro, que cuenta con una buena comunidad alrededor que comercializa las placas de control en diferentes niveles de integración. La ventaja principal del proyecto es que han resuelto muy bien el problema de la fusión de datos de diferentes sensores usando tanto filtros kalman avanzados, como algoritmos basados en matrices de cosenos directrices (DCM 2 ). Cuentan en su comunidad con una verdadera eminencia en el desarrollo del algoritmo de Matrices de Cosenos Directrices como W. Premerlani [43], y cuentan con un código muy 2 DCM: Direction Cosine Matrix

39 3.3. ARDUPILOT 23 Figura 3.6: Ardupilot: unidad de navegación inercial. Figura 3.7: Ardupilot sobre un Easy Glider, implementa funciones de piloto automático. optimizado. Por lo que este proyecto es una gran fuente de conocimiento en el caso de tener problemas con este tipo de algoritmia. Existen diferentes proyectos basados en el código de fusión de datos de Ardupilot. El proyecto pertenece a una comunidad aún mayor llamada DIYDrones (Do It Yourself Drones) [15] orientada al desarrollo de UAVs a pequeña escala basados, sobretodo, en aeroplanos. Por último existen diferentes proyectos orientados al mismo fin que no son tan significativos, en algunos casos porque son clones de los anteriores o basados en ellos, y en otros porque se trata de desarrollos cerrados tanto en hardware como software [39], aunque son dignos de mención al tener disponible información útil de alguna manera para este PFC. Entre ellos esta Quaduino [45], un proyecto personal de UAV cuadrimotor que toma como base el software de Ardupilot. También UAVP [34] un proyecto alemán dirigido a conseguir un mikrokopter de código abierto basado en plataformas hardware propias y soluciones de sensores diferentes. También MiKuadricoptero [16], un proyecto open source español con motivaciones didácticas que comenzó en tiempo a la vez que este PFC y que, aunque finalmente el desarrollo de Mikuadricoptero fue sustancialmente más lento que el de este PFC, en las primeras fases fue de gran ayuda conocer diferentes maneras de afrontar problemas similares.

40 24 CAPÍTULO 3. ESTUDIO DE ALTERNATIVAS

41 Capítulo 4 Entorno de Desarrollo 4.1. Arduino La primera elección importante dentro del proyecto fue la de seleccionar la plataforma hardware y el entorno de desarrollo. En primer lugar se debe elegir el microcontrolador y la arquitectura sobre la que desarrollar el software embarcado. Existen distintas soluciones muy diferentes unas de otras, desde usar microcontroladores tipo PIC 1 con arquitectura RISC 2 utilizando directamente lenguaje ensamblador, hasta utilizar un computador embebido tipo PC/104 [41] con una arquitectura similar a la de un PC corriente y usando un lenguaje de alto nivel, pasando por plataformas intermedias basadas en diferentes microcontroladores (ARM 3 u otros diseños RISC) con entornos de desarrollo propios, amigables y prácticos, como los basados en la plataforma.net MicroFramework 4, o Arduino. Tras analizar los proyectos de UAVs similares y comparar las diferentes opciones de plataformas de desarrollo se decidió usar la plataforma Arduino. Las principales razones para usar dicha plataforma fueron: Por un lado las ventajas de ser una plataforma abierta, tanto en software como en hardware y con una amplia comunidad alrededor. Esto posibilita el fácil acceso a foros de ayuda tanto de desarrollo software embarcado como de integración de la plataforma con diferentes soluciones hardware, incluyendo integración con gran cantidad de sensores y actuadores. En segundo lugar, la existencia de dos o tres proyectos de código abierto con objetivos comunes con este PFC y basados en la plataforma Arduino, siendo el más importante de ellos ArduPilot. Estos precedentes garantizan la seguridad de que la plataforma es válida, además de proveer una vía de comunicación a través de la que se puede pedir ayuda en caso de ser necesario. 1 Peripheral Interface Controller 2 Reduced Instruction Set Computer 3 ARM: Advanced Risc Machines 4.NET Microframework es una plataforma open source.net para usar en dispositivos de recursos limitados que incluye versiones reducidas de las principales librerías y utilidades.net com/en-us/netmf/default.aspx 25

42 26 CAPÍTULO 4. ENTORNO DE DESARROLLO Figura 4.1: Plataforma hardware Arduino UNO. Por último la familiaridad con el entorno debido a experiencias anteriores con la plataforma, y el conocimiento de las posibilidades tanto del software como de las interfaces externas con las que cuenta. Arduino es una plataforma muy flexible de hardware/software abierto para el desarrollo de proyectos de electrónica. Básicamente cuenta con una placa diseñada alrededor de un microprocesador ATmega328 de Atmel de 16MHz que cuenta con 14 entradas/salidas digitales y 6 entradas analógicas, 32 KB de memoria Flash, 1 KB de memoria EEPROM y 2 KB de SRAM. Para programar el microprocesador se utiliza un lenguaje de programación propio (Arduino Programming Languaje) basado en Wiring [9] y un entorno de desarrollo (Arduino Development Environment) basado en Processing [10], [3]. El lenguaje es de tipo estructurado con una sintaxis similar a la utilizada por el lenguaje Java. El entorno de desarrollo permite desplegar el código fácilmente a través de una interfaz USB que conecta con la placa Arduino. Entre las ventajas de la placa Arduino se encuentran la disponibilidad de un controlador UART para comunicarse a través de puerto serie, una interfaz USB para comunicación con el entorno de desarrollo Arduino, puertos para comunicaciones serie I2C muy utilizado en sensores digitales, soporte de comunicaciones SPI 5, soporte de salidas de modulación por ancho de pulsos PWM 6, en definitiva grandes posibilidades de integración con circuitos y dispositivos electrónicos. Dentro de la plataforma Arduino existen diferentes configuraciones de placas. Aunque todas cuentan con similares características principales y son compatibles entre sí, se diferencian entre ellas por el nivel de integración y por las capacidades del microprocesador. La versión estándar de Arduino en la fecha de presentación de este documento es la llamada Arduino UNO, basada en el micro Atmega328. Con las mismas características de la 5 SPI: Serial Peripheral Interface Bus 6 PWM: Pulse Width Modulation es una técnica utilizada para control de dispositivos electronicos inerciales, consiste en codificar un voltaje midiendo la longitud de pulsos on/off que se envían. http: //en.wikipedia.org/wiki/pulse-width_modulation

43 4.1. ARDUINO 27 Figura 4.2: Placa Arduino Nano, mayor nivel de integración manteniendo las características y compatibilidad. Figura 4.3: Mini, el más pequeño de todos los Arduinos. Figura 4.4: Plataforma Seeeduino. Basado en Arduino, cuenta con un diseño optimizado y diferentes mejoras y optimizaciones en las prestaciones.

44 28 CAPÍTULO 4. ENTORNO DE DESARROLLO Figura 4.5: Entorno de desarrollo Arduino. versión estándar pero con mayor nivel de integración aparecen las versiones Arduino Nano, con un tamaño aproximado de una tercera parte de la versión UNO, y Mini, con un tamaño de la mitad del Nano. También existe una versión UNO que en lugar de usar un microcontrolador con formato extraible DIP 7 usa uno de montaje superficial SMD 8. También se puede encontrar una versión extendida llamada Arduino Mega que cuenta con un micro ATmega2560 con mayor memoria y número de entradas analógicas/digitales. El proyecto Arduino cuenta, a su vez, con bifurcaciones que, tomando como base la plataforma Arduino, han realizado modificaciones en el hardware para dotar al mismo de mejoras, tanto en diseño optimizado hardware como en las características del mismo, mayor número de entradas/salidas, reguladores de tensión, interfaces de comunicaciones, etc. Cabe destacar un proyecto alternativo basado en Arduino llamado Seeeduino desarrollado por la comunidad Seeed Studio [47]. Este proyecto proporciona características funcionales extendidas que mejoran el diseño original (diodo zener 3v3 integrado, soporte de mayor amperaje en las salidas, conector mini USB, entrada de potencia tipo JST y conectores inferiores para integrar la placa en una placa de prototipado). 7 DIP: Dual in-line Package es una forma de encapsulamiento de circuitos integrados donde los pines del circuito quedan dispuestos en hileras paralelas 8 SMD: Surface Mount Technology, una forma de encapsulamiento más compacta donde el circuito se monta directamente en la placa o PCB(Board)

45 4.2. PROCESSING 29 Aunque en el primer prototipo V1 de la plataforma hardware se utilizó una versión anterior del Arduino UNO llamado Arduino Duemilanove, en los dos siguientes prototipos se utilizó un Seeeduino V Processing Una vez seleccionada la plataforma de desarrollo hardware y software embarcado, es necesario seleccionar el lenguaje y entorno de desarrollo para la estación de tierra (GCS). Para el desarrollo del software de GCS las posibilidades eran aún mayores, ya que dicho software se ejecuta en una plataforma PC (un ordenador portátil), por lo que se podía haber seleccionado cualquier lenguaje de alto nivel. Dados los requisitos de la interfaz gráfica de la estación en tierra, el lenguaje debía facilitar el dibujado de gráficos 3D/2D. Aunque casi todos los lenguajes se integran fácilmente con las API s 9 de representación de gráficos 3D/2D como OpenGL o DirectX, se decidió usar Processing [10] dada su especial compatibilidad con la plataforma Arduino. Processing es un lenguaje y entorno de programación de código abierto para el desarrollo de aplicaciones gráficas interactivas y proyectos multimedia basado en bocetos o sketches. Al estar basado en Java puede heredar todas las funcionalidades del mismo así como extenderse y usar todo tipo de librerías ya creadas para dicho lenguaje. Además provee una interfaz de programación para la visualización de gráficos muy intuitiva y con soporte de OpenGL. Los desarrolladores de Arduino tomaron como modelo el lenguaje y el entorno de desarrollo de Processing PDE (Processing Development Environment), por lo que la integración de proyectos software/hardware Arduino con aplicaciones Processing es muy completa. Una consecuencia de esta complicidad es la unificación de la sintaxis de ambos lenguajes. Aunque uno tome como base Java (Processing) y otro Wiring/C (Arduino) el formato y estructura de los ficheros de código fuente es muy similar, por lo que la curva de aprendizaje disminuye considerablemente. Tanto Processing como Arduino cuentan con un modelo de ejecución basado en un planificador cíclico. La manera de programar en ambos lenguajes es a través de sketches. Un sketch no es más que un código estructurado en dos métodos principales. El primer método es el procedimiento de setup o inicialización, que se ejecutará una sola vez al comienzo de la ejecución del programa y antes que cualquier otro. Sirve para inicializar las diferentes variables, estructuras, librerías o aquello que sea necesario. Tanto en Arduino como en Processing este procedimiento está instrumentalizado en la función setup(). El otro método se ejecutará de manera cíclica. En el caso de Arduino toma el nombre de loop(), mientras que en Processing es void draw(). Aunque estos métodos se ejecuten una vez en cada ciclo, el diseñador puede utilizar las diferentes estructuras de control para definir los periodos de ejecución que desee, implementando un completo planificador que seleccione el código a ejecutar en cada ciclo. En el caso de Arduino, el método loop() hace de punto de entrada a la ejecución, pudiendo estructurar la misma en diferentes métodos y funciones, teniendo en cuenta que el paradigma de programación es estructurado, y que la memoria y velocidad de procesado son limitados. 9 Application Programming Interface

46 30 CAPÍTULO 4. ENTORNO DE DESARROLLO Figura 4.6: Entorno de desarrollo Processing. Por esta última razón en algunos casos se ha preferido una codificación optimizada y eficiente frente a un código legible (elección de estructuras de control, dominio de las variables, etc.). Por otro lado Processing permite cierta flexibilidad a la hora de programar. Se puede utilizar el lenguaje para implementar código similar al scripting pero sin ser interpretado. También se puede utilizar toda la potencia del paradigma orientado a objetos que facilita Java. En este caso al no tener problemas de memoria o velocidad de ejecución tan importantes como el caso de Arduino, se ha preferido usar siempre un enfoque orientado a objetos siguiendo los preceptos de abstracción, encapsulación y modularidad. Conceptos que se han aprovechado especialmente a la hora de desarrollar elementos gráficos flexibles que puedan ser instanciados varias veces, y la composición de elementos gráficos complejos a partir de elementos simples.

47 Capítulo 5 Análisis Antes de entrar en el detalle del desarrollo es necesario realizar un pequeño análisis del problema a resolver. Ya que el objeto del proyecto es desarrollar un vehículo aéreo no tripulado, en primer lugar cabe preguntarse cómo hacer que el vehículo sea capaz de elevarse, y cuáles son los mecanismos disponibles para controlar el vehículo Principios de Sustentación y Movimiento La configuración de cuatro motores en los extremos de una cruz, que le confieren la característica de despegue y aterrizaje vertical, también hace que el vehículo no se apoye en planos aerodinámicos fijos para lograr el empuje necesario para elevarse, tal y como sucede en los vehículos con configuración de aeroplanos. Para elevar el modelo es necesario conseguir un empuje hacia abajo cuyo resultado sea una fuerza inercial hacia arriba que venza la fuerza de la gravedad elevando así el vehículo. Dicho empuje es generado por el rozamiento de los planos de las hélices con el aire debido al giro. Cada hélice está formada por dos palas, cuya forma es tal que el plano de cada pala no es paralelo al plano XY de la horizontal, sino que se encuentran giradas formando un ángulo con la horizontal. De esta manera, al girar la hélice se ejerce un empuje sobre el aire en dos componentes por cada pala, donde una de ellas será vertical. El sentido del giro de la hélice se elige de manera que la componente vertical sea hacia abajo. El ángulo de una pala es el inverso del de la contraria para que ambos empujes tengan el mismo sentido. El resultado es una fuerza inercial hacia arriba sobre todo el conjunto 5.1. Sin embargo, no es la única componente generada, el empuje del plano de la hélice contra el aire es perpendicular al plano de cada pala, por lo que existe una componente horizontal que sigue el sentido del giro de las palas. Estos empujes resultan en una fuerza inercial en el sentido contrario al giro de cada pala. Cada hélice esta formada por dos palas que forman ángulos contrarios con el plano, por esta razón la componente horizontal inercial en cada pala está formada por el mismo vector pero con sentidos contrarios. Esto hace que las componentes lineales se anulen, pero aparece un momento en sentido contrario al giro de la hélice tal y como se muestra en 5.1. Al sumar todas las fuerzas ejercidas queda una resultante vertical hacia arriba y un momento en el sentido contrario al giro de la hélice. Con un solo motor el vehículo se elevaría, pero también giraría sobre el eje del motor 31

48 32 CAPÍTULO 5. ANÁLISIS Figura 5.1: Diagrama de descomposición de las distintas fuerzas, así como la fuerza inercial resultante y el momento angular resultante. Figura 5.2: Inerciales y momentos resultantes: Se pueden ver las inerciales y momentos que aporta cada hélice al conjunto.

49 5.1. PRINCIPIOS DE SUSTENTACIÓN Y MOVIMIENTO 33 Figura 5.3: Inercial total y momento angular total del conjunto. El momento total es nulo. en el sentido contrario al giro del mismo. Si en lugar de uno contamos con dos motores en paralelo separados por una distancia, y sentidos contrarios entre sí, los momentos debidos al giro de cada motor se superpondrían. Anulándose el momento total sobre el conjunto del vehículo (suponiendo misma velocidad de giro en ambas hélices). Sin embargo, para permitir al vehículo moverse con los diferentes grados de libertad con solo dos motores sería necesario contar con la capacidad de controlar el ángulo que forma el plano que se abstrae del giro de las hélices respecto a la horizontal. Inclinando dichos planos la inercial resultante, antes vertical, ahora tendría otras componentes, y jugando con dichas componentes se conseguiría el movimiento en las diferentes direcciones. Controlar los ángulos que forman hélices y horizontal es complicado ya que la mecánica debe permitir el giro independiente de cada bloque motor. Mientras que añadiendo dos motores más al conjunto y jugando con las potencias suministradas a cada motor, se pueden conseguir las diferentes resultantes que hacen que el vehículo se mueva con los grados de libertad deseados. En la figura 5.2 aparecen los momentos e inerciales para cuatro motores. Para facilitar el control y simplificar el modelo teórico de componentes, lo ideal es situar los motores de manera que los planos de las hélices sean los mismos y paralelos al plano horizontal, formando los vértices de un cuadrado, situando los dos motores que giran en el mismo sentido en los vértices de la diagonal del cuadrado. De esta manera, para elevar el vehículo tan solo es necesario aplicar la misma fuerza angular a cada hélice, así las diferentes componentes horizontales quedarían anuladas, además del momento angular del conjunto 5.3, quedando tan solo la fuerza inercial vertical hacia arriba que haría que el vehículo se elevase. En la figura 5.4 se muestran los diferentes ángulos de movimiento y los ejes de giro para cada tipo de movimiento, que se describirán detalladamente a continuación.

50 34 CAPÍTULO 5. ANÁLISIS Figura 5.4: Relación de ángulos pitch, roll y yaw Pitch Si consideramos uno de los lados del cuadrado que forman los motores como el frente del vehículo y trazamos una línea recta perpendicular a dicho lado que cruce el plano del vehículo, estaríamos definiendo el eje de cabeceo. Se llama ángulo de cabeceo o pitch al ángulo que forma dicho eje con el plano horizontal de referencia. Cuando el ángulo pitch es positivo el vehículo se encuentra inclinado hacia atrás, de manera que el frente o cabeza del vehículo mira hacia arriba, de igual manera, cuando es negativo el frente del vehículo mirará hacia abajo. Así, cuando el vehículo está completamente horizontal el ángulo de pitch será 0, y si el vehículo se encuentra perpendicular a la horizontal el pitch será 90 o -90 dependiendo de la orientación del mismo. Figura 5.5: Para ganar ángulo de pitch aumenta el empuje de los motores frontales respecto al resto, de manera que aparece un desplazamiento horizontal asociado.

51 5.1. PRINCIPIOS DE SUSTENTACIÓN Y MOVIMIENTO 35 Figura 5.6: Para que el vehículo se incline ganando roll, aumenta la potencia de los motores laterales respecto al resto, como consecuencia aparece un desplazamiento lateral asociado. Para avanzar en una determinada dirección, la técnica utilizada por este tipo de vehículos aéreos consiste en desequilibrar el mismo, de manera que la resultante inercial tenga una componente horizontal en la dirección deseada, tal y como se muestra en la figura 5.5. Los dos motores que quedan en los extremos del lado del cuadrado que hemos denominado frente son los dos motores frontales. Si se proporciona mayor velocidad angular a dichos motores se producirá un mayor empuje del frente del vehículo, haciendo que el vehículo comience a girar sobre sí mismo ganando ángulo de pitch. Al girar el modelo sobre sí mismo se genera una componente horizontal en el empuje que permitirá moverse hacia atrás a todo el conjunto. Las velocidades de rotación de los motores deben compensarse de modo que el vehículo gire sobre sí mismo hasta alcanzar un pitch determinado que sea capaz de mantener. Al aumentar la potencia de los motores delanteros es necesario regular la potencia de los traseros para que la componente vertical se mantenga constante y, de esta manera, el vehículo se mantenga estable en la vertical. Al ser el giro de los dos motores delanteros contrario entre sí (al igual que ocurre con los traseros), se anularán los momentos por lo que no existirá ningún otro giro. Para hacer el vehículo avanzar hacia delante se realiza la misma estrategia pero logrando un pitch negativo, la cabeza del vehículo mirará hacia abajo Roll Si análogamente al eje de pitch se traza un eje perpendicular que atraviesa longitudinalmente el plano del vehículo se obtendrá el eje de alabeo o roll. El ángulo formado por dicho eje con el plano horizontal se denomina ángulo de alabeo o simplemente roll. De la misma manera que en el caso del pitch, se puede lograr movimiento lateral si se aumenta la velocidad de giro de dos motores de un mismo lateral de forma que se logre un

52 36 CAPÍTULO 5. ANÁLISIS Figura 5.7: Esquema de giro Yaw. Para que el vehículo gire sobre sí mismo se aumenta la potencia por igual a una de las parejas de motores que giran en el mismo sentido respecto al otro par, como consecuencia aparece un momento angular no nulo que permite el giro. determinado ángulo de roll tal y como se muestra en la figura 5.6. En cualquiera de los casos (pitch o roll), se podría lograr que el modelo girara sobre sí mismo completamente aplicando la suficiente diferencia de potencia en los motores de dos extremos. Sin embargo, este giro completo vendría acompañado siempre por un movimiento de traslación ya que el empuje de todos los motores tiene el mismo sentido (dado por la geometría de las hélices). Aunque esta traslación en los giros puede ser corregida una vez alcanzada la posición deseada Yaw El giro sobre sí mismo del vehículo mientras se mantiene en el plano horizontal (pitch y roll nulos) se denomina guiñada o yaw. Para lograr este tipo de giro el plano del vehículo permanece horizontal, y el desequilibrio no afecta a las componentes lineales del empuje, sino a los momentos resultantes de los giros. En los casos anteriores de pitch y roll, se establecía siempre la misma velocidad angular a pares de motores con sentidos de giro contrarios para mantener el momento total nulo. Sin embargo, en la figura 5.7 se puede ver como si se da diferente potencia a motores con giros contrarios aparece un momento angular que hace girar sobre sí mismo el vehículo. Este desequilibrio del momento angular no afecta a las componentes lineales debido a que se proporciona la misma velocidad angular por pares de motores que giran en el mismo sentido y que se encuentran situados en la misma diagonal. Para girar en un sentido u otro tan solo hay que elegir adecuadamente los pares de motores a potenciar, de manera que el momento tenga un sentido u otro.

53 Capítulo 6 Plataforma Hardware En este capítulo se describirá el diseño e implementación de la plataforma hardware, incluyendo la integración hardware, así como las dificultades encontradas y la solución propuesta a cada una de ellas. El capítulo se divide en tres secciones, una dedicada a la estructura física, otra a los sensores y la última al diseño de la placa que conforma la unidad central. Dentro de cada sección se diferenciará entre los tres prototipos resultantes de cada incremento realizado definiendo los avances entre cada uno de ellos Estructura Física La estructura básica o chasis del vehículo es parte fundamental del proyecto ya que de ella depende la corrección de las asunciones realizadas respecto al control del modelo. Tal y como se ha descrito en el capítulo de análisis, el vehículo estará equipado con 4 motores montados en una estructura que permita mantener los motores equidistantes. Además dicha estructura debe permitir montar una unidad central que ocupa espacio al estar formada por una unidad de procesamiento, todos los sensores, las baterías, los controladores de los motores, incluso la antena de comunicaciones, además del cableado que permite la interconexión de todos los elementos. Para la estructura principal existen diferentes alternativas, desde construirla en madera de balsa mezclada con diferentes materiales livianos, hasta usar varillas de fibra de carbono. Sin embargo, existen multitud de proyectos de multicópteros que permiten adquirir parte del chasis por separado, como Mikrokopter, por lo que se decidió no perder demasiado tiempo en la construcción del chasis y se optó por comprar un chasis básico de Mikrokopter. Dicho chasis está formado por cuatro varillas de aluminio que se unen en una cruceta central. En dicho chasis se pueden montar los motores en los extremos. La distancia elegida entre motores fue de 50 cm que se corresponde con la distancia entre motores de los modelos más grandes de Mikrokopter o Aeroquad. Los motores elegidos fueron unos HackerStyle Outrunner 20-20L. Estos motores sin escobillas son capaces de girar a 1050 rpm (revoluciones por minuto) por Voltio y precisan unos 15 Amperios de media (con picos de 19 A), alimentados a través de controladores 37

54 38 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.1: Chasis básico de Mikrokopter Figura 6.2: Conjunto de motor con hélice APC de 4.7 x 10 o variadores electrónicos de velocidad ESC comúnmente utilizados en radio control y que fuesen capaces de soportar dicho amperaje. Estos motores se escogieron tras un análisis de las diferentes alternativas teniendo en cuenta el peso, potencia, amperaje y tasa de giro por voltio (en el Apéndice 12 se puede consultar la comparativa). Junto con los motores se estudiaron las hélices, seleccionando unas hélices de 4.7 x 10 de la marca APC, elegidas por su rendimiento de empuje en relación con resistencia. En el Apéndice 12 se puede observar la comparativa de hélices respecto a empuje y consumo Incremento V1 Para el primer incremento se usaron los motores descritos anteriormente en conjunto con los ESC Turnigy Plush 30. Dichos variadores soportan picos de hasta 30 A a 11.1 V, suficiente para dar el mayor rendimiento a los motores/hélices. Para alimentar dichos variadores se eligió usar baterías de Litio Polímero (LiPo) dado su

55 6.1. ESTRUCTURA FÍSICA 39 Figura 6.3: Detalle de los ESC s con los conectores cambiados para facilitar la conexión con la UC Figura 6.4: Primer banco de pruebas gran relación peso capacidad. Para este incremento se usaron baterías LightMax formadas por tres celdas de 3.7 V. Estas baterías soportan una tasa de descarga de hasta 20 A y cuentan con una capacidad de 1500 mah (Miliamperios/Hora). Para más información sobre las baterías LiPo y sus peculiaridades se puede consultar el Apéndice 12. En lo que respecta a la unidad central de proceso (UC), ésta no contaba con soporte aún y quedaba sujeta a través de un velcro a la parte central del chasis. Las conexiones entre UC y ESC s se realizan usando los conectores originales de los ESC s de radio control. Como en este primer incremento aún no se podía usar el chasis final para probar, se construyó un banco de pruebas en madera, simulando uno de los ejes, dos motores con sus ESC s y una visagra central de modo que se pudiera mover como un balancín En el capítulo de Pruebas 10 se dan detalles sobre los bancos de tests. Para estas pruebas se utilizó una fuente de alimentación para no malgastar ciclos de carga/descarga de las baterias y evitar perder tiempo entre cargas.

56 40 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.5: Detalle de plataforma aislante, soporte de baterías y variadores ESC HK finales Incremento V2 Para el segundo incremento se construyó un banco de pruebas avanzado que permitiera ajustar el chasis del vehículo entre dos posiciones elevadas, de modo que se dejase libre un solo eje del vehículo para probar la estabilización. En este incremento también se cambió el soporte de la UC por una caja de un polímero resistente. Se diseñó una pequeña plataforma de metacrilato para unir el soporte de la UC con la parte central del chasis a través de velcro. Por último se realizó un soporte inferior para las baterías también usando metacrilato. También se cambiaron los conectores originales de los ESC s de tres cables por otros de dos cables (ya que solo se necesitaba la línea de tierra y la de control, ver Apéndice 12 ). En esta iteración se realizaron tests con baterías de 1500 mah y de 1800 mah para analizar el consumo y autonomía del vehículo Incremento V3 En la última iteración se procedió a cambiar el cableado para ajustarlo de modo que quedasen los cables lo más ordenados y el modelo más compacto. Sin embargo, al cambiar el cableado de los ESC s y cambiar de nuevo los conectores por otros más idóneos ocurrió un accidente con los ESC s que hizo que se estropeasen dos de ellos. Al ir a sustituirlos resultó que no existía stock de dicho modelo, por lo que hubo que adquirir cuatro ESC s nuevos diferentes. Se optó por los más económicos que cumpliesen las características de Rpm por Voltio, seleccionando unos HobbyKing SS Series que soportan picos de 20 A (menos que los Turnigy), pero pesan menos y son más económicos. Adicionalmente se adquirieron varias baterías de distinta capacidad, incluyendo una de 4000 mah y 360 gramos de peso (las anteriores de 1800 mah pesaban 160 gramos), para poder hacer pruebas de autonomía y poder seleccionar las que mejor relación diesen.

57 6.2. SENSORES 41 Figura 6.6: Protector de poliestireno usado en pruebas de vuelo. Debido a un problema con las vibraciones trasladadas desde los motores a la unidad central y a la distorsión que provocaba dicha vibración en los sensores, se estudiaron varias soluciones para aislar la UC. Entre las soluciones estaba el uso de un gel dieléctrico para envolver a la unidad inercial, el uso de gomas para amortiguar el anclaje de los motores al chasis y la construcción de una plataforma aislante para el anclaje de la UC al chasis. El gel dieléctrico se descartó por el alto coste. Se dispusieron gomas entre los motores y el chasis y se construyó la plataforma aislante a base de varias capas de metacrilato y polietileno elastificado unidas por cola de contacto (Fig.6.5). La solución aislante resultó todo un éxito al hacer desaparecer casi al completo las vibraciones y liberar a la UC de costosos filtros software para paliar el efecto de las mismas. Por último, para poder realizar pruebas completas de estabilización fuera del banco de pruebas, se construyó un protector formado por cuatro placas de poliestireno expandido cubriendo todo el chasis, como se muestra en la fig 6.6 se dejan aperturas para las hélices y la antena de comunicaciones. De esta manera se pueden realizar pruebas más seguras al proteger las hélices de posibles choques Sensores Los sensores involucrados en la estabilización del vehículo deben proporcionar las entradas suficientes para que la UC pueda calcular con precisión los ángulos que forma el vehículo respecto a los diferentes ejes de referencia. Básicamente se trata de encontrar los ángulos que separan los ejes del modelo de los ejes que forman el sistema de coordenadas de referencia, teniendo en cuenta que no podemos asegurar que el modelo no está en movimiento, ni tampoco que no cuenta con cierta aceleración en alguno de sus ejes, por lo que el modelo puede considerarse un marco de referencia no inercial. Por lo tanto, el conjunto de sensores y algoritmos matemáticos, necesarios para conocer

58 42 CAPÍTULO 6. PLATAFORMA HARDWARE con precisión los ángulos de estabilización, deben ser capaces de calcular dichos ángulos independientemente de si el modelo está acelerado o no. Este conjunto se denomina IMU (Inercial Measurement Unit) o unidad de medición inercial, ya que permite calcular la orientación exacta del vehículo respecto al eje de referencia de la tierra independientemente de si el vehículo está acelerado o no. Aunque existen soluciones de IMUs completas que solucionan el cálculo de los ángulos, éstas son soluciones caras. Además se consideró interesante analizar y resolver este problema como una parte más del proyecto. Por esta razón se decidió implementar los algoritmos y construir la IMU a partir de los sensores implicados para lograr una IMU eficiente de bajo coste. Para la construcción de una IMU existen varios tipos de sensores en el mercado. El primero es el grupo de sensores que miden aceleraciones lineales o acelerómetros. Estos sensores son capaces de medir la aceleración instantánea que sufre el vehículo en un eje concreto en un momento dado. Dentro del marco de referencia de la tierra, cualquier objeto con masa está sometido constantemente a una aceleración conocida en la dirección del eje z y hacia abajo. Esta aceleración es debida a la fuerza de la gravedad. Ya que esta aceleración siempre está presente se puede llegar a realizar una primera aproximación al cálculo de los ángulos θ(pitch), ϕ(roll) y ψ(yaw) midiendo la proporción de la aceleración de la gravedad que se mide en los diferentes ejes del vehículo. La aceleración de la gravedad se descompondrá en los diferentes ejes del modelo proporcionalmente a los ángulos que estos ejes formen con el eje z. El segundo tipo de sensores útiles para el propósito de la IMU son los giróscopos o giroscopios, sensores que miden la velocidad angular en un instante dado para un eje del modelo. En otra aproximación se podrían acumular las diferentes velocidades angulares que el modelo ha sufrido durante un periodo de tiempo y calcular una aproximación del giro total que ha sufrido el vehículo desde su posición inicial Acelerómetros El acelerómetro es un sensor que es capaz de medir las aceleraciones sufridas en un eje particular, también existen sensores que miden aceleraciones en diferentes ejes. Hay diferentes tipos de acelerómetros. Los acelerómetros mecánicos cuentan con un pequeño peso y varios muelles que lo sujetan dentro de un espacio cerrado al vacío. Los muelles se encuentran dispuestos en línea con el eje que se desea medir y sujetan el peso entre medias, de modo que si el peso sufre alguna aceleración la inercia hará que el peso se desplace, estirando o encogiendo los muelles que lo sujetan. El sensor se limita a medir la deformación de los muelles y convertirlo en una señal eléctrica. Otro tipo de acelerómetros no son mecánicos, sino que se basan en traspaso térmico por convección natural, es decir, miden cambios internos por la transferencia de calor causada por la aceleración sobre moléculas de gas. Estos acelerómetros son más compactos y precisos que los mecánicos y se pueden encontrar fácilmente en el mercado a un precio competitivo. Como ya se ha mencionado en la introducción, cualquier cuerpo con masa está sometido, al menos, a una aceleración debida a la fuerza de la gravedad. Sin embargo, la aceleración de la gravedad no tiene por qué ser la única aceleración a la que esté sometido dicho cuerpo.

59 6.2. SENSORES 43 Figura 6.7: Diagrama de relación entre orientación y salidas del acelerómetro. El principio de equivalencia garantiza que la fuerza gravitacional experimentada localmente mientras se encuentra cerca de un cuerpo masivo, como la tierra, es la misma que la pseudo fuerza experimentada por un observador en un marco de referencia no inercial (acelerado). Esto quiere decir que la fuerza de la gravedad será equivalente en magnitud y dirección a aquella que soporta un objeto acelerado, por lo que no variará la aceleración sufrida por la gravedad aunque el vehículo en el que está instalado el sensor se encuentre acelerado. Cuando el vehículo se encuentre sometido a una aceleración diferente a la de la gravedad lo único que ocurrirá es que la aceleración total será la composición de dicha aceleración con la de la gravedad. Esto significa que la aceleración captada por los acelerómetros instalados en el vehículo tendrá una componente debida a la aceleración de la gravedad, y otra debida a la aceleración externa del vehículo. El mayor problema es que el sensor nos dará un único valor de aceleración y no es posible diferenciar a priori qué parte de la magnitud de aceleración es debida a la gravedad y qué parte no. Esto hace que la primera aproximación presentada para el cálculo de los ángulos sea errónea, ya que cualquier fuerza a la que sometamos el vehículo derivará en una aceleración que provocará un error de cálculo de los ángulos, pudiéndose dar el caso de que se llegue a anular la aceleración debida a la gravedad. De esta manera no es recomendable construir una IMU basada tan solo en las lecturas de los acelerómetros puesto que, aunque si el modelo no está acelerado se estimará adecuadamente la orientación, cualquier aceleración diferente de la gravedad que sufra el modelo provocará un cambio artificial en los ángulos θ, ϕ y ψ. Durante el primer incremento V1 se hicieron pruebas con la IMU 6DoF Razor desarrollada por Sparkfun 1. Esta unidad cuenta con un acelerómetro de tres ejes de Analog Devices, en concreto el modelo ADXL335, capaz de medir aceleraciones de hasta ±3g. Este sensor cuenta con salida analógica referenciada a 3.3 V. La IMU cuenta con filtros para la estabilización de las salidas y se alimenta a través de una entrada de 3.3 V. En la ilustración 6.8 se puede ver el esquema de conexiones del acelerómetro de tres ejes ADXL335 tal y como viene en la IMU 6DoF Razor. 1 Sparkfun es una conocida tienda online y fabricante de circuitos y dispositivos electrónicos sparkfun.com

60 44 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.8: IMU 6DoF Razor. Figura 6.9: ADXL345 con breakboard de Sparkfun. Sin embargo, aunque las primeras pruebas de medición resultaron satisfactorias, más adelante se comenzaron a detectar problemas con el sensor. El primero de ellos era debido a que, al tratarse de una placa con todos los sensores integrados, un defecto en alguno de los sensores suponía el reemplazo de la unidad completa, y las primeras pruebas en el banco balancín confirmaron la facilidad de fallo de estos sensores de bajo coste. Por otro lado, la limitación en el número de entradas analógicas en la placa Arduino y la necesidad de usar el conversor analógico digital del microprocesador para procesar las entradas, fueron clave para la sustitución de esta unidad por pequeños módulos de sensores independientes y la preferencia por módulos con salida digital (Incremento V2). El sensor elegido para sustituir al ADXL335 fue su hermano mayor ADXL345 (Fig. 6.9), también de Analog Devices, pero esta vez con mejor precisión (detecta cambios menores a 1 o ), mayores aceleraciones máximas (±9g), y una salida digital a través de interfaz I 2 C (Apéndice 12) muy amigable. En el Apéndice 12 se puede consultar más información sobre estos sensores. Antes de usar las medidas del acelerómetro hay que realizar el ajuste de la magnitud de la aceleración de la gravedad en la configuración seleccionada. Esta configuración consiste en seleccionar el rango de medida máximo a ±3g, ya que no será necesario medir mayores aceleraciones y además esta configuración es la que mayor precisión tiene (13 bits). Para esta configuración el valor de la aceleración de la gravedad medida en estático es de 260, por lo que hay que calibrar las medidas de modo que en estático el sensor proporcione una medida de 260 en eje Z y 0 en los ejes X e Y.

61 6.2. SENSORES 45 Figura 6.10: Esquema de funcionamiento de un giroscopio encapsulado MEMS (Micro Electro Mechanical Systems) Giróscopos Un giróscopo o giroscopio es un sensor que basado en el principio de conservación del momento angular es capaz de medir velocidades angulares en un determinado eje. Esto quiere decir que es capaz de medir la velocidad instantánea a la que está girando un cuerpo sobre un eje dado. Al proporcionar magnitudes de velocidad de giro es posible calcular el giro al que se ha sometido un cuerpo determinado durante un periodo de tiempo. Además, como el momento angular se mantiene inalterado independientemente de las aceleraciones lineales a la que se vea sometido el cuerpo, la magnitud de velocidad angular proporcionada por este sensor no varía aunque se encuentre en un marco de referencia no inercial. Esto es una gran ventaja ya que este tipo de sensores no se ven afectados ni por la aceleración debida a la gravedad ni por aquellas aceleraciones debidas a otras fuerzas, por lo que nos permite calcular la tasa de giro del vehículo independientemente de la orientación actual del vehículo y de su aceleración. Sin embargo, este tipo de sensores cuentan con dos problemas. El primero es que las magnitudes se corresponden con velocidades angulares instantáneas, y la frecuencia de las mediciones viene dada por las características técnicas del giróscopo así como de la velocidad con la que es capaz la IMU de consultar al sensor. Esto quiere decir que es necesario realizar una estimación de la velocidad angular entre medida y medida que, dependiendo de las características de precisión y frecuencia de medida, puede provocar pequeñas diferencias entre los giros calculados y los giros reales. Además, como para calcular el giro total se han de acumular las mediciones efectuadas desde el momento en el cual el modelo se encuentra en un ángulo de referencia, si el giro se prolonga en el tiempo al acumular las mediciones también se acumulan los errores. Por otro lado, el segundo de los problemas al usar estos sensores es que es necesario

62 46 CAPÍTULO 6. PLATAFORMA HARDWARE conocer el ángulo de referencia para poder aplicar el giro medido por el giróscopo a dicho ángulo para conocer la orientación del modelo. En el primer incremento V1 se utilizaron dos giróscopos integrados en la IMU 6DoF de Razor que se ha mencionado anteriormente. Esta IMU cuenta con dos giróscopos de ST Microelectronics, un LPR530AL que es capaz de medir en los ejes X e Y (pitch y roll) con un rango máximo de ±300 o /s y salidas analógicas amplificadas 4x, y un LY530ALH que es capaz de medir velocidad angular en torno al eje Z (yaw) con las mismas características de precisión y rango máximo. Al realizar pruebas en el banco de test con esta IMU se encontraron diferentes problemas al usar las magnitudes devueltas por los giróscopos. El primero de los problemas encontrados tiene que ver con una corrección abrupta encontrada en las salidas de los giróscopos cuando la velocidad angular pasaba a 0. Básicamente el problema consistía en una corrección de giro cuando el modelo paraba de girar, esta corrección era en el sentido de giro contrario al realizado y no era menospreciable. En un primer momento se achacó este comportamiento a la deriva inercial que sufren los giróscopos al parar bruscamente un giro, sin embargo, investigando en diferentes foros especializados [15] y consultando al fabricante se encontró que este efecto es debido a los diferentes filtros que el fabricante incorpora a la salida de los giróscopos, en este caso un filtro de paso alto y otro de paso bajo como se puede observar en el esquema del Apéndice 12. La cuestión reside en las características de los sensores y de la adquisición de la información de los mismos, en principio la adquisición de los sensores se realizará a una frecuencia dada, y el software se encargará de integrar los valores para reconstruir lo que ha ocurrido en función del tiempo, sin embargo, al tomar medidas cada cierto tiempo se pierde la información de lo que ha ocurrido entre medida y medida. Para poder limitar los efectos de este periodo de tiempo durante el cual no tenemos medidas y filtrar la salida para que quede en un rango adecuado lo que hace el fabricante es incorporar unos filtros que cuentan con condensadores. De este modo los valores que dan los sensores pasan por estos condensadores cargándolos, y cuando se realiza la lectura correspondiente no se lee directamente la salida de los sensores, sino la descarga de estos condensadores, que ofrece la señal filtrada. En otros casos, el uso de filtros es beneficioso para poder acotar la señal y suavizarla. Sin embargo, para los cálculos que realiza el software embarcado estos filtros provocan que la deriva de los giróscopos se amplifique debido a los diferentes tiempos de carga y descarga de los condensadores. En concreto es el filtro de paso alto el que introduce este indeseable efecto colateral del filtrado. Para solucionar este problema basta con eliminar físicamente los filtros de paso alto conectados a las salidas de los giróscopos. Para ello es necesario eliminar los condensadores, uno por cada salida, y realizar un puente en el lugar que ocupaban de modo que la señal pase libre. También hay que eliminar las resistencias asociadas a los filtros de paso alto y sustituirlas por una resistencia infinita (se deja desconectado), de modo que la señal no pierda nada. En la ilustración 6.11 se puede observar el resultado de eliminar los filtros en la IMU de Razor. Como se puede observar en la imagen, al eliminar uno de los condensadores se perdió también la pista correspondiente, por lo que fue imposible realizar el puente. Para solucionarlo se realizó el puente a la salida sin amplificar 1x y la entrada al amplificador de la señal. Sin embargo los problemas con la IMU de Razor no quedaron ahí, tras varias pruebas

63 6.2. SENSORES 47 Figura 6.11: IMU 6DoF RAZOR una vez eliminados los filtros de paso alto. En Verde se resaltan los condensadores cortocircuitados y en azul las resistencias eliminadas. Figura 6.12: Placa breakboard con LPY530AL. con el prototipo V1 uno de los giróscopos comenzó a tener un comportamiento anómalo. Las magnitudes de salida tenían grandes errores en velocidades bajas y la señal era inestable. Posiblemente debido al problema que surgió al eliminar los filtro el sensor se habría sobrecalentado y había quedado defectuoso, por lo que se procedió a cambiar toda la IMU por una nueva. La segunda IMU volvió a estropearse al intentar integrarla con el prototipo de la iteración V2. Aunque el fallo fue humano al desoldar la IMU de la placa de prototipado, el problema de sustitución de toda la IMU al fallar alguno de los sensores, unido al alto precio de la unidad de Razor, y unido al uso de salidas analógicas (y limitación de entradas analógicas en la plataforma Arduino), hizo que se eliminase del proyecto el uso de esta unidad y se sustituyera por módulos independientes. Por tanto en el incremento V3 se sustituyó definitivamente la IMU de Razor por dos giróscopos de dos ejes LPY530AL con breakboard de Sparkfun 6.12, de modo que uno se situase en el eje de pitch y otro en el de roll (ejes X e Y del modelo). Ambos cuentan con filtros de paso alto incorporados que hubo que eliminar como en el caso de la IMU de Razor Magnetómetros El tercer tipo de sensores que intervienen en la estabilización son los magnetómetros. En este caso el magnetómetro es un sensor magnético que es capaz de detectar el campo magnético de la tierra y, al igual que un compás tradicional, es capaz de definir dónde se

64 48 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.13: Magnetómetro HMC6352 de Honeywell con placa breakboard de Sparkfun. encuentra el norte magnético. Este tipo de sensores son útiles en navegación, pero también en estabilización, puesto que es necesario un sensor que nos de una referencia fiable para calcular el giro en el eje Z o Yaw. Realmente el compás digital o magnetómetro nos da una referencia del norte geográfico, útil para calcular el rumbo o heading. En el caso del yaw, cuando el modelo tenga cualquier inclinación en cualquiera de los ejes X e Y al contar con una componente no nula a partir del eje Z se pueden usar los acelerómetros como referencia para corregir y calcular el ángulo de referencia del giro. Por lo que tan solo se utilizará el compás digital cuando la componente debido a la aceleración de la gravedad caiga completamente en el eje Z, ya que al tener componentes nulas en los ejes X e Y sería imposible determinar el ángulo de origen de yaw. En realidad introduciremos el componente de heading como uno más en la estabilización, en cuanto a que se desea que el modelo no tenga ninguna velocidad angular en el eje Z y que esté dirigido hacia un rumbo particular. Para calcular dicho rumbo se toma como referencia la medida del compás digital para determinar el error en rumbo y corregirlo. El sensor elegido para medir el rumbo fue el HMC6352 de Honeywell en la versión de breakboard de Sparkfun debido a que dicha placa cuenta con señal filtrada estabilizada y salida digital a través de bus I 2 C. Después de hacer diversas pruebas con el compás digital se encontraron resultados no satisfactorios. En primer lugar con el compás en reposo las medidas que da el componente varían en un rango de dos, incluso tres, grados. Por lo que en la práctica la precisión del compás es muy deficiente. El segundo resultado no esperado ha sido que hay rangos de grados en los que el compás proporciona medidas extrañas. En concreto lo detectado es que al comenzar a girar sobre sí mismo hay un pequeño instante en el que las medidas se paran incluso se han obtenido medidas en sentido contrario durante un breve espacio de tiempo. Por lo tanto habrá que tener en cuenta la mala precisión del compás a la hora de preparar el módulo de navegación para orientar al modelo, de modo que se considere aceptable un error de grados Sónar y Barómetro Por último, para el tercer incremento V3 se incorporaron dos nuevos sensores: un barómetro con salidas digilates SCP1000 de MBed para ser usado de altímetro y un sonar LV- MaxSonar EZ1 de MaxBotics para gestionar la altitud con mayor precisión cuando el vehículo

65 6.3. UNIDAD CENTRAL 49 Figura 6.14: Barómetro SCP1000 de MBED. Figura 6.15: Sónar LV MaxSonar EZ-1 de MaxBotics. se encuentra a baja altitud. El Barómetro SCP1000 realmente obtiene medidas de presión que hay que filtrar y transformar a valores de altura por software. Tiene una resolución de 1 metro y un error también de 1 metro, por lo que no puede utilizarse como medida precisa para estabilización a baja altura, aunque es muy útil en campo abierto. Para poder realizar la conversión de presiones a altura hay que realizar un calibrado software a través del cual se establece la altura de referencia y se utiliza la temperatura actual para transformar las diferencias de presión en diferencias de altitud. El sónar seleccionado tiene salidas analógicas y en serie, aunque en este caso se utilizaron las salidas analógicas por motivos de latencia. Tiene una resolución de una pulgada (2.54 cm) y un error igual a la resolución. Cuenta con un alcance máximo de 6 metros, la altura mínima detectada es de 1 pulgada, aunque comienza a dar medidas exactas de distancia a partir de 5 pulgadas (unos 12 cm) Unidad Central La unidad central es el cerebro del vehículo, integra la placa Arduino con el microprocesador, reguladores de tensión, conversor serie FTDI 2 (USB a RS232) y resistencias unidas a las entradas/salidas analógicas, y todos los sensores utilizados por el microprocesador. En esta sección se explicarán los diferentes prototipos resultados de cada incremento, así como la evolución de las pistas, conexiones y demás detalles que conforman la placa principal. 2 Future Technology Devices International, empresa escocesa de circuitos integrados especializada en la tecnología USB

66 50 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.16: Montaje de UC para Iteración V1, se puede ver el Arduino Duemilanove con el adaptador para comunicaciones Xbee de Libelium (sin el módulo Xbee de Maxtream) y la IMU 6DoF de Razor. Figura 6.17: Módulo de comunicaciones Xbee (Zigbee) de MaxStream Incremento V1 En el primer incremento se utilizó un Arduino Duemilanove como base. Se utilizó una placa de prototipado corriente para integrar los sensores que se fueron probando con el Arduino. Aunque en las primeras pruebas se anclaba el conjunto al banco de test con cinta adhesiva o velcro, más tarde se adquirió una caja de Sparkfun donde montar los prototipos de modo que quedase un montaje compacto y seguro para las pruebas. Para el módulo de comunicaciones se eligió utilizar comunicaciones basadas en el estándar Zigbee 3. La decisión de usar Zigbee como enlace de datos inalámbrico residió en su bajo consumo respecto a Bluetooth 4, tasa de transferencia y alcance razonables (250 kbps / 1600 metros) y sobretodo su buena integración con la plataforma Arduino. Dentro del rango de opciones posibles se seleccionó usar un Shield (adaptador) para 3 Zigbee: Especificación de un conjunto de protocolos de comunicación inalámbrica basados en el estándar IEEE ( 4 Bluetooth: Especificación industrial para Redes Inalámbricas de Area Personal a través de radiofrecuencia en la banda ISM de los 2,4 GHz (

67 6.3. UNIDAD CENTRAL 51 Figura 6.18: Capas representado las conexiones deseadas sobre la placa de Measure Explorer Arduino 5 desarrollado por la empresa Libelium 6, una spin-off de la Universidad de Zaragoza. Este adaptador es capaz de integrar un módulo de comunicaciones Zigbee Xbee de MaxStream 7 facilitando el acceso desde Arduino a dicho módulo. Se puede consultar más información sobre el protocolo Zigbee en el Apéndice A sección Zigbee. Como se puede ver en la ilustración 6.16, las conexiones entre sensores y microprocesador se hacen a través de cable ordinario de prototipado. En el prototipo resultado del incremento V1 la unidad central tomaba alimentación (5V) a través del cable USB que conectaba la placa Arduino con el PC de desarrollo Incremento V2 En la segunda iteración se sustituyó la placa Arduino Duemilanova por una placa Seeeduino v2.12 basada en Arduino, que facilitaba la integración de la plataforma Arduino en una placa de prototipado. Una de las ventajas de Seeeduino es que cuenta con un regulador de tensión tanto de 5 V como un diodo Zener 3v3 que puede usarse como referencia para las entradas analógicas, eliminando la necesidad de usar un diodo externo así como un regulador de 5V externo (en primera instancia se iba a utilizar un L7805CV de ST Microelectronics). Como base para las conexiones se sustituyó la primera tipo protoboard por una placa de prototipado de una capa de Measure Explorer (ME) obtenidas a través de la tienda de ME en ebay. Se trata de placas de prototipado que cuentan con todos los agujeros conectados entre sí por finos hilos superficiales, de manera que para trazar las pistas tan solo se deben cortar las conexiones no útiles. Para facilitar el diseño de las pistas se utilizó una plantilla de GIMP 8 con diferentes capas Libelium: 7 MaxStream ahora absorvida por Digi 8 The GNU Image Manipulation Program

68 52 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.19: Capa de cortes que permiten las conexiones seleccionadas Figura 6.20: Resultado al trasladar los cortes y los headers a la placa de prototipado, en este caso se pueden ver los sensores también acoplados a sus cabeceras. para cada uno de los componentes a integrar, y dos capas especiales, una que representa la placa de prototipado con todos sus agujeros y otra que representa las conexiones de la placa Seeeduino. Sobre estas dos capas se superponen una capa que representa las conexiones deseadas, y otra que representa los cortes a realizar para tener las conexiones dadas, por lo que se puede realizar un buen diseño de los cortes de modo que se produzca el menor número de cortes posible. Se utilizaron dos placas de ME de 18 x 28 agujeros a las que se soldaron diferentes conectores (headers) para poder integrar fácilmente los sensores, de modo que se pudieran sustituir fácilmente. La alimentación en esta iteración proviene del conector de la batería LiPo principal. Seeeduino cuenta con un interruptor para seleccionar alimentación a través de USB para la programación o alimentación externa. El montaje final puede verse en la figura 6.21.

69 6.3. UNIDAD CENTRAL Incremento V3 Figura 6.21: Montaje final del prototipo de la Iteración V2 El tercer incremento se centró en mejorar la integración de los componentes con la plataforma Arduino y en la integración de los últimos sensores como el barómetro y el sónar para el módulo de estabilización en altura. Se incorporó una nueva placa de prototipado de Measure Explorer, esta vez mucho más grande (42 x 42 agujeros) en la que integrar todos los componentes. Al ser una placa nueva se realizó un diseño completamente nuevo de las pistas para facilitar la integración y alimentación de todos los componentes, y facilitar la expansión de la misma, permitiendo dejar visibles conexiones no utilizadas. Tras los problemas de alimentación encontrados en la segunda iteración, donde los cambios de potencia a los motores suponían interferencias en las lecturas de los sensores analógicos, se decidió alimentar la UC con una batería LiPo propia de 7.4 V y 500 mah. Además de esta manera la UC mantiene el control y las comunicaciones operativas aunque la tensión de la batería principal caiga, lo que permitiría, en caso de emergencia, mantener la telemetría operativa. Además se añadió un interruptor para permitir encender/apagar la alimentación de la UC. Por último se sustituyó la antena cerámica integrada del módulo XBee de MaxStream por una antena externa de mayor alcance, y se situó dicha antena fuera de la caja principal, de modo que las interferencias en los sensores debido a la radiofrecuencia se suavizaran.

70 54 CAPÍTULO 6. PLATAFORMA HARDWARE Figura 6.22: Diagrama de pistas para la placa final de la iteración V3 Figura 6.23: Montaje final de la UC Incremento V3

71 Capítulo 7 Software Embarcado En este capítulo se realizará una descripción informática de la parte de software que ejecutará embarcado en la Unidad de Control (UC). En primer lugar se especificará la arquitectura software para luego pasar a detallar los módulos de los que está compuesta, las evoluciones sufridas en cada uno de los incrementos, las dificultades encontradas, así como las soluciones propuestas Arquitectura Software La arquitectura del software embarcado está sujeta a la estructura general de un programa desplegable en la plataforma Arduino. Tal y como se ha explicado anteriormente todo software embarcable en Arduino debe contar con dos procedimientos a modo de punto de entrada o entry point que serán llamados automáticamente por el planificador del Framework Arduino. Un procedimiento setup() que se llamará una sola vez y un procedimiento loop() que será llamado cíclicamente. A partir de ahí el resto del código se puede modularizar y estructurar como se desee. El procedimiento setup() engloba las llamadas a los métodos de inicialización de cada uno de los módulos. En dichos métodos se inicializan los registros y variables de cada driver, también se ejecutan los posibles procedimientos de calibrado de los sensores analógicos, incluso los protocolos de inicialización en caso de ser necesario. Para poder controlar los ciclos de ejecución de cada módulo software y gestionar adecuadamente los recursos, se decidió implementar un planificador en el procedimiento loop(). Este planificador realiza las llamadas al resto de los módulos. Entre los módulos se encuentran los diferentes manejadores o drivers de entrada/salida. En el diagrama 7.1 se pueden observar los manejadores de entrada de los diferentes sensores, así como el manejador de salida hacia los motores. Cada uno de estos drivers se encarga de comunicarse con los sensores de diferentes maneras, así como de proveer una interfaz cómoda de acceso a los valores recibidos de los sensores o escritura de los valores de salida hacia los motores, de manera que el resto de módulos pueda hablar con todos los dispositivos de entrada/salida sin preocuparse del protocolo o tecnología usada por el manejador o driver. 55

72 56 CAPÍTULO 7. SOFTWARE EMBARCADO Figura 7.1: Diagrama de arquitectura Software.

73 7.2. DRIVERS DE ENTRADASALIDA 57 Además de los drivers de entrada/salida el software embarcado se compone de tres módulos importantes de procesamiento: Modulo de Comunicaciones: Encargado de procesar los comandos recibidos de la estación de tierra y enviar la información de telemetría del vehículo. Modulo IMU: Fusiona los datos de sensores para calcular la posición relativa del vehículo. Módulo de Estabilización: Encargado de la seleccionar la salida adecuada hacia los motores dependiendo de la situación del vehículo y los comandos recibidos. Cada uno de estos módulos cuenta con un procedimiento de inicialización, que es llamado desde el punto de entrada setup() y que se ejecutará una sola vez. Y dependiendo de si se trata de un módulo de entrada/salida o de procesamiento contará con un método de acceso a los datos o escritura de los mismos (del tipo get()/set()) o con un método procesamiento (process()) Drivers de EntradaSalida Interfaz I2C La interfaz I 2 C 1 fue definida por Philips para conectar de forma simple componentes electrónicos. Consta de dos líneas, una de datos y la otra de sincronización de reloj. También es necesaria una línea de tierra que suele ser la misma utilizada para alimentar el circuito. La nomenclatura de las líneas es: SDA (Datos), SCL (Reloj), GND (Tierra). A través de I 2 C podemos enviar datos con una tasa de transferencia de hasta 100kbps. Los dispositivos conectados por I 2 C cuentan con una dirección única de 7 bits, además pueden ser configurados en modo maestro o esclavo. El maestro es el que inicia la transmisión mientras que el esclavo solo responde a lo que el maestro pida. En toda comunicación I 2 C el maestro es el encargado de generar la señal de reloj. Después de cada transferencia de 8 bits el maestro genera un pulso en la señal de reloj y deja libre la línea, entonces el esclavo responde con un ack poniendo la línea SDA a nivel bajo o con un nack dejando la línea a nivel alto. Todas las transiciones en la linea SDA deben ocurrir cuando SCL está a nivel bajo ya que las transiciones cuando SCL está a nivel alto se reservan para los comandos de Start y Stop. Al iniciar las comunicaciones el maestro debe enviar el comando de Start seguido por la dirección de destino. Como la dirección está formada por 7 bits y las transferencias I 2 C son de 8 bits, se usan los 7 bits más significativos. Esto hay que tenerlo en cuenta ya que antes de enviarla habrá que mover un bit hacia la izquierda la dirección de modo que quede en los 7 bits más significativos. El bit menos significativo se usa para indicar si se trata de una lectura (1) o una escritura (0). 1 I 2 C: Inter-Integrated Circuit, también llamado Twice Wires Interface TWI

74 58 CAPÍTULO 7. SOFTWARE EMBARCADO Afortunadamente existe una librería implementada para Arduino llamada Wire que implementa todo el protocolo. Para poder usar la librería Wire de Arduino es necesario conectar la línea SCL a la entrada analógica 5 y la linea SDA a la entrada analógica Módulo ADXL345Driver En general se ha desarrollado un driver independiente para cada sensor o grupo de sensores. El primero de ellos es el ADXL345Driver encargado de realizar las lecturas del acelerómetro de 3 ejes. La interfaz del sensor es a través de bus I 2 C. Para adquirir los datos del sensor se ha utilizado la librería Wire de Arduino. La dirección de 7 bits I 2 C asignada según especificación del sensor es 0x1D, aunque se pueden usar dos direcciones a elegir dependiendo de si la entrada SD0 se encuentra a nivel alto o a tierra, si es a nivel alto se usa 0x1D y si es tierra usará la dirección 0x53. Hay que tener en cuenta que ambas direcciones se configuran en los 7 bits más significativos dejando el menos significativo para indicar lectura o escritura. Una vez inicializado el bus I 2 C y configurada la dirección y parámetros del bus, el módulo provee tres funciones get() que devuelven la aceleración medida en un entero, donde la aceleración de la gravedad se sitúa en el valor 260 (medida resultante al medir la aceleración sobre el eje Z sin ninguna otra aceleración externa) Módulo ImuAdc El módulo ImuAdc provee una interfaz de acceso a los datos de los dos giróscopos de dos ejes (uno de los ejes es común a ambos giróscopos). En este caso las salidas amplificadas de los sensores se conectan a entradas analógicas, por lo que se utilizan los conversores AD de micro que tienen una precisión de 10 bits (1024 valores). En lugar de proveer funciones de acceso a cada una de las lecturas, este módulo guarda los valores leídos de velocidades angulares en un vector donde son corregidos. La razón de esto es la necesidad de calibrar los giróscopos, para ello se toman medidas con los sensores estáticos para conocer el ruido de los mismos y se utilizan estos valores para corregir y mejorar las medidas. Este módulo está directamente vinculado al módulo ImuDcm encargado de corregir las lecturas y fusionarlas con las lecturas de los acelerómetros para obtener los valores netos de pitch, roll y yaw Módulo DigitalCompass Este módulo provee una interfaz de acceso a los valores de heading obtenidos a través del magnetómetro digital. Se conecta a través de bus I 2 C que, según especificación, está configurado en modo esclavo con la dirección 0x48. Para obtener lecturas de heading es necesario primero inicializar las comunicaciones I 2 C (initdigitalcompas()). Para acceder al último valor obtenido se puede llamar a la función getheading() que devuelve un entero que representa grados 10, de modo que tiene 0.1 grados de precisión. Para actualizar la última lectura de heading es necesario llamar al procedimiento processdigitalcompass(). Este procedimiento envía el comando A al sensor, espera 6 ms y recibe dos bytes que se corresponde con el rumbo dado en décimas de grados

75 7.3. COMUNICACIONES 59 desde 0 a Se puede consultar más información sobre los procedimientos de calibración del magnetómetro en el Apéndice A sección de sensores. Tras realizar diferentes pruebas con el módulo se encontraron resultados no demasiado satisfactorios. En primer lugar, las medidas obtenidas con el compás en reposo varían en un rango de ±2 grados, por lo que en la práctica la precisión del compás es muy mala. Además al tratarse de un magnetómetro de un solo eje las medidas de rumbo son fiables tan solo cuando el sensor está completamente horizontal, por lo que hay que tener en cuenta la posición del vehículo para considerar válidas las medidas, o bien realizar solo actualizaciones de heading cuando el modelo se encuentre con pitch y roll nulos Módulo AltimeterDriver El módulo AltimeterDriver provee dos funciones para obtener la altitud y la temperatura. Para poder obtener la altitud se utilizan dos sensores diferentes, por un lado un sensor de presión SCP1000 con interfaz I 2 C, y por otro un sónar MaxSonar con interfaz analógica. En un principio el módulo estaba compuesto por el sensor de presión, sin embargo, dicho sensor tiene un error de ±1 metro, inaceptable para vuelo en interiores e insuficiente para los procedimientos de despegue y aterrizaje. Por lo que se optó por complementarlo con un sónar con precisión suficiente a corta distancia. El procedimiento processaltitude() realiza la fusión de estos dos sensores. Por un lado lee los valores analógicos del sónar utilizando un filtro simple de moda para eliminar posibles lecturas sucias, convierte a pulgadas aplicando el factor de conversión que especifica el fabricante para luego convertir los valores recibidos de pulgadas a metros. Si el resultado es mayor a 5 metros (el sónar tiene un alcance máximo de 6.5 metros) entonces descarta la medida del sónar y solicita a través de I 2 C el valor de presión al sensor de presión. Se aplica una conversión logarítmica a los valores de presión recibidos para convertirlos a metros, para eso se busca el valor de la presión a una determinada temperatura en la zona de vuelo estimada (en este caso sur de Madrid) y se aplica dicha presión de referencia en la función de conversión. Debido a que la presión varía con la temperatura ambiente las medidas del sensor de presión deben tomarse teniendo en cuenta una posible calibración de la medida de la presión leída cuando el vehículo se encuentra en tierra. Dado que el sensor de presión cuenta con un termómetro, aprovechando el acceso al sensor para conocer la presión se obtiene la temperatura, que es almacenada y puede ser consultada a través de la interfaz de la GCS Comunicaciones El módulo SerialComms provee toda la interfaz referida a comunicaciones, tanto de salida de telemetría como de entrada de comandos y órdenes. Tal y como se ha explicado en la sección de Plataforma Hardware 6 las comunicaciones se procesan a través de un módulo Xbee que implementa el protocolo Zigbee. Además del módulo Xbee instalado en el vehículo, habrá otro módulo Xbee conectado a la GCS al que llamaremos Router. Este segundo módulo redigirá el tráfico a un puerto USB

76 60 CAPÍTULO 7. SOFTWARE EMBARCADO de la GCS, dotando de esta manera de comunicaciones Zigbee a la GCS. El módulo Xbee del vehículo se conecta directamente con el puerto serie de Arduino. Además, el módulo de radio se configura dándole una dirección determinada fija (de modo que el Router sepa la dirección del módulo de radio del vehículo). Se configura el protocolo en modo Ad-Hoc (Router-Vehículo), por lo que todo lo que se envía a través del puerto serie de Arduino es redirigido a través de Zigbee a la dirección Zigbee especificada como Router. Se implementaron dos programas Arduino de configuración que automáticamente configuran los módulos de radio tanto del vehículo como del router siguiendo el protocolo de configuración de las radios a través de puerto serie. Una vez configurado el enlace a través de Zigbee se desarrolló un protocolo de comunicaciones basado en ASCII 2 para poder enviar y recibir los diferentes mensajes. Este protocolo establece cabeceras simples que delimitan y clasifican los tipos de mensajes. Se decidió codificar en ASCII para facilitar la lectura de código y la depuración, teniendo en cuenta que el problema del ancho de banda no era significativo. Se establecen dos tipos de mensajes, por un lado comandos que recibe el vehículo desde la estación de tierra, y por otro lado mensajes de telemetría que envía el vehículo con información de diferente tipo. De esta manera un mensaje se compone de una cabecera de comienzo y final de mensaje, y entre medias un identificador de mensaje sucedido de los datos del mensaje. Para el envío y recepción se implementa un buffer de recepción, de manera que en cada ciclo de ejecución se vacía el búfer de recepción de la pila Zigbee y, dependiendo de una máquina de estados que indica si se espera una cabecera de comienzo o fin de mensaje o datos, se decide si los bytes leídos son válidos, si es así se almacenan en el búfer local de recepción. Cada vez que la máquina de estados de recepción considera que se ha recibido un mensaje válido (por ejemplo al recibir una cabecera de fin de mensaje que se esperaba), vacía el búfer sacando el mensaje válido y lo envía a un clasificador de mensajes que lo decodifica y llama al procesador de mensaje adecuado. El procesador correspondiente al mensaje recibido envía asentimiento en caso de requerirlo, y en caso de tratarse de un comando implementado llama a la función correspondiente. En la tabla 7.1 se puede ver la relación de mensajes implementados, tanto de telemetría como de comandos. Adicionalmente se implementó un mensaje especial de depuración y otro de alarmas para poder enviar mensajes específicos desde el software embarcado a la estación de tierra. De esta manera, además de la información de telemetría presentada en la estación de tierra gráficamente, también se provee información adicional que se presenta a través de una ventana de texto, muy útil para conocer qué ocurre en el software embarcado (trazas de código, información de depuración, tiempos de ejecución, etc). Entre los comandos más importantes se encuentran los comandos de inicio de comunicaciones y los correspondientes asentimientos (Ok, Fail y Reconnect) que permiten establecer (y reestablecer en su caso) el enlace entre vehículo y estación de tierra. Hasta que dicho enlace no está establecido el software embarcado no ejecutará determinadas rutinas, como las de estabilización, proceso de comandos, y cálculo de la posición relativa. Adicionalmente hay comandos específicos que ordenan al software comenzar a procesar 2 ASCII: American Standard Code for Information Interchange

77 7.4. MÓDULO IMU 61 Tipo Descripcion Id Datos Cmd Comms Init I - Cmd Reconnect - Cmd Motor Power M [MotId][Value] Cmd Kp Param Set K [PidId][Value] Cmd Td Param Set TD [PidId][Value] Cmd Ti Param Set TI [PidId][Value] Cmd Pitch Dmd P [Value] Cmd Roll Dmd R [Value] Cmd Heading Dmd H [Value] Cmd Start B - Cmd Stop S - Cmd Ok OK - Cmd Fail FAIL - Info Pitch Info P [Value] Info Roll Info R [Value] Info Yaw Info Y [Value] Info Heading Info H [Value] Info Altitude Info B [Value] Info X Acceleration AX [Value] Info Y Acceleration AY [Value] Info Z Acceleration AZ [Value] Info X Angular Vel GX [Value] Info Y Angular Vel GY [Value] Info Z Angular Vel GZ [Value] Info Power Motor PM [MotId][Value] Info Debug D [String] Cuadro 7.1: Mensajes implementados en el protocolo de comunicaciones los ángulos de pith, roll y heading solicitados desde la estación de tierra (Start), así como un comando de parada total de emergencia (Stop). Los comandos Pitch Dmd, Roll Dmd y Heading Dmd son los encargados de establecer los ángulos de pitch y roll, así como el rumbo que debe tomar el vehículo y que serán las entradas que utilizará el módulo de estabilización para realizar sus cálculos Módulo IMU Uno de los módulos más importantes es el encargado de fusionar los datos obtenidos de los sensores que forman la unidad inercial del vehículo (IMU), formado por acelerómetros y giróscopos, para obtener la posición del vehículo en ángulos de pitch, roll y yaw. Existen dos enfoques principales para la fusión de datos y obtención de ángulos de Euler a partir de aceleraciones absolutas y velocidades angulares. Uno de ellos es utilizar las aceleraciones como datos principales y usar un filtro Kalman en el que se utilizan los valores de velocidad angular como dato corrector [2]. El segundo es utilizar las velocidades angulares como dato principal y utilizar matrices de cosenos directores para, por un lado corregir los vectores unitarios que forman la base de coordenadas del vehículo con la información de

78 62 CAPÍTULO 7. SOFTWARE EMBARCADO aceleraciones, y por otra renormalizar estos vectores para mantener la ortogonalidad de los mismos. El algoritmo DCM (Direction Cosine Matrix) [43] desarrolla el segundo enfoque, y al tratarse de un método nuevo y más efectivo que el tradicional uso de filtros Kalman se decidió utilizarlo Algoritmo DCM El algoritmo DCM funciona de la siguiente manera: 1. Las medidas de los giróscopos se usan como la fuente principal de información de orientación. Se procede a integrar la ecuación diferencial no lineal que relaciona el tiempo durante el cual el modelo ha estado cambiando de orientación con la velocidad angular y con la orientación actual del modelo. Esto se hace a una frecuencia suficientemente alta como para dar información lo suficientemente fresca al controlador de modo que pueda corregir la potencia a enviar a cada uno de los motores. Básicamente se obtienen datos de velocidad de giro, y se integran en tiempo para obtener posición. 2. El resultado de la primera fase tiene la forma de una matriz de rotación 3x3 que representa el giro en los tres ejes. Los errores en la integración provocarán que se viole el principio de ortogonalidad que la matriz DCM debe satisfacer, por lo que se van haciendo pequeñas correcciones para mantener la ortogonalidad de la matriz. 3. Los errores numéricos debidos a las medidas de los giróscopos se van acumulando en los elementos de la matriz DCM. Para poder corregir estos errores o paliarlos en gran medida se usarán las medidas de los acelerómetros para poder corregir pitch y roll y las medidas del compás digital para corregir el yaw Rotaciones Una manera de representar una rotación en tres ejes es a través de una matriz de rotación. Dicha matriz es una matriz 3x3 compuesta de nueve elementos, tres filas y tres columnas, que representa la orientación de cada sistema de coordenadas respecto a otro. Las columnas de la matriz son los vectores unitarios de un sistema de coordenadas visto desde el otro. Un vector en un sistema de coordenadas puede ser transformado hacia el otro sistema multiplicándolo por la matriz de rotación correspondiente. La transformación en el sentido contrario se obtiene multiplicando el vector por la matriz inversa a la de rotación que resulta ser igual a la traspuesta (resultado de intercambiar filas por columnas). Los vectores unitarios son muy útiles a la hora de realizar los cálculos ya que al tener valor uno pueden ser usados en los productos escalares y cruzados para obtener los senos y cosenos de varios ángulos. Un grupo de rotación es el grupo de posibles rotaciones. Se llama grupo porque dos posibles rotaciones pueden combinarse para formar una nueva rotación del grupo. Toda rotación cuenta con su rotación inversa, y también existe la rotación identidad que al ser aplicada no cambia la orientación. Lo interesante es que el grupo de rotación es cerrado, es decir, se pueden aplicar sucesivas rotaciones hasta dejar al modelo con la orientación inicial.

79 7.4. MÓDULO IMU 63 La idea base es que la matriz de rotación que define la orientación del modelo (respecto a una orientación inicial dada) puede ser actualizada integrando la ecuación diferencial no lineal que describe la cinemática de la rotación. Esta cinemática tiene que ver con la geometría de la rotación de un cuerpo rígido y cómo la rotación transforma una configuración rígida en otra. Esto se hace teniendo en cuenta que la integración se puede conseguir a través de una serie de composiciones de matrices, con composición se entiende la multiplicación de dos matrices de rotación, y la resultante representa la matriz de rotación resultante de haber aplicado secuencialmente las rotaciones que representan las matrices de rotación multiplicadas. Sin embargo, esta integración introduce dos tipos de errores, por un lado el error numérico debido a que la integración utiliza periodos de tiempo acotados y la información se obtiene con una determinada frecuencia (correspondiente a la frecuencia de actualización de los sensores). Dependiendo del método de integración se asumen ciertos supuestos sobre lo que ha pasado entre cada muestra de datos, en este caso se puede asumir que la velocidad de rotación es constante entre cada lectura de los giróscopos. Por tanto el error es proporcional a la aceleración angular. El segundo tipo de error es el cuantitativo y tiene que ver con la propiedad discreta de las lecturas digitales, en definitiva cada lectura de los giróscopos es una lectura digital (los sensores analógicos pasan por un conversor A/D), en nuestro caso con una resolución de 10 bits (precisión del A/D de Arduino). Una propiedad clave de la matriz de rotación es su ortogonalidad, que implica que si dos vectores son perpendiculares en un marco de referencia deben ser perpendiculares en cualquier otro marco de referencia, y también que la longitud de cada vector es la misma independientemente del marco de referencia. Los errores numéricos anteriores pueden hacer que se viole esta propiedad de las matrices. Las filas y columnas de la matriz representan vectores unitarios cuya longitud debe ser siempre uno, pero los errores acumulados pueden hacer que varíe la longitud ligeramente por debajo o por encima de uno. Aunque la matriz de rotación cuenta con nueve elementos, realmente tan solo tres de ellos son independientes. La ortogonalidad de la matriz indica que cualquier par de columnas o filas debe ser perpendicular y que la suma de los cuadrados de los elementos de cada fila o columna debe resultar uno. Esta propiedad puede ser usada para renormalizar la matriz Matriz de Cosenos Directores Tal y como se ha definido anteriormente, algunos vectores como desplazamiento, dirección, velocidad o aceleración, pueden ser transformados de un marco de referencia a otro con solo multiplicarlo por una matriz de rotación 3x3. Esta matriz de rotación es resultado de calcular las proyecciones de un marco de referencia sobre el otro como se puede ver en la figura 7.2. La relación entre la matriz de cosenos directrices y ángulos de Euler se muestra en la ecuación 7.1 cos θ cos ψ sin φ sin θ cos ψ cos φ sin ψ cos φ sin θ cos ψ + sin φ sin ψ R = cos θ sin ψ sin φ sin θ sin ψ + cos φ cos ψ cos φ sin θ sin ψ sin φ cos ψ (7.1) sin θ sin φ cos θ cos φ cos θ Al ser la frecuencia de actualización muy rápida se asume que los giros producidos son

80 64 CAPÍTULO 7. SOFTWARE EMBARCADO Figura 7.2: Proyecciones de una base sobre otra de referencia. tan pequeños que se puede simplificar los cosenos por 1, los senos por el valor del arco medido en radianes (θ) y los productos seno x seno por 0. Suponiendo velocidad angular (Θ) constante durante el periodo de cálculo el arco queda Θ = ω dt Teniendo la matriz de rotación para un instante dt, la matriz para un instante (t + dt) es igual a la del instante t multiplicada por la rotación, como se observa en la ecuación 7.2: 1 dθ z dθ y R(t + dt) = R(t) dθ z 1 dθ x (7.2) dθ y dθ x 1 Donde: Θ z = ω z dtθ y = ω y dtθ x = ω x dt (7.3) Una vez obtenido el resultado de la rotación es necesario realizar una renormalización para corregir posibles violaciones del principio de ortogonalidad, para ello se usa el producto escalar de cada pareja de vectores perpendiculares. Así conseguimos el error de ortogonalidad y es posible aplicar una corrección a cada vector igual a la mitad del producto del error calculado por el vector perpendicular utilizado. Por último se convierten a vectores unitarios normalizando. En este punto es donde entran en acción los valores de aceleraciones obtenidos de los acelerómetros. Dichos valores se utilizan para cancelar el efecto de deriva de los giróscopos. Para ello se utiliza un controlador retroalimentado proporcional derivativo (PI) que genera la corrección a aplicar a los giros, se detallará en qué consiste un controlador de bucle cerrado de este tipo en la sección Se introduce como entrada del controlador PI el error entre los ángulos calculados en función de los valores de los acelerómetros y los obtenidos por el DCM en la ejecución anterior. Se toma una pequeña fracción del error como corrección de la parte proporcional, y la acumulación de dicha corrección como corrección de la parte integral.

81 7.4. MÓDULO IMU 65 Figura 7.3: Diagrama del controlador PI DCM Ángulos de Euler Para obtener el ángulo Pitch solo hay que referirse a la relación entre la matriz de rotación y los ángulos de Euler ya vista anteriormente, de la misma manera se puede obtener el ángulo Roll y Yaw acudiendo a la matriz de rotación y despejando: P itch = T odeg(asin(dcm Matrix[2][0])) (7.4) Roll = T odeg(atan2(dcm Matrix[2][1], DCM M atrix[2][2])) (7.5) Y aw = T odeg(atan2(dcm Matrix[1][0], DCM M atrix[0][0])) (7.6) Notas sobre la implementación Para implementar y probar adecuadamente el algoritmo DCM se partió de los documentos de Mahony [33] y del draft de documentación de William Premerlani, DCM Imu Theory [43]. Además se ha contado con una implementación basada en el código abierto del proyecto DIYDrones encontrada en el proyecto VoidBot [8], en el que casualmente adapta el código DCM para ser utilizado con la IMU 6DoF de Razor que se utilizó en los primeros incrementos (V0 y V1) de la plataforma hardware. Además se ha consultado también el propio código del proyecto DIYDrones [15], así como los foros de discusión sobre DCM [15], por lo que el código final de la implementación DCM está basado en la implementación de DIYDrones, aunque modificado, adaptado y optimizado para ser utilizado con los sensores seleccionados y el planificador implementado en el software embarcado. Todas las funciones de cálculo algebráico se han implementado de cero, así como la adquisición y conversión de datos de los sensores. El código correspondiente a la renormalización y al controlador PI aplicado para las correcciones es una adaptación del código original de DIYDrones a la plataforma propia. La transformación de coordenadas se ha optimizado e implementado de manera diferente a la original.

82 66 CAPÍTULO 7. SOFTWARE EMBARCADO Hay que tener en cuenta que el código original de DIYDrones está orientado a ser utilizado por un avión radiocontrolado, por lo que tanto la adquisición como la corrección de datos adquiridos difiere respecto a un vehículo de despegue vertical (VTOL). Por lo que fue necesario estudiar los cambios y rectificaciones a aplicar al algoritmo original Módulo de Estabilización El módulo de estabilización es el encargado de procesar el estado actual del vehículo y calcular la potencia a suministrar a cada uno de los motores para llevar al vehículo al estado deseado. En este caso las entradas del controlador de estabilización las forman los tres ángulos calculados por el módulo IMU, mientras que las salidas son las potencias que puede comandar a cada uno de los motores. Para solucionar la estabilización del vehículo, se ha decidido abordar el cálculo de las salidas debidas a cada eje como un problema independiente. De esta manera la estabilización del vehículo se convierte en tres problemas de estabilización, uno para cada uno de los ejes. Para cada eje se tiene una única entrada, que es el ángulo correspondiente calculado por el módulo IMU, y cuatro salidas correspondientes a las potencias de los motores. En realidad, tal y como se ha descrito en el capítulo 5.1, las potencias a suministrar a los cuatro motores para provocar un cambio en un eje, se pueden simplificar a un único valor que representa un diferencial de potencia entre dos parejas de motores. De esta manera, dado un ángulo que se corresponde con el ángulo real (calculado por módulo IMU) en un eje concreto, y por otro lado el ángulo objetivo, se puede calcular el error absoluto entre ambos (que se corresponde con la diferencia entre ambos). Dicho error es la entrada al controlador, mientras que la salida representará el giro necesario para paliar dicho error (siempre se habla de un eje fijo concreto) en forma de diferencia de potencia entre dos pares de motores. Para solucionar este problema se usará un controlador Proporcional, Integral, Derivativo PID [36] para el ángulo pitch y otro para el roll. También se usará un controlador PID para el ángulo Yaw, aunque éste impactará en el control del rumbo y no de la estabilización en sí PID Un controlador de bucle cerrado es aquel que cuenta con feedback o retroalimentación de su salida además de las entradas habituales, esto es para poder conocer cómo de bien se ajusta la salida proporcionada por el propio controlador y poder corregirla adecuadamente. Digamos que existe la posibilidad de actuar sobre una variable de salida a la que llamaremos salida del controlador (CO, CV o simplemente OUTPUT). Además se cuenta con una entrada que es la variable a procesar (PV de Process Variable) y con un tercer valor que nos indica si se ha alcanzado el objetivo, que suele tratarse de un valor deseado para la variable de entrada y a la que se denomina Set Point (SP). En principio, las variaciones en la variable de salida o CO afectan en el siguiente ciclo al valor de entrada PV, por esa razón existe un bucle cerrado.

83 7.5. MÓDULO DE ESTABILIZACIÓN 67 Figura 7.4: Esquema de controlador PID Acción Proporcional El controlador PID cuenta con tres factores, si tan solo se tuviese en cuenta la variable de entrada PV y se usase una función de proporcionalidad entre ésta y el valor objetivo SP (error entre el valor actual y el objetivo) sería un controlador proporcional simple. Se define una constante de proporcionalidad en la acción proporcional, una constante que define la relación entre la salida CO y el efecto de esta en la entrada PV de modo que la entrada se acerque al objetivo SP. Esta constante se denomina Kp. La acción proporcional es rápida de calcular y fácil de sintonizar (tune) pero no elimina el error en estado estacionario. Kp recibe el nombre de ganancia proporcional Acción Integral Para minimizar las perturbaciones debidas a factores externos se aplica un factor integral encargado de conocer la historia de la relación entre la acción aplicada y la entrada retroalimentada. En un símil electrónico es el mismo efecto que tiene la colocación de un condensador como filtro en un circuito de modo que en lugar de tomar las lecturas de una señal eléctrica se toman las medidas del condensador, para estabilizar la señal y evitar que nos impacten las variaciones anómalas. Además ayuda a mantener la variable controlada en el valor objetivo. Este factor integral necesita una variable que indique el tiempo durante el cual se va a tomar. A mayor tiempo la acción integral será menor y a menor tiempo la acción integral será mayor (tendrá más peso). Esto es normal porque si se reduce el tiempo es más probable que las perturbaciones afecten a la salida pero también hace que en caso de error muy grande el controlador sea más agresivo al sumarse la acción integral a la proporcional. La constante de tiempo integral se denomina Ti Acción Derivativa Por último hay un tercer factor que es el derivativo, este factor prevee hacia dónde va a ir la variable controlada en el siguiente ciclo dada la salida actual debida al controlador Proporcional/Integral. Se define una constante de tiempo Td que se usa para calcular el efecto de la acción proporcional, durante ese tiempo Td la salida va a variar proporcionalmente a la acción proporcional, estima a qué velocidad se está reduciendo el error para abstraer, conociendo el tiempo de aplicación, cual será la posición en el siguiente ciclo de ejecución respecto al error.

84 68 CAPÍTULO 7. SOFTWARE EMBARCADO Figura 7.5: Comportamiento PID respecto a parametros Kp,Ti,Td Parametrización PID Antes de utilizar un controlador PID hay que calibrarlo, es decir, definir los valores de Kp, Ti y Td. Existen diferentes métodos para configurar estos parámetros, algunos consisten en ir dejando a nulo cada valor e ir midiendo la respuesta del controlador a diferentes valores de uno solo de los coeficientes hasta lograr el mejor efecto, fijar dicho valor y luego realizar otras pruebas con los otros factores (Método Ziegler-Nichols [14]). Sin embargo, debido a la baja calidad de los sensores (al ser de bajo coste) y de la necesidad de una calibración lo más exacta posible debido a la criticidad de un fallo por pequeño que sea en la salida de los controladores, es necesario realizar una calibración lo más precisa posible. Teniendo esto en cuenta se decidió implementar un método de autocalibración que aprovechase el banco de pruebas existente. Si se simplifican los parámetros de un controlador PID a Kp, Ti y Td se puede construir un espacio tridimensional con las posibles parametrizaciones del PID. Si se construye una función que valore cómo de buena es una parametrización (Kp,Ti,Td) respecto a una serie de variables objetivas, como por ejemplo el error medio obtenido mientras se ejecuta el PID durante un tiempo fijo dado, el error máximo, o cualquier otro parámetro medible durante un experimento, entonces se reduce la calibración del PID a un problema de búsqueda en un espacio tridimensional. Se ha desarrollado un algoritmo específico para resolver este problema, que será presentado en el capítulo Aplicación de PID a la estabilización Una vez que se obtiene la salida del controlador, se debe convertir dicha salida a potencias a aplicar a los motores. La salida del controlador se puede traducir en una proporción de giro en un sentido u otro. Tal y como se describió en el capítulo de análisis, un giro en un solo eje se puede transformar en la aplicación de una potencia determinada a cada pareja de motores.

85 7.6. EVOLUCIÓN DE LOS INCREMENTOS 69 Si nombramos X (1,2) e Y (3,4) a cada pareja de motores, se logra un giro en un sentido aplicando un factor de corrección a una de las parejas y aplicando la corrección inversa al otro par de motores. El sentido del giro lo determinará el signo de dicho factor de corrección, mientras que la determinación del giro se basa en la elección de las parejas de motores según los diagramas mostrados en el capítulo de Análisis 5. Para simplificar la elección de los factores se decidió configurar la salida de los PID s de modo que la salida de cada controlador sea directamente el factor de corrección a aplicar. Este factor de corrección es el mismo para los ejes de pitch y roll y tiene un rango que va de P M MAX P ID LIMIT a P M MAX P ID LIMIT siendo P M MAX la máxima potencia posible para los motores y P ID LIM IT una constante de proporcionalidad que va de 0 a 1 e indica el porcentaje de potencia de motor dedicado a la estabilización de un eje dado. La aplicación del factor de corrección debido a un controlador se realiza sobre la potencia actual de los motores, es decir, los motores tienen una potencia dada currentthrottle y a esa potencia se aplica una fracción de 1 del factor de corrección. 4 Por ejemplo, si la pareja de motores 3 y 4 inciden en el giro de pitch mientras que la pareja 1 y 2 lo hacen sobre el roll, y la pareja 1 y 3 lo hacen sobre el giro sobre sí mismo (yaw se convierte en rumbo o heading si el vehículo se encuentra horizontal), la aplicación de las salidas de tres controladores PID uno para cada eje sería: motor3pow = currentthrott+(pitchout/4) - (RollOut/4) + (HeadOut/4); motor4pow = currentthrott+(pitchout/4) + (RollOut/4) - (HeadOut/4); motor1pow = currentthrott-(pitchout/4) + (RollOut/4) + (HeadOut/4); motor2pow = currentthrott-(pitchout/4) - (RollOut/4) - (HeadOut/4); Si el giro de corrección es en un sentido equivocado tan solo hay que cambiar los signos, mientras que si el giro es demasiado brusco siempre se puede variar el límite PID LIMIT Evolución de los Incrementos El desarrollo del software embarcado ha seguido la metodología descrita basada en incrementos. El incremento inicial V0 sirvió para familiarizarse con la plataforma Arduino y las diferentes librerías disponibles. En el primer incremento real V1 se desarrolló el protocolo de comunicaciones y se probó su correcto funcionamiento. También se realizó el primer draft del planificador, así como diferentes versiones de los módulos de drivers de los sensores, primero para comunicarse con la IMU 6DoF de Razor, y luego adaptándo el código para comunicarse con las placas de giróscopos y acelerómetros independientes. También se realizaron pruebas de salida de potencia de motores. En el segundo incremento V2 se introdujo todo el desarrollo del algoritmo DCM, también los drivers de los magnetómetros y del barómetro. Por último, se añadieron nuevos mensajes para poder solicitar los comandos de inicio y parada de emergencia. En el módulo de estabilización se implementó el controlador PID de pitch y roll para poder realizar las primeras pruebas de calibración.

86 70 CAPÍTULO 7. SOFTWARE EMBARCADO En el último incremento V3 se implementó el planificador completo, se introdujo la gestión del sónar y compás digital, se implementaron los PIDs de heading y altitud. Se introdujeron comandos para cambiar los parámetros de los PIDs fácilmente al vuelo, también para poder variar los ángulos de pitch, roll, heading y la altitud objetivo de los PIDs. Finalmente se optimizó el código para que ocupara menos memoria y pudiese ejecutar en los tiempos de ejecución marcados para cada módulo.

87 Capítulo 8 Estación de Tierra (GCS) La estación de tierra es una pieza clave del proyecto al conformar la interfaz entre el vehículo autónomo y el usuario en tierra. La GCS se encarga de monitorizar los datos de telemetría que envía el vehículo y de mostrar dicha información de manera que sea productiva y usable por el personal de tierra. También es capaz de enviar comandos al vehículo, desde el plan de vuelo, hasta los comandos de parada de emergencia, incluso es posible comandar el vehículo en modo semiautomático y poder controlar pitch, roll y rumbo o heading. Por último, desde la GCS se gestionan todas las acciones relacionadas con la carga de pago y el uso de los datos recibidos por el vehículo. En este caso la GCS desarrollada muestra por un lado toda la información que envía el vehículo y por otra permite enviar distintos comandos, entre los que se encuentran comandos de inicializacion y parada, parámetros de los diferentes PID s utilizados, así como los comandos que mandan al vehículo de los ángulos de pitch, roll, heading y altitud a tomar. Por otro lado, la GCS muestra una pantalla dedicada a la ejecución y gestión de tests, así como la ejecución y calificación de pruebas de calibración del vehículo. Para facilitar el análisis de todos los datos, la GCS cuenta con un grabador/reproductor de datos que es capaz de grabar todos los datos de una prueba concreta, tanto de telemetría como de calibración de los controladores PID. De esta manera se pueden grabar todos los datos de una prueba concreta, ya sea en banco o en vuelo real, para poder reproducir y analizar a posteriori todos los datos y poder sacar información útil sobre el vuelo/prueba Arquitectura Software El entorno de desarrollo utilizado para implementar la GCS es Processing. Como se ha comentado en el capítulo Plataforma de Desarrollo 4, el entorno Processing es análogo al de Arduino, con la diferencia del lenguaje de programación utilizado, que es Java. Processing cuenta con un API de gráficos 2D/3D, utilizando como render tanto OpenGL 1 como Java3D 2. Adicionalmente se ha utilizado la librería guicomponents [29] que facilita el uso de botones y otros componentes gráficos, además de proporcionar gestión de eventos. 1 OpenGL Open Graphics Library 2 Java3D es un API para gráficos 3D del lenguaje de programación Java que puede ejecutar sobre OpenGL o sobre DirectX 71

88 72 CAPÍTULO 8. ESTACIÓN DE TIERRA (GCS) Figura 8.1: Componente gráfico Serial Comms. En la última iteración se ha introducido el uso de la librería procontroll [13] que facilita la gestión de joysticks, para proporcionar control semiautomático en tests de vuelo. De manera similar al software embarcado, la aplicación de GCS cuenta con dos puntos de entrada que son llamados automáticamente por el planificador de Processing. En el caso de Processing existe el método setup() que es llamado una única vez y que sirve para inicializar todos los controles gráficos, y el método draw() que es llamado en cada ciclo de ejecución y que es el encargado de actualizar el modelo de datos y pintar en pantalla los gráficos 2D/3D. Para facilitar el diseño y gestión de los componentes de la interfaz se decidió dividir la interfaz gráfica en componentes gráficos (también llamados widgets) independientes. Cada uno de estos componentes debe implementar un constructor y una método draw() o paint() que será llamado en cada ciclo desde el método draw() principal. Cada componente recibe en su constructor las coordenadas (x,y), el tamaño del componente gráfico, y otras propiedades como el título a mostrar en caso de que pinte uno. Adicionalmente, los componentes gráficos que gestionen eventos deben implementar los métodos handle() correspondientes a los eventos a implementar (handlemouse(), handle- Key(), etc.). Existe un manejador de eventos gestionado por la librería guicomponents que recibe los eventos y los reparte a los métodos handle() de cada componente. Los componentes gráficos pueden ser simples o complejos y todos son autocontenidos, por lo que cada componentes contiene y gestiona sus datos. Los componentes simples no están formados por otros componentes y normalmente cuentan con un método paint() o draw() que pueden recibir los datos actualizados (integer, float, etc.). Mientras que los componentes complejos están formados a su vez por otros componentes, por lo que los métodos paint() o draw() reciben todos los datos necesarios para ser pasados a los componentes contenidos. Adicionalmente, tanto componentes simples como complejos pueden gestionar eventos, por lo que deben implementar los métodos handle() adecuados, los componentes complejos deben llamar a los métodos handle() de los componentes contenidos. La interfaz gráfica se ha dividido en tres subcomponentes principales: MainMenuDisplay, que muestra el menú principal (siempre visible). PrimaryDisplay, que contiene todos los componentes principales de telemetría y comando. CalibrationDisplay, que gestiona la pantalla de calibración y test SerialComms Este componente muestra y gestiona el estado del enlace de datos. Por un lado informa del estado del enlace inalámbrico de manera que éste puede encontrarse NOT INITIATED,

89 8.3. MAINMENUDISPLAY 73 Figura 8.2: Componente MainMenuDisplay. Figura 8.3: Componente GraphicMotor. WAITING ACK en caso de estar esperando respuesta de vehículo, y CONNECTED si se ha completado el establecimiento de conexión. Además informa del puerto de comunicaciones utilizado, de manera que se puede conectar a través del enlace Zigbee inalámbrico o por un cable USB directo a la UC del vehículo. Este componente además gestiona la recepción y envío de todos los mensajes del protocolo implementado y especificado en la sección de comunicaciones del software embarcado, de manera que los mensajes enviados por el software embarcado son los que es capaz de recibir la GCS y viceversa. La gestión de comunicaciones es similar a la implementada en la UC, se cuenta con un búfer de recepción y un método de gestión de mensaje para cada mensaje. Cuando se detecta un mensaje correctamente formado en el búfer se manda dicho mensaje a un distribuidor que a su vez elimina cabeceras y se queda con los datos útiles, los cuales pasa al método que gestiona dichos datos. Normalmente la información de telemetría se almacena en variables globales y son pasadas a cada subcomponente para que actualicen su estado. Por último, el componente SerialComms cuenta con botones para solicitar conexión o desconexión del enlace de datos, y para enviar los comandos de parada de emergencia e inicio del bucle de control del vehículo (comandos que deben estar disponibles desde el momento de habilitar la conexión) MainMenuDisplay Este componente contiene los botones para cambiar de la primarydisplay a la calibrationdisplay, así como los títulos de la interfaz y la información de la versión actual PrimaryDisplay GraphicMotor Este componente muestra el estado de cada uno de los motores, así como la potencia total que el vehículo está administrando. Para cada motor se muestra una barra que indica

90 74 CAPÍTULO 8. ESTACIÓN DE TIERRA (GCS) Figura 8.4: Componente GraphicHorizon. la potencia de cada motor. Estas barras son sensibles a los eventos de click de ratón, por lo que un click en una posición de una barra concreta envía un comando de potencia de motor que intentará forzar dicha potencia al motor en cuestión. Dependerá del estado del vehículo el que el comando sea tomado en cuenta o no, por ejemplo, si el vehículo se encuentra con los controladores de estabilización desactivados, los comandos de potencia de motor serán tenidos en cuenta, de otra manera no ya que las potencias estarían bajo el control del módulo estabilizador GraphicAHorizon Este componente muestra un horizonte artificial en el que se representa la posición relativa del vehículo respecto al horizonte. Esta vista es muy útil para que el piloto en tierra tenga una idea de la posición o movimiento que está realizando el vehículo, incluso si éste se encuentra fuera del alcance visual del mismo. Para facilitar la identificación de la orientación del vehículo se pinta de color marrón lo que se corresponde con la tierra y en azul la parte de cielo (de la línea de horizonte hacia arriba). Se añade una escala semicircular que indica la inclinación en roll marcando los ángulos de 10, 20, 30 y 45 grados. También se cuenta con una escala vertical que indica la inclinación en pitch de cinco en cinco grados (numerando las decenas). El método paint() de este componente recibe los valores actualizados de pitch y roll que son usados para realizar una traslación (pitch) y una rotación (roll) de las texturas correspondientes. El constructor recibe la posición en coordenadas (x,y), y el tamaño (width) HeadingIndicator En el componente del horizonte artificial no se representa de manera alguna el giro sobre sí mismo y el ángulo correspondiente (yaw). Aunque más útil que este ángulo que es relativo a la posición del vehículo, es aquel que representa el rumbo, el ángulo que forma el morro del vehículo con el norte magnético. La mejor manera de representar el rumbo o heading es a través de una rosa de los vientos, donde se marque una escala con el rumbo cada 30 grados. En este caso el componente recibe en su método de pintado el valor actualizado de heading, y lo usa para transformar y rotar

91 8.4. PRIMARYDISPLAY 75 Figura 8.5: Componente HeadingIndicator. Figura 8.6: Componente GraphicModel. la escala de modo que se represente el rumbo actual del vehículo GraphicModel El tercer componente gráfico usado para mostrar la posición del vehículo es una representación en 3D del vehículo, de manera que se muestre cómo se está moviendo el modelo y la posición relativa respecto a los ejes x,y,z del mundo real. El modelo 3D es un modelo simplificado realizado a base de cubos. Dicho modelo se gira en los tres ejes según los valores actualizados de pitch, roll y yaw recibidos en la llamada al método paint(). Para lograr algo de perspectiva, antes de aplicar las rotaciones debidas a los ángulos, se realiza una pequeña rotación en el eje x e y para lograr un punto de vista desde una perspectiva algo superior.

92 76 CAPÍTULO 8. ESTACIÓN DE TIERRA (GCS) Figura 8.7: Componente BatteryMonitor. Figura 8.8: Distintas instancias del componente ValueIndicator BatteryMonitor Este componente gráfico representa el nivel de carga de la batería. Al ser una barra pequeña y poco precisa se establece un valor de voltaje de emergencia a partir del cual el color de la barra pasa a ser rojo, considerando de esta manera que se debe tomar una acción urgente para poner a salvo el vehículo. El valor de emergencia es configurable aunque por defecto está marcado en 10.5 V ValueIndicator Este componente gráfico es un componente genérico que muestra un valor junto con un título, en el caso del PrimaryDisplay se usa para mostrar los valores sin tratar de aceleraciones y velocidades angulares del vehículo. También se utiliza para mostrar el valor numérico de la altitud y de la temperatura medida en el vehículo. Como el resto de componentes, en el constructor se puede especificar, además de las posiciones a mostrar y el título, el tamaño del componente gráfico GraphicPID Este componente gráfico se introdujo en la última iteración para poder monitorizar y cambiar fácilmente los parámetros de un controlador PID. Se pueden cambiar los valores de Kp, Ti y Td, incluso con el vehículo en funcionamiento. Cuenta con un botón para enviar el comando correspondiente. Para poder conocer la correspondencia del componente gráfico con la instancia de PID asociada en el software embarcado, al crear el componente se le pasa (a través del constructor) un identificador enumerado que se corresponde con el enumerado declarado en la parte de software embarcado Figura 8.9: Componente GraphicPid, una instancia para cada PID existente.

93 8.5. CALIBRATIONDISPLAY 77 Figura 8.10: Componente JoystickControl. para identificar los mismos PIDs. En este caso se construyen cuatro componentes para controlar los PIDs de pitch, roll, heading, y altitud JoystickControl Este componente se añadió en la última iteración para permitir gestionar un joypad de manera que se pueda utilizar para semicomandar al vehículo pequeñas variaciones en los ángulos de pitch y roll, así como poder tener a mano botones mapeados a comandos de emergencia como parada, etc. Por un lado, el componente muestra la posición del joystick. Dicha posición se retroalimenta con la posición de los ejes proporcionada por la librería procontrol. Por otro lado muestra una serie de combos que permiten configurar los ejes a utilizar e incluso el dispositivo de entrada en caso de existir varios. Para permitir el control semiautomático se mapean los ejes X e Y del joystick con un rango de grados del orden de ± 2 grados. De esta manera, con el joystick se pueden solicitar variaciones de pitch y roll objetivo de 2 grados. El componente detecta cuando ha cambiado la posición respecto al ciclo anterior para comandar el mensaje correspondiente. También permite el mapeo de botones a diferentes comandos, por ejemplo, se pueden usar dos botones para aumentar o disminuir la altitud objetivo, o, cuando el control de altura se encuentra desactivado, aumentar o disminuir la potencia total a repartir entre los motores por los controladores de estabilización. De esta forma se pueden realizar pruebas de estabilización gestionando la navegación de manera manual CalibrationDisplay La pantalla de calibración está diseñada para configurar pruebas de calibración (Fig. 8.13) y para mostrar, por un lado el resultado de un test concreto de modo que pueda ser evaluado gráficamente, y por otro mostrar el resultado actual de la calibración siguiendo el algoritmo Qsearch desarrollado para el proyecto y detallado en el capítulo 9. Para ello, se cuenta con un apartado de configuración de calibración donde se pueden seleccionar los valores límites de cada uno de los parámetros, junto con el tiempo de duración de cada test, el tiempo de reposo entre cada ejecución de los tests, el número de tests que componen la calibración, y la iteración actual en la que se encuentra el algoritmo.

94 78 CAPÍTULO 8. ESTACIÓN DE TIERRA (GCS) Figura 8.11: PrimaryDisplay. Figura 8.12: Representación tridimensional del espacio de búsqueda.

95 8.5. CALIBRATIONDISPLAY 79 Figura 8.13: Sección de configuración de la calibración o test a realizar. Figura 8.14: Representación visual del test realizado junto con los parámetros ejecutados y el resultado obtenido. El botón Apply inicia la calibración seleccionada, una vez iniciada la GCS comanda parada e inicialización de los controladores PIDs. Entonces ejecuta el algoritmo Qsearch implementado en el fichero qsearch. Dicho algoritmo cuenta con una función de inicialización, y varias funciones importantes. La función calculatenextpoint() que devuelve las coordenadas del siguiente punto a probar (aplica a la posición actual la función que define el salto teniendo en cuenta la iteración actual), la función calculatefitness() que calcula la calidad de la prueba realizada actualmente y la máquina de estados que gestiona el estado del algoritmo. El pseudocódigo del algoritmo se puede consultar en el capítulo QSearch 9. En la parte izquierda de la pantalla se encuentra una representación 3D del espacio de búsqueda (Fig. 8.12), en el que se muestran los puntos correspondientes a las parametrizaciones probadas así como líneas que indican el progreso del algoritmo. Esta visión del espacio muestral es muy interesante ya que a través de ella se puede percibir el sentido del algoritmo y comprobar cómo las soluciones van acercándose a la solución óptima. Además esta representación 3D es interactiva, de manera que el usuario puede hacer click y girar el espacio para ver de forma más clara la progresión del algoritmo, también permite realizar zoom para apreciar mejor los valores probados.

96 80 CAPÍTULO 8. ESTACIÓN DE TIERRA (GCS) Figura 8.15: CalibrationDisplay. Por último, en la parte inferior de la derecha se encuentra una gráfica que se construye en tiempo real y en la que se representa los valores de error en el eje que se está calibrando, y que dan una perspectiva gráfica de cómo de bien o mal ha ido la prueba (Fig. 8.14). Esta gráfica puede servir también para comprobar cómo de fiel es la función de evaluación o fitness respecto a la realidad de lo ocurrido, por lo que puede usarse para modificar la función de fitness para adecuarla a las necesidades concretas del proyecto Grabador Reproductor Tanto en la pantalla principal, como en la de calibración se cuenta con un módulo grabador/reproductor. Este componente se encarga de grabar en fichero todos los parámetros que se están recibiendo a un rate determinado (generalmente 20 frames por segundo), de manera que luego puede ser reproducido el comportamiento a posteriori reproduciendo los datos al mismo rate al que fueron grabados. El módulo grabador reproductor ofrece la posibilidad de pausar la reproducción en cualquier momento. Para grabar una sesión tan solo hay que pulsar el botón de grabar o rec, entonces se abre una ventana auxiliar que permite seleccionar el fichero a escribir la sesión. Una vez seleccionado comienza la grabación, y ésta no para hasta ser pulsado el botón de parada o stop. Al pulsar el botón de reproducción o play otra ventana auxiliar permite seleccionar el fichero que contiene la sesión a reproducir. Una vez abierto, si es válido, la sesión comienza a reproducir hasta que es parada (stop) o pausada (pause). Después de una pausa se puede volver a reproducir desde el punto en el que se quedó pulsando de nuevo play.

97 8.7. EVOLUCIÓN DE LOS INCREMENTOS 81 Figura 8.16: Controles gráficos del Grabador/Reproductor. En la captura se ve una reproducción pausada. El componente grabador reproductor utiliza un módulo llamado LogManager que es el encargado de grabar y leer ficheros. El componente gráfico GraphicRecorder tan solo gestiona la máquina de estados del grabador reproductor y el LogManager utilizado (asociado a un fichero concreto), pero no la lógica de las variables a leer o escribir. Dicha lógica está implementada en el componente complejo CalibrationDisplay o Primary- Display, que consultan en cada ciclo el estado del grabador reproductor para escribir o leer las variables deseadas en el fichero asociado Evolución de los Incrementos Al igual que el resto de desarrollos, el desarrollo de la GCS ha ido marcado por los incrementos realizados y su planificación. En el incremento inicial (V0) se realizaron pruebas simples de dibujado con el API gráfico de Processing, así como pruebas de comunicaciones con el entorno Arduino a través de la conexión serie USB directa con la placa. En el segundo incremento (V1) se desarrolló una versión preliminar de casi todos los widgets, salvo los controles de los PIDs, del joystick y la ventana de calibración que se introdujeron en la siguiente iteración. Se realizó un primer diseño de toda la interfaz en cuanto a tamaño y colocación de los widgets, también se trazó la estructura general de un componente gráfico, se instrumentó el procedimiento de paso de eventos y se compuso la jerarquía de widgets simples/complejos. En el tercer incremento (V2) se actualizaron todos los widgets, dotándolos de enlace entre la parte de visualización y la lógica de comunicaciones. También se desarrolló la pantalla de calibración guiada por las necesidades del algoritmo QSearch y las pruebas necesarias para validarlo. En el cuarto y último incremento se introdujeron los controles de los PIDs, así como el control por joystick para realizar las pruebas de vuelo semiautomático. Se recolocaron casi todos los elementos gráficos rediseñando la aparencia de los widgets y de las ventanas principales y se introdujeron mejoras en la pantalla de calibración, como la posibilidad de moverse por el espacio de soluciones con el ratón, y la posibilidad de seleccionar manualmente la iteración a mostrar. También se introdujo el grabador/reproductor en ambas pantallas ya que resultó crucial para analizar los diferentes resultados de test, tanto en la pantalla de calibración como en la principal.

98 82 CAPÍTULO 8. ESTACIÓN DE TIERRA (GCS) Figura 8.17: Diagrama de clases principal GCS.

99 Capítulo 9 QSearch En este capítulo se presenta un algoritmo de búsqueda optimizada desarrollado para ser aplicado a la calibración de controladores PID. El objetivo es encontrar una parametrización PID que ofrezca estabilidad de vuelo con el mínimo número de casos de prueba. Cuando se desea resolver un problema de optimización del cual no se tiene una descripción matemática, o aún teniéndola no es posible aplicar (o no son efectivos) los métodos analíticos de resolución conocidos, se puede recurrir a los métodos de búsqueda optimizada. Los algoritmos de búsqueda optimizada son métodos computacionales que intentan optimizar un problema a base de ir eligiendo posibles soluciones dentro del espacio de búsqueda del problema, apoyándose en una función objetivo que indica cómo de buena es la solución seleccionada. Hasta ahí la descripción encaja con cualquier algoritmo de búsqueda usual, el secreto de los algoritmos de búsqueda optimizada reside en explorar el espacio de búsqueda eficientemente, dando una solución al problema antes de lo que lo haría un método aleatorio. El caso de la parametrización de controladores PID es un caso concreto de problema de optimización. El objetivo es elegir los valores óptimos de las variables que parametrizan el controlador,kp, Ti y Td. Para ello normalmente es necesario contar con un modelo de simulación del proceso que permita escoger los valores basándose en el modelo dinámico. Sin embargo, en ocasiones no se cuenta con dicho modelo (ya sea por complejidad o limitaciones en recursos). En estos casos se puede optar por realizar búsquedas optimizadas. Para ello se define el espacio de búsqueda (espacio de soluciones) como un espacio tridimensional formado por todos los posibles valores de Kp, Ti y Td. A la hora de realizar la búsqueda se cuenta con la gran restricción del coste de calcular la calidad de la solución seleccionada, ya que la función de calidad no es instantánea. Para calcular la calidad de una solución es necesario realizar una medida del comportamiento del modelo que puede incluir diferentes factores, tales como tiempo de reacción, oscilación, precisión y muchos otros indicadores que deben ser medidos con el sistema en marcha durante un tiempo determinado. Por esa razón el objetivo de este algoritmo de búsqueda optimizada no es encontrar la mejor solución, o una solución con un grado de resolución dado, sino encontrar una solución suficientemente buena con el mínimo número de candidatos seleccionados. En el caso de la estabilización de un UAV de cuatro motores la solución debe permitir una salida estable, mínima oscilación y mínimo tiempo de reacción ya que este control es crítico. Para ello es primordial una gran eficiencia en la exploración del espacio de soluciones y un alto nivel de convergencia del algoritmo de búsqueda, dándole menor valor a otros factores como gran resolución de la solución, o conocimiento de los diferentes máximos/mínimos locales, etc. 83

100 84 CAPÍTULO 9. QSEARCH 9.1. Antecedentes en búsqueda optimizada Cuando surgió el problema de la optimización de los parámetros PID, se realizó un estudio sobre los diferentes métodos de optimización existentes para examinar qué métodos podían ser aplicados y si eran prácticos en el caso concreto de nuestro problema Métodos numéricos Existen diferentes tipos de algoritmos de optimización [44] [7]. Cuando el problema en cuestión puede ser modelado matemáticamente pero la resolución analítica es complicada se pueden usar métodos de optimización numéricos, basados en la aproximación usando diferentes vertientes, tales como el método de Newton, el método del Gradiente, o diferentes combinaciones que aprovechan las virtudes de ambos métodos [7]. Estos métodos necesitan que los problemas sean derivables, ya que precisan del cálculo de Gradientes y Hessianas 1 para conocer hacia dónde buscar. Otros métodos especulan sobre las propiedades de concavidad/convexidad del problema para poder atacarlo. Al no contar con un modelo matemático de comportamiento estos métodos no son aplicables Algoritmos basados en muestras Los filtros de partículas se basan en el concepto de muestra estadística. El conjunto muestral es una población de partículas generadas y repartidas de manera pseudoaleatoria por todo el espacio de búsqueda. En lugar de aplicar la función objetivo sobre todas las posibles soluciones se aplica a cada una de las partículas (muestras). Una vez evaluada la población de partículas, se mueven o se generan nuevas partículas siguiendo una ley matemática de algún tipo, de manera que con las siguientes iteraciones el algoritmo converge en probabilidad al óptimo. Dicho de otra manera, al aumentar las iteraciones la probabilidad de contar con la solución óptima entre la población de partículas seleccionadas tiende a uno. Los algoritmos genéticos [17] y el algoritmo PSO 2 [28] son otros tipos de algoritmos basados en muestras que usan diferentes aproximaciones y heurísticas. El problema común de los algoritmos basados en filtros de partículas reside en la cantidad de evaluaciones de la calidad o fitness a realizar, al menos una para cada partícula por cada iteración Cuckoo Search El algoritmo Cuckoo Search [50] (en adelante CS) es un reciente algoritmo de muestras basado en la aplicación de metaheurísticas provenientes de la naturaleza. Como muchos otros algoritmos de optimización, las dos características principales de estas metaheurísticas son la intensificación o capacidad de buscar siempre cerca de las mejores soluciones, y la diversificación o capacidad de explorar todo el espacio de búsqueda eficientemente. Básicamente CS comienza esparciendo aleatoriamente una población de partículas a lo largo del espacio de búsqueda, se califican las soluciones y se queda con las mejores. Una 1 La matriz hessiana de una función f de n variables, es la matriz cuadrada de n x n, de las segundas derivadas parciales 2 Particle Swarm Optimization

101 9.2. DESCRIPCIÓN DEL ALGORITMO QSEARCH 85 Figura 9.1: Vuelo Levy convencional parte de las peores soluciones se descartan y sustituyen por nuevas soluciones y el resto de partículas se mueven siguiendo una distribución Lèvy [40]. Para modelizar el movimiento de las partículas los autores se fijaron en el comportamiento del vuelo de algunas moscas de la fruta y aves, que se ajusta a los denominados Lèvy Flights. Este tipo de vuelo se caracteriza por largos recorridos en línea recta seguidos de bruscos cambios de dirección con giros de 90 grados. La dirección del giro se distribuye uniformemente y el tamaño del incremento está distribuido de acuerdo a una distribución de Lèvy de la forma y = x a, donde 1 < a < 3. Para CS cada solución del espacio de búsqueda es un nido, de ellos se elige una población de nidos en los que depositar huevos (soluciones candidatas). La función objetivo pone nota a la calidad de cada nido, en cada iteración se descarta una fracción de los peores nidos, y se seleccionan nuevos nidos a través de Lèvy Flights (la población de nidos permanece constante). La potencia del algoritmo se basa en usar vuelos Lèvy para explorar el espacio de soluciones y para añadir aleatoriedad a la selección de nuevas soluciones candidatas. Aunque todos los algoritmos revisados generan soluciones muy buenas, ninguno asegura encontrar el máximo global. Además, aunque cuentan con estrategias de exploración del espacio de búsqueda eficientes, necesitan grandes cantidades de pruebas de soluciones candidatas, al tratarse de algoritmos iterativos es necesario realizar varias iteraciones para que las partículas converjan. Si contamos con una población de tamaño n constante, necesitaremos de n Iteraciones ejecuciones de la función de calidad, lo que en el caso que nos ocupa es un número demasiado grande Descripción del algoritmo QSearch El algoritmo QSearch parte del intento de usar el Cuckoo Search para el caso de la calibración de PIDs. A la hora de realizar las primeras pruebas se constató que el número de