scieee AI-readable full text Open interactive document viewer

Plataforma de pruebas para un vehículo aéreo no tripulado utilizando LABVIEW

Vianna Raffo, Guilherme; Ortega Linares, Manuel Gil; Rodríguez Rubio, Francisco

Abstract

Este artículo presenta el desarrollo de una plataforma de experimentacion para poder ensayar estrategias de control con un vehículo aéreo no tripulado. Tras describir los diferentes componentes físicos que constituyen la plataforma, el artículo presenta la aplicación desarrollada bajo LabView para poder comunicar el helicoptero con la unidad de tierra. Finalmente se presentan algunos resultados experimentales que corroboran la funcionalidad de la aplicacion, así como algunas mejoras que se estan llevando a cabo sobre la misma.

Full text

PLATAFORMA DE PRUEBAS PARA UN VEH´ ICULO A ´ EREO NO TRIPULADO UTILIZANDO LABVIEW Guilherme V. Raffo, Manuel G. Ortega, Francisco R. Rubio Dept. Ingenier´ ıa de Sistemas y Autom´ atica Escuela Superior de Ingenieros. Universidad de Sevilla Camino de los Descubrimientos, s/n. 41092, Sevilla {raffo, ortega, rubio}@cartuja.us.es Resumen Este art´ ıculo presenta el desarrollo de una plataforma de experimentaci´ on para poder ensayar estrategias de control con un veh´ ıculo a´ ereo no tripulado. Tras describir los diferentes componentes f´ ısicos que constituyen la plataforma, el art´ ıculo presenta la aplicaci´ on desarrollada bajo LabViewrpara poder comunicar el helic´ optero con la unidad de tierra. Finalmente se presentan algunos resultados experimentales que corroboran la funcionalidad de la aplicaci´ on, as´ ı como algunas mejoras que se est´ an llevando a cabo sobre la misma. Palabras clave: Veh´ ıculos a´ ereos no tripulados, plataforma de experimentaci´ on, aplicaci´ on bajo LabViewr. 1. INTRODUCCI ´ ON Uno de los principales objetivos de los sistemas de control de vuelo en los ´ ultimos a˜ nos ha sido el desarrollo de veh´ ıculos a´ ereos no tripulados (del ingl´ es UAV -Unmanned Aerial Vehicle) que sean capaces de funcionar de manera aut´ onoma. Este tipo de veh´ ıculo se est´ a empleando en tareas de b´ usqueda y rescate, vigilancia comercial, exploraci´ on de edificios, inspecci´ on, entre otras. UAV’s son muy ´ utiles, principalmente, cuando las tareas requeridas son ejecutadas en entornos de dif´ ıcil acceso y peligrosas. Hasta hace poco tiempo, desarrollar un veh´ ıculo a´ ereo en escala miniatura y controlado de manera aut´ onoma era un sue˜ no de muchos investigadores, los cuales estaban limitados por las restricciones impuestas por el hardware hasta entonces existentes. Los avances tecnol´ ogicos en actuadores y sensores en escala reducida (del ingl´ es MEMS -Micro Electromechanical Systems), as´ ı como en el almacenamiento de energ´ ıa y en el procesamiento de datos, han hecho posible la construcci´ on de robots a´ ereos no tripulados. Sin embargo, el desarrollo de sistemas de control para este tipo de veh´ ıculos no es trivial, debido principalmente a la din´ amica tan compleja inherente en los sistemas aerodin´ amicos, los cuales son multivariables, normalmente subactuados y adem´ as presentan diversas caracter´ ısticas no lineales. Por lo tanto, se requiere una estrategia de control que proporcione buen desempe˜ no en vuelo aut´ onomo, o que ayude al menos al pilotaje del veh´ ıculo, con alta maniobrabilidad y robustez con respecto a perturbaciones externas. El trabajo presentado en este art´ ıculo consiste en el desarrollo de una plataforma utilizando la herramienta LabViewra fin de poder probar diferentes estrategias de control en un veh´ ıculo a´ ereo no tripulado. La plataforma de pruebas est´ a compuesta de un ordenador de tierra, una unidad de medici´ on inercial (del ingl´ es Inertial Measurement Unit -IMU), una tarjeta de adquisici´ on de datos, un mando a distancia (del ingl´ es Remote Control -R/C), y un helic´ optero en miniatura propulsado por cuatro rotores. La comunicaci´ on entre el ordenador de tierra y la instrumentaci´ on instalada en el helic´ optero se realiza de forma inal´ ambrica. El esquema de la plataforma implementada se representa en el diagrama de la Figura 1. Figura 1: Estructura de control del helic´ optero quadrotor. El ordenador de tierra recibe informaci´ on de las aceleraciones lineales, velocidades angulares y posici´ on angular a trav´ es de la IMU que est´ a acoplada al helic´ optero. Bas´ andose en estas informaciones, un aplicaci´ on, desarrollada sobre la plataforma LabViewr, calcula las se˜ nales de control necesarias para desplazar el helic´ optero y las env´ ıa al veh´ ıculo a´ ereo mediante un mando a distancia que est´ a conectado al ordenador de tierra v´ ıa una tarjeta de adquisici´ on de datos de la marca National InstrumentTM. El resto del art´ ıculo est´ a estructurado de la siguiente manera: en el siguiente apartado se presentan los equipos utilizados, donde se describe el helic´ optero quadrotor en escala miniatura, conocido como Draganfl- yer V Ti R/C, de la marca comercial Draganfly Innovations Inc., la unidad de medici´ on inercial y la tarjeta de adquisici´ on de datos que se han utilizado. En el apartado 3, se expone la estructura del programa desarrollado para proveer de autonom´ ıa al helic´ optero. El apartado 4 presenta resultados experimentales del lazo de estabilizaci´ on del sistema. Finalmente, las conclusiones del trabajo se presentan en el apartado 5. 2. DESCRIPCI ´ ON DEL EQUIPO 2.1. HELIC ´ OPTERO QUADROTOR El veh´ ıculo a´ ereo utilizado en este trabajo es un helic´ optero en miniatura en la configuraci´ on de cuatro rotores coplanarios (quadrotor), tal como se presenta en la Figura 2. El movimiento del UAV se origina a partir de los cambios de velocidad de los rotores. Cada rotor consta de un motor el´ ectrico de corriente continua, un mecanismo de engranaje y un rotor de palas con ´ angulo de ataque fijo. Para lograr movimiento hacia adelante la velocidad del rotor trasero debe ser aumentada y, simult´ aneamente, la velocidad del rotor delantero debe ser disminuida. El desplazamiento lateral se ejecuta con el mismo procedimiento, pero usando los rotores de la derecha y de la izquierda. El movimiento de gui˜ nada (yaw) se obtiene a partir de la diferencia en el par de torsi´ on entre cada par de rotores, o sea, se acelera los dos rotores con sentido horario mientras se desacelera los rotores con sentido anti-horario, y viceversa. F 1 F 4 F 2 F 3 U 4 U 1 U 3 U 2 Figura 2: Esquema de funcionamiento del helic´ optero quadrotor. El helic´ optero quadrotor empleado es el modelo comercial Draganflyer V Ti Pro R/C, que a trav´ es de su grupo propulsor puede alcanzar una velocidad de aproximadamente 9,44m/s[1]. El Draganflyer V Ti Pro R/C trae de f´ abrica una micro c´ amara de v´ ıdeo inal´ ambrica CCD (del ingl´ es Charge Coupled Device) de 1/4”, con resoluci´ on de 430 l´ ıneas, que est´ a sujetada a la estructura del helic´ optero por un sistema que aumenta la resistencia y reduce vibraciones. El transmisor de v´ ıdeo opera a una frecuencia de 2.4GHz y a una potencia de 50mW. Una antena circular polarizada, conectada a un sistema receptor, capta las se˜ nales enviadas por el transmisor de la c´ amara y las env´ ıa al ordenador remoto. Adem´ as, el helic´ optero quadrotor posee una electr´ onica embebida que est´ a constituida por 4 sensores t´ ermicos, tres gir´ oscopos, un receptor FM (del ingl´ es Frequency Modulation) de doble conversi´ on a 72MHz y un DSP (del ingl´ es Digital Signal Processor) que se encarga de comunicarse con el mando a distancia, controlar la velocidad de los motores bas´ andose en la cantidad de aceleraci´ on y velocidades angulares que requiera el piloto, y estabilizar el helic´ optero cuando sean activados los sensores t´ ermicos. El mando remoto que acompa˜ na el Draganflyer V Ti Pro R/C es un transmisor FM digital a 72MHz, de seis canales de la marca comercial Hitecr. La energ´ ıa necesaria para los motores el´ ectricos, la electr´ onica embebida y el sistema de visi´ on se suministra con una bater´ ıa de pol´ ımero de litio compuesta de tres c´ elulas y provee 11,1 voltios con 1320 mAh. Con esta bater´ ıa se tiene una autonom´ ıa de vuelo de entre 12 y 15 minutos. La estructura del helic´ optero es de fibra de carbono y nylon, y las h´ elices han sido moldeadas por inyecci´ on de nylon de alta resistencia. El helic´ optero mide 76 cm de di´ ametro, y sin considerar la unidad de medici´ on inercial, presenta una masa de 525 g. 2.2. UNIDAD DE MEDICI ´ ON INERCIAL La unidad de medici´ on inercial utilizada en este proyecto es el modelo Inertia-Linkrde la marca comercial MicroStrainr, que adem´ as es un giroscopio vertical. Este modelo utiliza tecnolog´ ıa de sensores miniaturizados, nombrada MEMS, combinando un aceler´ ometro triaxial, un gir´ oscopo triaxial, sensores de temperatura y un procesador embebido ejecutando un algoritmo de fusi´ on de sensores [2]. Esta IMU ofrece un rango de datos de salida a partir de medidas inerciales plenamente calibradas para calcular estimaciones de orientaci´ on del sensor. Todas las medidas son compensadas por temperatura y corregidas para la desalineaci´ on del sensor. Las medidas de velocidad angular son adem´ as corregidas por sensibilidad-G y por un factor de escala no lineal del gir´ oscopo. La interfaz de comunicaci´ on de la IMU est´ a contenida en un modulo separado y puede, por lo tanto, ser f´ acilmente configurable. Actualmente, la comunicaci´ on est´ a hecha a trav´ es de un transmisor inal´ ambrico, con una tasa de transmisi´ on de datos de 1 a 250Hz y ancho de banda del sensor de 1 a 100Hz, ambos configurables. La comunicaci´ on inal´ ambrica est´ a basada en la norma IEEE 802.15.4 (2.45GHz). Posee 16 canales entre 2.450GHz y 2.490GHz [2]. 2.2.1. Protocolo de comunicaci´ on La comunicaci´ on de la IMU est´ a basada en el protocolo 3DM-GX2TM Data Communication Protocol [3]. Este es un conjunto de comandos y respuestas en serie dise˜ nados espec´ ıficamente para sensores de orientaci´ on de MicroStrainr. La estructura de comandos utilizada en este trabajo se corresponde con el caso de sensores inal´ ambricos. Todas las comunicaciones con el sensor son realizadas usando un puerto serie est´ andar. Esto se consigue gracias a un controlador del dispositivo que convierte las distintas opciones del interfaz proporcionadas por el fabricante (RS-232, RS-485, RS- 422, USB y inal´ ambrica (802.15.4)). Como el sensor en cuesti´ on utiliza comunicaci´ on inal´ ambrica, se requieren ciertas consideraciones a la hora de comunicarse con la estaci´ on base. A pesar de que la comunicaci´ on de este sensor se hace a trav´ es de un puerto serie virtual, los datos transmitidos entre el sensor y el ordenador deben ser realizados como en la versi´ on empaquetada del protocolo. Esto se debe a la informaci´ on adicional necesaria para diferenciar el sensor, el cual puede estar compartiendo un canal de radio con otros sensores. La estaci´ on base inal´ ambrica-USB utiliza esta informaci´ on para encaminar los datos hacia el sensor inal´ ambrico correcto. Los comandos empaquetados difieren de los no empaquetados en que son precedidos por un paquete de cabecera y seguido por un paquete de final de mensaje ([3]). En general estos sensores poseen la misma configuraci´ on para el puerto serie COM, donde la tasa de transmisi´ on es siempre de 115.2K baudios. En este protocolo el ordenador remoto controla qu´ e datos salen del sensor emitiendo uno o m´ as comandos (en algunos casos, los bytes adicionales de datos deben seguir al byte de comando). Cada comando enviado a la IMU har´ a que ´ esta transmita un dato o un n´ umero fijo de bytes. El sensor puede operar seg´ un dos modos de comunicaci´ on: uno muestreado y otro continuo. En el modo muestreado, un ´ unico dato es transmitido para cada byte de comando recibido. Por otra parte, en el modo continuo, se guarda un byte de comando en la memoria del sensor y el dato correspondiente se env´ ıa continuamente por la IMU sin necesidad de intervenci´ on del ordenador. En este trabajo se ha implementado solamente el modo muestreado. Los comandos y dem´ as datos sobre el protocolo de comunicaci´ on del sensor Inertia-Linkrse pueden encontrar en la referencia [3]. 2.3. TARJETA DE ADQUISICI ´ ON DE DATOS Para comunicar el ordenador de tierra con el mando a distancia, con el fin de transmitir al helic´ optero las se˜ nales de control, se ha utilizado la tarjeta de adquisici´ on de datos NI USB-6251 de la marca comercial National InstrumentsTM [4]. La tarjeta tiene dos salidas anal´ ogicas, lo cual es suficiente puesto que la se˜ nal de control se env´ ıa multiplexada por una de las salidas. Las salidas anal´ ogicas de esta tarjeta pueden alcanzar una velocidad de transmisi´ on de 2.86MHz, que es necesaria para conseguir generar el tren de pulsos que codifica la se˜ nal de control en cada tiempo de muestro. Adicionalmente, la tarjeta dispone de un buffer de 4096 bytes que puede ser utilizado para almacenar una forma de onda determinada, y gestionar el vaciado del buffer hacia la salida anal´ ogica seg´ un la tasa de muestreo seleccionada. Esta funcionalidad de la tarjeta es utilizada para recibir y almacenar en un solo env´ ıo el tren de pulsos de la se˜ nal de control previamente programada, siendo la tarjeta la encargada de gestionar el tiempo de salida de los datos del buffer. 3. INTERFAZ ORDENADOR-HELIC ´ OPTERO Para convertir el helic´ optero quadrotor en un veh´ ıculo a´ ereo aut´ onomo, se ha optado por implementar una plataforma de control remota, como se ha comentado anteriormente. El programa que supervisa y controla el helic´ optero se ha desarrollado en LabViewry est´ a dividido en tres lazos principales: uno que env´ ıa y recibe datos de la IMU, otro que calcula las se˜ nales de control, y un tercero que, bas´ andose en las se˜ nales de control, genera un tren de pulsos y lo env´ ıa a la tarjeta de adquisici´ on de datos, que est´ a conectada al mando a distancia. Estos tres lazos se ejecutan de forma concurrente en la plataforma LabViewr, donde se asigna a cada lazo un valor de prioridad y el periodo de ejecuci´ on de cada ciclo. En la Figura 3 se presenta la pantalla principal del programa. A continuaci´ on se describen las principales funcionalidades de la aplicaci´ on. 3.1. LECTURA Y ESCRITURA DE LA IMU El controlador desarrollado en LabViewrpara comunicar el ordenador de tierra con la IMU se ha implementado de manera que los comandos descritos en el protocolo 3DM-GX2TM Data Communication Protocol sean ejecutados seg´ un el modo muestreado. Por lo tanto, la escritura y lectura de datos del sensor se realiza por medio del ordenador de tierra en cada ciclo del programa. En la Figura 4 se expone la pantalla del programa referente a la unidad de medici´ on inercial. En el programa se han implementado las siguientes funciones proporcionadas por el sensor: Aceleraci´ on y Velocidad Angular;∆´ Angulo y ∆Velocidad;Matriz de Rotaci´ on;Aceleraci´ on, Velocidad Angular y ´ Angu- Figura 3: Pantalla principal del controlador del helic´ optero en LabViewr. los de Euler;´ Angulos de Euler; y Velocidad Angular y ´ Angulos de Euler. Se han implementado tambi´ en funciones para monitorizar la tasa transmisi´ on de datos, las se˜ nales de LQI (Link Quality Indication) y RSSI (Receive Signal Strength Indicator), as´ ı como la medici´ on del ancho de banda. Figura 4: Pantalla de la IMU Inertia-Linkr. La rutina que se ha implementado para monitorizar el sensor inercial empieza habilitando el puerto serie en que se ha conectado la estaci´ on base inal´ ambrica- USB. La configuraci´ on del puerto serie se realiza en la carpeta Signal Data, donde tambi´ en se tiene acceso a informaciones de la calidad de la se˜ nal. Hecho esto, se habilita un lazo continuo y se empieza a realizar la comunicaci´ on entre el ordenador de tierra y el sensor. Dentro del lazo, primero se emite un paquete realizando al sensor la petici´ on de los datos elegidos (por ejemplo, los datos de aceleraci´ on y velocidad angular en el instante actual), seguido de un bloque que lee el puerto serie. En este bloque se llevan a cabo una serie de intentos para lograr la lectura de los datos. Si la lectura de los datos se realiza con ´ exito, ´ estos son convertidos de valores en hexadecimal a valores en el formato IEEE 754, los cuales son tratados y expresados en unidades f´ ısicas. Las informaciones obtenidas se representan a trav´ es de gr´ aficas y se ponen a disposici´ on del lazo de control en el caso de que las necesite. 3.2. GENERADOR DEL TREN DE PULSOS Como se coment´ o anteriormente, el ordenador de tierra env´ ıa se˜ nales de control al helic´ optero mediante el mando a distancia. ´ Este recibe las se˜ nales a trav´ es de un puerto de entrenamiento que se habilita con un conmutador instalado en el propio mando. El tipo de se˜ nal que hay que enviar a este puerto resulta ser un tren de pulsos, donde cada pulso representa un canal del mando, y el ancho del pulso informa sobre lo que hay que aplicar en cada canal. Consecuentemente, se ha desarrollado un programa que genera tal tren de pulsos. La pantalla donde se configura el generador del tren de pulsos e informa sobre su estado, se presenta en la Figura 5. En el primer paso se configura la frecuencia del tren de pulsos, as´ ı como su amplitud. En esta etapa tambi´ en se define la configuraci´ on de la tarjeta de adquisici´ on de datos, fijando la salida anal´ ogica que se utilizar´ a, los Figura 5: Pantalla del generador de tren de pulsos. l´ ımites inferior y superior de la tensi´ on de salida, y el tama˜ no del buffer utilizado por la tarjeta. El tren de pulsos se genera cada 22,5ms, teniendo cada pulso un ancho de banda de 800 µ scuando el ciclo de trabajo est´ a al 100%. Un canal tiene una duraci´ on m´ ınima de 920 µ sy m´ axima de 2120 µ s, siendo los primeros 400 µ sun tiempo muerto entre el final del pulso del canal anterior y el inicio del pulso del canal actual. Cada canal puede ser ajustado independientemente, utilizando la funci´ on Trimmer, si fuese necesario compensar alg´ un desequilibrio del helic´ optero. Adem´ as, cada canal puede ser habilitado de manera aislada, haciendo que la acci´ on generada por el lazo de control no sea enviada al mando, y as´ ı, se mantiene el valor de defecto. En la Figura 6 se presenta un ejemplo del tren de pulsos. Figura 6: Tren de pulsos. Realizada la configuraci´ on del tren de pulsos, as´ ı como la de la tarjeta anal´ ogica, se inicia el lazo de generaci´ on de la forma de onda que se repite, como ya se ha comentado, cada 22,5ms. Bas´ andose en el valor de la acci´ on de control, se calcula el tiempo de inicio de cada pulso, el desfase entre ellos y el ciclo de trabajo de cada uno con respecto al tiempo del tren de pulsos. Cada pulso se genera de forma independiente de los otros utilizando la funci´ on Waveform Buffer Generation DAQ de Labviewr, y al final se suman todos ellos dando origen a la forma de onda necesaria, la cual se env´ ıa a la tarjeta de adquisici´ on de datos. Para finalizar el lazo se traza la gr´ afica del tren de pulsos. 3.3. LAZO DE CONTROL El lazo de control se ejecuta a un nivel superior que el correspondiente al de los dos anteriores. En cada ciclo se leen los datos suministrados por el sensor, y bas´ andose en estos, se ejecutan los controladores desarrollados, los cuales suministran las se˜ nales de control enviadas al lazo de generaci´ on del tren de pulsos. En la Figura 3 se presenta, adem´ as de la portada principal del programa, la interfaz de los controladores disponibles. Antes de ejecutar el lazo de control, se requieren algunas configuraciones del programa, como elegir en qu´ e archivo, con extensi´ on .m, se almacenar´ an los datos del experimento, los valores de referencia de las salidas para los controladores y el periodo de muestreo, entre otras cosas. La Figura 7 muestra la pantalla en la que se determinan los valores de referencia, se habilita y dibuja la estimaci´ on de la posici´ on en el triedro xyz basada en las medidas de aceleraciones lineales del sensor, y en la que se traza la gr´ afica de las se˜ nales de control aplicadas. Figura 7: Pantalla para determinar los valores de referencia y habilitar la estimaci´ on de la posici´ on xyz. Una vez realizados todos los tr´ amites iniciales, se pasa a la etapa de elecci´ on del controlador a utilizar. El programa est´ a pensado para que se pueda trabajar tan- to en bucle abierto como en bucle cerrado. En bucle abierto se han programado dos funciones, una donde se aplican escalones a las entradas de control del helic´ optero, y otra donde se generan entradas senoidales con amplitud y frecuencia ajustables. Para trabajar en bucle cerrado se ha dividido el sistema en dos sub-sistemas, donde se realizan el bucle de control de los movimiento de rotaci´ on y el bucle de control de los movimientos de traslaci´ on lineal. Para lograr la estabilizaci´ on del sistema se han implementado cuatro controladores: proporcional, PID (Proporcional- Derivativo-Integral), Backstepping [5]y H∞no lineal [6, 7]. Los controladores se han programado en lenguaje C gener´ andose un archivo .dll. El bucle de control de los movimientos de traslaci´ on tiene implementado, para este trabajo, un controlador PID. Una ventaja en la manera en la que este programa est´ a dise˜ nado es su car´ acter gen´ erico, pudiendo implementarse f´ acilmente otros controladores a partir de un archivo .dll. Adem´ as, permite el control de otras aeronaves siendo solamente necesario que se incorpore la unidad de medici´ on inercial Inertia-Linkry que el veh´ ıculo reciba las se˜ nales de control a trav´ es de un mando a distancia. 4. RESULTADOS EXPERIMENTALES En este apartado se exponen resultados experimentales obtenidos con la plataforma presentada. Debido a que la realimentaci´ on de la posici´ on del veh´ ıculo est´ a en fase de implementaci´ on, y que la IMU s´ olo provee informaci´ on fiable de la orientaci´ on del sistema, en los experimentos realizados s´ olo se ha utilizado el control de orientaci´ on. Por lo tanto, el empuje principal (´ unica se˜ nal de control que no gestiona este controlador) se ha modificado manualmente desde el ordenador de tierra. En la figura 8 se muestra el esquema de la estrategia de control utilizada para la realizaci´ on de experimentos. Para realizar una estimaci´ on de los par´ ametros del sistema se han pesado y medido las distintas partes del equipo. Sin embargo, dado que el sistema no permite tener un acceso directo al control de la velocidad de los motores, se han realizado experimentos de identificaci´ on en bucle cerrado para determinar la relaci´ on entre los pares ejercidos por la propulsi´ on de las h´ elices y las se˜ nales de control Uique se env´ ıan desde la computadora de tierra. En los experimentos de identificaci´ on se ha controlado el sistema con un control proporcional, consiguiendo que el sistema real oscile con una cierta frecuencia y amplitud. En la figura 9 se muestran los resultados de estos experimentos. A partir de estos datos, se ha ajustado mediante simu- Figura 8: Control de orientaci´ on para el helic´ optero quadrotor. 0 1 2 3 4 5 6 7 8 9 10 −20 −10 0 10 20 φ 0 1 2 3 4 5 6 7 8 9 10 −20 −10 0 10 20 θ 0 1 2 3 4 5 6 7 8 9 10 −4 −2 0 2 4 tiempo [s] ψ Figura 9: Oscilaciones experimentales. laci´ on la ganancia de un controlador proporcional que consiga que el sistema simulado oscile aproximadamente con la misma frecuencia y amplitud. En la figura 10 se muestran los resultados de simulaci´ on. 0 1 2 3 4 5 6 7 8 9 10 −20 −10 0 10 20 φ 0 1 2 3 4 5 6 7 8 9 10 −20 −10 0 10 20 θ 0 1 2 3 4 5 6 7 8 9 10 −20 −10 0 10 20 tiempo [s] ψ Figura 10: Oscilaciones simuladas. La relaci´ on de ganancias resultantes ha sido del orden de 3.5 veces mayor la se˜ nal de control del modelo frente a la se˜ nal de control del sistema real. En las figuras 11 y 12 se muestran algunos resultados experimentales preliminares logrados con controladores aplicados al subsistema rotacional. Como puede verse, tras aplicar un escal´ on en U1(figura 11) el resto de se˜ nales de control act´ uan de manera que los ´ angulos de Euler (figura 12) se mantengan en un valor cercano al cero, controlando la orientaci´ on del sistema. El helic´ optero se deja de controlar a los 45 segundos aproximadamente (v´ ease se˜ nal de control U1). Como puede observarse en las gr´ aficas de los resultados, a partir de este instante los ´ angulos aumentan debido a que el helic´ optero se ha inestabilizado. 10 15 20 25 30 35 40 45 50 55 20 40 60 80 U1 [%] 10 15 20 25 30 35 40 45 50 55 0 50 100 U2 [%] 10 15 20 25 30 35 40 45 50 55 20 40 60 80 U3 [%] 10 15 20 25 30 35 40 45 50 55 40 50 60 tiempo (s) U4 [%] Figura 11: Se˜ nales de control. 10 15 20 25 30 35 40 45 50 55 −20 −10 0 10 20 φ (º) 10 15 20 25 30 35 40 45 50 55 −20 −10 0 10 20 θ (º) 10 15 20 25 30 35 40 45 50 55 −10 −5 0 5 10 tiempo (s) ψ (º) Figura 12: Orientaci´ on del helic´ optero quadrotor. 5. CONCLUSIONES En este trabajo se ha presentado una plataforma de pruebas para el control de veh´ ıculos a´ ereos no tripulados. La aplicaci´ on se ha desarrollado utilizando la herramienta Labviewr, donde se han implementado tres algoritmos concurrentes, uno que gestiona la comunicaci´ on entre la unidad de medici´ on inercial y el ordenador de tierra; otro que se encarga de generar la forma de onda a ser enviada al mando a distancia y, por ´ ultimo, el algoritmo responsable por ejecutar las leyes de control destinadas a realizar las tareas de seguimiento de trayectoria y estabilizaci´ on del veh´ ıculo. Finalmente, se han presentado resultados experimentales para la estabilizaci´ on del helic´ optero quadrotor, donde se pudo validar la funcionalidad de la plataforma propuesta. Sin embargo, uno de las cuestiones a´ un no resueltas satisfactoriamente est´ a relacionada con el periodo de muestreo necesario para garantizar el control del helic´ optero, principalmente causado por el uso del sistema operacional Windows XPr. Para solucionar este problema se est´ a implementando la plataforma en el sistema operativo RTLinux. Adem´ as, para poder evaluar las estrategias de control para el sistema comple- to, se est´ a implementado un sistema de medici´ on de la posici´ on espacial utilizando sensores ultras´ onicos. Agradecimientos Los autores desean agradecer al MCyT la financiaci´ on de este trabajo con cargo a los los proyectos de investigaci´ on DPI2007-64697 y DPI2006-07338. Referencias [1] Draganfly Innovation Inc. Draganflyer V Ti Pro Manual. Technical report, Draganfly Innovation Inc., Canada. [2] MicroStrain Inc. Technical Product Overview - Inertia-Linkr: Inertia Measurement Unit and Vertical Gyro, 2006. [3] MicroStrain Inc. 3DM-GX2TM Data Communication Protocol. Technical Report Version 1.08, MicroStrain, Inc., Williston, VT, Mar 2007. [4] National Instruments. DAQ M Series - M Series User Manual NI 622x, NI 625x, and NI 628x Devices. Technical Report 371022H-01, National Instruemnts, Texas, USA, June 2007. [5] G. V. Raffo. Modelado y Control de un Helic´ optero Quad-Rotor (in Spanish). Master’s thesis, Universidad de Sevilla, Dept. Ing. Sistemas y Autom´ atica, Sevilla, Spain, 2007. [6] G. V. Raffo, M. G. Ortega, and F. R. Rubio. Backstepping/Nonlinear H∞Control for Path Tracking of a QuadRotor Unmanned Aerial Vehicle. In Proc. of the American Control Conference - ACC2008, pages–, June 2008. [7] G. V. Raffo, M. G. Ortega, and F. R. Rubio. MPC with Nonlinear H∞Control for Path Tracking of a Quad-Rotor Helicopter. In Proc. of the IFAC World Congress 2008, 2008.