Verificación y validación de sistemas de control de vuelo para mav-vtol basadas en matlab stateflow

Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) VERIFICACI ´ ON Y VALIDACI ´ ON DE SISTEMAS DE CONTROL DE VUELO PARA MAV-VTOL BASADAS EN MATLAB STATEFLOW Pablo Rodr´ıguez1, Jes´us G. Villag´omez2, Manuel Vargas2, Francisco R. Rubio2 1[email protected]om ,2{villagomez, mvargas, rubio}@us.es Departamento de Ingenier´ıa de Sistemas y Autom´atica, Universidad de Sevilla Resumen Se presenta el desarrollo de una soluci´on para la verificaci´on y validaci´on de sistemas de gobierno y control de vuelo para peque˜nas plataformas de tipo VTOL (Vertical Take-Off and Landing). Para la simulaci´on del veh´ıculo se dispone del correspondiente modelo din´amico, que ser´a interconectado con diferentes subsistemas de control de estabilizaci´on y posici´on, gobernados por una m´aquina de estados definida en MATLAB Stateflow. El conjunto de simulaciones para la verificaci´on del dise˜no de la soluci´on propuesta son llevadas a cabo mediante Simulink. El objetivo es disponer de mecanismos que permitan evaluar el correcto funcionamiento de prototipos antes de ser evaluados en condiciones reales. Palabras clave: Arduino, Docencia, MATLAB Stateflow R ,Quadrotor, Simulaci´on. 1. INTRODUCCI ´ ON El uso de plataformas MAV-VTOL (Miniature Autonomous Vehicle - Vertical Take Off and Landing) [5] ha experimentado un notable crecimien- to en los ´ultimos tiempos. Bien para investigaci´on como para uso dom´estico, este tipo de veh´ıculos son ideales principalmente gracias a su bajo coste y al amplio conjunto de aplicaciones en las que permite ser utilizado: desde vigilancia a´erea hasta transporte de carga. Su uso est´a cada vez m´as extendido e incluso normativas de tipo legal est´an siendo desarrolladas para poder legislar su aplicaci´on futura en entornos urbanos [1]. En el ´ambito de la Academia, existen numerosos trabajos que combinan el estudio de controladores para la estabilizaci´on y estimaci´on del estado [4][15], bien en interiores o exteriores, gracias a las posibilidades de expansi´on sensorial que permiten estos veh´ıculos. La inclusi´on de sensores exteroceptivos (c´amaras, sensores de tipo l´aser, etc.) al sistema no es m´as que una evoluci´on del mismo que permite posibilidades de navegaci´on aut´onoma, incluso en entornos no estructurados. Trabajos recientes ponen de manifiesto la capacidad de ampliaci´on funcional e interacci´on con el entorno que permiten estas plataformas, mediante la inclusi´on de peque˜nos brazos manipuladores [7], actuadores de c´amara giro-estabilizados [11] o sensores de pre- si´on y contacto para diferentes tipos de aplicaciones [13]. Sin embargo, la integraci´on de los diferentes subsistemas que conforman estas plataformas y su configuraci´on y adaptaci´on no es trivial. Como plataforma a´erea rob´otica, es imprescindible que la combinaci´on de software y hardware embarcado funcione seg´un lo establecido, siendo robusto a fallos de tipo sensorial o bien de p´erdida de comunicaci´on con el enlace de tierra, entre otros. En caso contrario, cualquier excepci´on no contemplada en el desarrollo del software, derivar´a en un fallo que provocar´ıa grandes desperfectos en la plataforma y riesgos para terceros, con el consiguiente coste econ´omico tanto de materiales como de horas de trabajo. Por ello, la evaluaci´on del software embarcado antes de su uso es imprescindible para poder detectar fallos de codificaci´on o situaciones no contempladas. Las soluciones actuales, econ´omicamente viables, que combinan hardware y software m´as extendidas est´an basadas en entornos de microprogramaci´on en lenguage C/C++ y hardware basado en Arduino, conocidas como Arducopter [2]. Peri´odicamente la Comunidad aporta nuevas actualizaciones del firmware del dispositivo e incluye nuevas mejoras y funcionalidades. A nivel de investigaci´on, lo que se pretende es poder reutilizar parte de estas aportaciones para poder avanzar en campos como el control o la fusi´on sensorial, pudiendo acceder a cualquier elemento hw/sw del sistema y poder reconfigurarlo, si fuera necesario. Si bien es una plataforma muy extendida, no es posible una comprobaci´on por simulaci´on del sistema, de tal manera que ante cualquier modificaci´on del c´odigo fuente, o bien una reformulaci´on de la l´ogica de aplicaci´on, la ´unica depuraci´on y verificaci´on posibles, incluyendo el comportamiento de los controladores, es mediante el despegue de la plataforma y comprobando que la evoluci´on de la misma no deriva en situaciones de inestabilidad. Para entornos como investigaci´on y docencia, son situaciones no admisibles. Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) Se hace por tanto imprescindible el desarrollo de entornos que permitan una simulaci´on completa del sistema para su verificaci´on, control de supervisi´on, planificaci´on de tareas, gesti´on de fallos y posterior validaci´on. Es lo que se conoce t´ıpicamente como “Software-in-the-loop”: como m´aquina de estados que permite probar el comportamiento del sistema ante cualquier entrada o evento externo, comprobando que la salida se corresponde con lo previamente dise˜nado. Existen otras t´ecnicas m´as avanzadas de verificaci´on y validaci´on de modelos software: son las denominadas t´ecnicas basadas en modelo o “Model checking” [12][14]. Estas t´ecnicas est´an basadas en l´ogicas de tipo modal y descriptiva para la representaci´on del conocimiento y automatizaci´on del comportamiento. Son t´ecnicas que permiten una evaluaci´on exhaustiva del sistema. Sin embargo, gr´aficamente no es posible ver su evoluci´on y a nivel acad´emico son dif´ıciles de implantar a corto o medio plazo. La soluci´on propuesta en este trabajo, para dise˜nar e implementar una m´aquina de control de estados e integrarla en una plataforma de tipo quadrotor, est´a basada en la combinaci´on de MATLAB Stateflow R y el software de simulaci´on MATLAB Simulink R , muy extendido a nivel acad´emico [16]. Stateflow es un entorno para el modelado y simulaci´on de l´ogica de decisi´on combinatoria y secuencial basado en m´aquinas de estado y diagramas de flujo. Permite la representaci´on de diagramas de transici´on de estado con el fin de modelar la evoluci´on del sistema ante eventos internos, externos o condiciones basadas en tiempo. El desarrollo del presente trabajo queda estructurado como sigue: en la secci´on 2 se presenta brevemente una descripci´on del modelo din´amico de la plataforma utilizada para la experimentaci´on, de tipo quadrotor. Las secciones 3 y 4 presentan en detalle la soluci´on propuesta y diferentes alternativas para la representaci´on de las salidas del sistema, respectivamente. La secci´on 5 explora la capacidad de integraci´on del dise˜no propuesto en hardware real y las principales conclusiones y propuestas de trabajo futuro son presentadas en la secci´on 6. 2. MODELADO DIN ´ AMICO Uno de los puntos clave de la soluci´on propuesta es la modularidad que presenta. Es posible reutilizar la misma m´aquina de estados para el gobierno de cualquier plataforma de tipo VTOL, intercambiando el modelo din´amico del veh´ıculo bajo estudio y los controladores de estabilizaci´on y posici´on correspondientes. As´ı, en esta propuesta, se ha utilizado el modelo din´amico correspondiente a un veh´ıculo denominado quadrotor, con 4 motores coplanarios. Desde el punto de vista din´amico, un quadrotor consiste en una masa puntual suspendida en el aire sobre la cual se aplican diferentes fuerzas y momentos, combinando tan s´olo las velocidades de los diferentes rotores [4][5]. Para generar un movimiento de balanceo o roll (´angulo φ), se produce un desequilibrio entre las fuerzas f2yf4(Figura 1). An´alogamente, para un movimiento de cabeceo o pitch (´angulo θ), el desequilibrio se realizar´a entre las fuerzas f1yf3. El movimiento de gui˜nada, o yaw (´amgulo ψ), es resultado del desequilibrio entre los pares de fuerzas (f1,f3) y (f2,f4) producidas por pares de motores que giran en sentidos opuestos. Como consecuencia de magnitudes positivas en los ´angulos de balanceo y cabeceo, se producen movimientos de tipo lateral y longitudinal, respectivamente, consiguiendo as´ı desplazamientos traslacionales. Desde el punto de vista del n´umero de entradas manipulables y grados de libertad, el sistema se considera subactuado, de manera que tan s´olo se dispone de 4 se˜nales de actuaci´on (motores f1...4) para controlar los 6 grados de libertad (orientaci´on y posici´on) propios de un sistema a´ereo. El empuje total proporcionado por la rotaci´on de los motores se obtendr´a como la suma de las fuerzas que ejercen los mismos. Figura 1: Representaci´on de fuerzas y pares resultantes sobre la estructura de tipo quadrotor. Bajo ciertas consideraciones [15], es posible plantear las ecuaciones que rigen la din´amica en dos subsistemas interconectados: traslaci´on (ecuaci´on 1) y rotaci´on (ecuaci´on 2): m¨ ξ+mge3=fξ(1) M(η)¨η+C(η,˙η)˙ η=τη(2) Los principales sistemas de coordenadas relevantes en el modelado son: sistema de referencia inercial, Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) supuesto fijo sobre la superficie de la Tierra, {W} (World coordinate frame), y el sistema {B} (Body coordinate frame), supuesto solidario al movimien- to del veh´ıculo. Se tiene que WξB= [x y z]>∈R3 representa la posici´on del centro de rotaci´on del veh´ıculo, expresado en el marco de referencia inercial. WηB= [φ θ ψ]>∈R3son los denominados ´angulos de Tait-Bryan; fξ∈R3son los fuerzas aplicadas en cada eje; `es la distancia entre el origen del sistema By el eje de rotaci´on de cada motor (se asume estructura sim´etrica); τη∈R3son los pares generados como consecuencia del desequilibrio de fuerzas; m es la masa del helic´optero; g es el m´odulo de la aceleraci´on de la gravedad; M(η)∈R3×3es la matriz de inercia; C(η,˙η)∈R3×3es la matriz de Coriolis y e3= [0 0 1]>∈R3. 3. DESCRIPCI ´ ON DE LA SOLUCI ´ ON Siguiendo una descripci´on de tipo top-bottom, se dispone de tres elementos principales interconectados que componen la soluci´on propuesta: m´aquina de estados, o diagrama de Stateflow; bloques de control e implementaci´on del modelo din´amico de la plataforma (Figura 2). 3.1. DIAGRAMA STATEFLOW El diagrama de Stateflow permite definir l´ogica de decisi´on compleja en el control de la plataforma de forma gr´afica y estructurada, con el fin de simular la respuesta del sistema a entradas externas, eventos y condiciones temporales. En esta propuesta, existen dos elementos principales para el dise˜no: estados y transiciones. Los estados representan modos de funcionamien- to del sistema, que se ejecutan de forma exclusiva o en paralelo. En ´estos se establecen valores para variables y se incluyen funciones relativas a la sem´antica de Stateflow, recurriendo a bloques externos que incluyen funciones de MATLAB o diagramas de Simulink. Se organizan de forma jer´arquica y pueden relacionarse entre s´ı mediante transiciones, que incluyen alg´un tipo de restricci´on o condici´on y permiten gestionar el paso de un estado a otro. 3.1.1. Descripci´on de los estados Si bien la definici´on de los diferentes estados no es ´unica, a continuaci´on se expone el conjunto m´ınimo de estados necesarios para recoger la l´ogica b´asica relativa a la evoluci´on de un VTOL, tanto en tierra como en el aire (Figura 3). Tierra Considerado como el estado inicial. Se establece para comprobar y calibrar los distintos componentes del quadrotor, tales como GPS, enlace RC, s´onar, bar´ometro, IMU, sensor de flujo ´optico. etc. Si se realiza correctamente, el sistema estar´a listo para realizar una transici´on ante el evento “Volar” y conmutar al estado “Aire”. Aire El estado “Aire”se define desde que la plataforma est´a disponible para iniciar el vuelo. A su vez se descompone de los siguientes subsistemas: Despegue El despegue es la fase siguiente al estado “Tierra”, y se encarga de proporcionar referencias en altura para un despegue estable y coordinado de la plataforma, por lo que adem´as establece a cero las referencias de orientaci´on. Establece las condiciones de inicio y monitoriza los bloques de control rotacional y el control de altura. Vuelo En el modo “Vuelo”se establecen cuatro modos que se diferencian en las referencias proporcionadas a la plataforma y, por tanto, en el tipo de trayectorias a marcar como referencia. Cada uno de estos estados incluye una funci´on de Simulink donde se obtienen las referencias incluidas como entradas externas. Modo 0. Estabilizaci´on Este modo proporciona referencias en posici´on y velocidades angulares, con el objetivo de mantener estable la plataforma en torno a unos valores fijos de los ´angulos que definen la orientaci´on. Se establece por defecto y adem´as, se debe pasar por ´el en cualquier transici´on entre los otros tres estados, como se comentar´a m´as adelante en la secci´on (Secci´on 3.1.2). Modo 1. Estabilizaci´on en altura Similar al modo anterior en cuanto a la estabilizaci´on de la plataforma, pero a˜nadiendo como grado de libertad adicional controlado la altura respecto al suelo. Permite el movimien- to en la direcci´on vertical proporcionando un valor de referencia zref , que puede ser una constante o una variable proporcionada por un generador de trayectorias que proporcione la referencia. Este bloque tambi´en puede ser aplicable a los dos siguientes modos. Modo 2. Movimiento en el plano En el modo 2 se mantiene constante la referencia de altura a la que se encuentra en Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) Figura 2: Modelo de la soluci´on. Se representan bloque de Stateflow (izq); bloques de control (centro); y representaci´on del modelo din´amico de la plataforma (dcha.) ese instante y se proporciona una referencia en posici´on en el plano XY, bien constante o proporcionada por el generador de trayectorias. En este caso dicho sistema definir´ıa una serie de waypoints que conformar´ıan la trayectoria deseada. Este bloque permite incluir algoritmos de planificaci´on de caminos que expanden las utilidades de la plataforma al aumentar su nivel de autonom´ıa. Modo 3. Movimiento en XYZ En el ´ultimo modo son proporcionadas referencias para los 6 grados de libertad de la plataforma, permitiendo un movimiento libre en el espacio tridimensional. Conserva las caracter´ısticas del modo 2 pero a˜nade la posibilidad de variar referencias en altura. Monitoriza y gestiona tanto los bloques de control rotacional como del control traslacional. 3.1.2. Transiciones Tierra - Aire Esta transici´on verifica la comunicaci´on con la estaci´on base, estado de sensores, voltaje de bater´ıas y enlace RC con la emisora, confirmando as´ı que todos los componentes est´an operativos y la plataforma est´a lista para volar de forma segura. Despegue - Vuelo Tiene como objetivo confirmar que el quadrotor ha despegado y se encuentra estable, comprobando que la altura es la de referencia establecida para este modo, y as´ı poder iniciar el estado Vuelo. Transici´on entre modos de vuelo El modo de vuelo es una variable externa introducida por el usuario y puede tomar valores consecutivos del 0 al 3. Aunque los cuatro modos de vuelo son independientes y tienen su propia l´ogica, para cambiar entre s´ı los modos “1”, “2” y “3” es necesario pasar primero por el estado “0” de “Estabilizaci´on”, con el fin de garantizar una transici´on segura en tiempo finito. Una vez verificada la estabilidad, se proceden a comprobar en cada caso los siguientes par´ametros mediante una funci´on denominada “ok”, que realiza las siguientes actuaciones seg´un el tipo de control seleccionado: 1. Control en altura. Se debe comprobar la veracidad de los valores del s´onar, as´ı como el margen entre la altura de referencia y la altura actual, para comprobar que es un movimiento realizable y seguro. 2. Control en posici´on. Deben verificarse la cobertura GPS, as´ı como los valores de referencia deseados y elaborar unos valores de transici´on entre el estado y la referencia para suavizar la trayectoria, en tiempo finito. El tipo de control en cada caso es el siguiente: •Transici´on 0 →1: Control en altura. •Transici´on 0 →2: Control en posici´on. •Transici´on 0 →3: Control en altura y en posici´on. Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) 3.2. Modelo din´amico El bloque denominado Quadrotor en la figura (Figura 2) recoge la implementaci´on del modelo din´amico de la plataforma presentada en la secci´on (Secci´on 2). La entrada al sistema, proporcionada por el bloque de control, se corresponder´a con los pares de actuaci´on (τa): τa=  τφa τθa τψa  =  `f2−`f4 `f3−`f1 κ((f1+f3)−(f2+f4))   (3) y el empuje total deseado, calculado como: T=Xfi, i = 1 . . . 4 (4) donde κrecoge diferentes par´ametros dependientes del motor y rotor seleccionados. Estas entradas son direccionadas al bloque denominado “Control Mixer”, encargado de convertir estos pares y empuje total en velocidades de giro de los rotores. La aplicaci´on de ´estos provocar´a la evoluci´on del vector de estados representado como: x=hx y z φ θ ψ ˙x ˙y ˙z ˙ φ˙ θ˙ ψi (5) Adicionalmente, pueden a˜nadirse modelos de perturbaciones externas, tales como viento o efecto suelo, mediante bloques propios que incluyan el modelado de estos efectos, o los propios del Aeroespace Toolbox. Figura 3: Representaci´on del diagrama principal de estados Stateflow y transiciones. 3.3. CONTROL El conjunto de bloques relativos al control est´an gobernados por la m´aquina de estados y proporcionan las se˜nales de actuaci´on a la plataforma para lograr las referencias deseadas. Si bien es un elemento clave en el dise˜no de la soluci´on global, para un primer desarrollo se ha optado por reutilizar controladores para plataformas de tipo VTOL disponibles en [6]. Consisten b´asicamente en controladores lineales en posici´on y velocidad (lineales y angulares), tanto para estabilizaci´on como para traslaci´on. Para un mayor detalle sobre la implementaci´on de las leyes de control, se refiere al lector a la referencia indicada. T´ıpicamente, debido a la din´amica de los subsistemas que conforman el modelo de este tipo de plataformas (Secci´on 2), la tarea del control se descompone en control rotacional y control longitudinal [4][5][15] (alternativamente de estabilizaci´on y traslaci´on). Bajo estas premisas, el modelo presentado en la figura (Figura 2) presenta esta descomposici´on, lo que permite implementar una l´ogica de gobierno de los diferentes bloques de control: En funci´on del modo de vuelo actual del sistema, la m´aquina de estados habilitar´a o no (se˜nal ENABLED) diferentes subsistemas. Por ejemplo, si el modo de vuelo establecido es “Estabilizaci´on”, el subsistema de control traslacional ser´a deshabilitado hasta nueva conmutaci´on. La interfaz que presentan los bloques de control, tanto al diagrama de estados como al modelo din´amico, es similar, independientemente de las leyes que est´en ejecutando (lineales, no lineales, por ejemplo). Esto permite la adici´on de nuevos bloques de control, sin modificar el dise˜no global (tan s´olo el subsistema al que afecte), para ser evaluados y verificados. Este detalle se puede observar en la figura (Figura 4). Pueden a˜nadirse tantos modos de control como se quiera, teni´endolos en cuenta en la l´ogica de Stateflow. Uno de los objetivos del dise˜no inicial era poder permitir una conmutaci´on en “caliente” entre las diferentes leyes de control. Tanto el usuario como el sistema, pueden, en cualquier momento y si el sistema lo cree conveniente, poder conmutar entre leyes de estabilizaci´on o traslaci´on. El bloque de control traslacional (Figuras 2,4) toma como referencia la posici´on (WξB ref ) y proporciona las referencias al control rotacional. Los Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) Figura 4: Subsistema de control traslacional. Se observa el detalle de la se˜nal ENABLE para poder simular la habilitaci´on de diferentes leyes de control en “caliente”. modos de vuelo que utilizan este tipo de control son el de “Movimiento en el plano” y “Movimiento en XYZ”. En el caso del control rotacional, se tiene como entrada la posici´on angular de referencia (proporcionada por el bloque de control traslacional o por el propio modo de vuelo en el bloque de Stateflow) y se obtienen como salida los pares correspondientes a cada ´angulo para realizar el movimiento. 4. SIMULACI ´ ON El objetivo principal de este trabajo era desarrollar una soluci´on para poder simular los diferentes estados l´ogicos por los que puede pasar el quadrotor, de manera segura. Los resultados de simulaci´on permiten evaluar diferentes aspectos de la soluci´on propuesta: evaluaci´on de las leyes de control, comportamiento ante perturbaciones, conmutaci´on entre diferentes estados, etc. 4.1. RESULTADOS INICIALES El hecho de utilizar Simulink permite un an´alisis inmediato de los resultados de simulaci´on mediante gr´aficas. A continuaci´on se muestran algunos de los resultados m´as interesantes. En la figura (Figura 5), puede observarse la evoluci´on temporal de los valores correspondientes de posici´on lineal y posici´on angular, y ser comparados con el modo de vuelo. La gr´afica se ha obtenido a partir de una simulaci´on de tsim = 40s, donde: Modo 0: Intervalo de simulaci´on: [0-10]s. Modo de vuelo “Estabilizaci´on”: Referencias en posici´on y orientaci´on a 0: WξB ref =01x3(m), WηB ref =01x3. El objetivo es mantener fijo el quadrotor en la posici´on final que alcanza despu´es del despegue. Modo 1: Intervalo de simulaci´on: [10-20]s. Modo de vuelo “Estabilizaci´on en altura”: Referencias en posici´on WξB ref = [0 0 8]>(m), y orientaci´on WηB ref = [0 0 0]>. Se proporciona una referencia fija en altura manteniendo la posici´on XY. Modo 2: Intervalo de simulaci´on: [20-30]s. Modo de vuelo “Movimiento en el plano XY”: Las referencias en posici´on se establecen como WξB ref = [−1,5−1,5z]>(m). Se conserva la altura del intervalo anterior y se proporciona una referencia para que la plataforma vuele en el plano. Modo 3: Intervalo de simulaci´on: [30-40]s. Modo de vuelo “Movimiento en el espacio XYZ”: Referencias en posici´on WξB ref = [1,5 1,5 4]>(m). La plataforma realiza una trayectoria 3D hacia un punto fijo de referencia. Figura 5: Evoluci´on temporal de las variables “Modo”, posici´on lineal y posici´on angular durante una simulaci´on 4.2. FLIGHTGEAR FlightGear [8] es un simulador de vuelo, de c´odigo abierto, que permite visualizar el vector de estado Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) de la plataforma de una forma gr´afica gracias a sus m´ultiples opciones de conexi´on con otro software. En este caso, se dispone del bloque “Flight- Gear Preconfigured 6DoF Animation” del Toolbox Aerospace Simulink, cuyas entradas son longitud, latitud, altitud, y posici´on angular (pitch, roll y yaw) (Figura 6(a)). Figura 6: FlightGear (a) Diagrama de conexionado necesario para visualizaci´on de resultados en el simulador, y (b) Esquema de conexi´on con la salida del sistema. FlightGear dispone de una gran variedad de modelos de aeronaves, tanto de ala fija como rotatoria, sin embargo no se ha encontrado un modelo nativo de quadrotor, por lo que se ha optado por disponer de un modelo de helic´optero que ilustra de forma similar la din´amica de ´este (Figura 7). Figura 7: Ejemplo de visualizaci´on de la evoluci´on de la plataforma con FlightGear. Para realizar la conexi´on de FlightGear y Simulink, es necesario colocar en el modelo un bloque denominado “Generate Run Script” (Figura 6(b)). Al abrir FlightGear y ejecutar este script, se sincronizan los datos de conexi´on por red y permite generar un archivo con extensi´on *.bat que servir´a de ejecutable para el FlightGear con las condiciones y par´ametros iniciales que se hayan indicado en el script [9]. 5. DESCRIPCI ´ ON HARDWARE 5.1. PLATAFORMA HW La plataforma hardware utilizada durante el desarrollo de este trabajo est´a basada en la soluci´on Arducopter [2]. M´as concretamente, la versi´on utilizada es la denominada APM 2.5, la cual contiene en una misma placa PCB tanto el microprocesador como todos los sensores relativos a la IMU (Inertial Measurement Unit) o unidad de medida inercial, y externo a la placa proporciona la antena receptora de se˜nal GPS modelo uBlox LEA-6H y el magnet´ometro. Para medir la altura respecto al suelo se utiliza un s´onar modelo MB1200. Salvo peque˜nas modificaciones, el software embebido proporciona el conjunto de medidas necesarias para la realimentaci´on sensorial (WηB) y permite el cierre del lazo de control de estabilizaci´on a 100 Hz. Para la obtenci´on de los datos necesarios para el cierre del lazo de posici´on (WξB), se utilizan en combinaci´on el sensor GPS, sensor de flujo ´optico y opcionalmente una c´amara. En ´este ´ultimo, es necesario adem´as la inclusi´on de una placa de hardware m´as potente que permita el procesamiento de informaci´on visual. Los motores empleados son t´ıpicos brushless, modelo T-Motor MT4006 de 740 RPM, los cuales, en funci´on del n´umero de celdas de la bater´ıa y la configuraci´on del rotor, proporcionar´an un empuje determinado. El control de estos motores se realiza mediante variadores de frecuencia (ESC- Electronic Speed Controller) de hasta 30 A, del fabricante T-Motor, que implementan un control de velocidad a bajo nivel y permiten env´ıo de referencia desde la placa de control a 400 Hz. A nivel de comunicaciones, se dispone de un enlace de telemetr´ıa de 433 Mhz del fabricante 3DRo- botics, el cual permite el env´ıo peri´odico de las diferentes variables necesarias para una monitorizaci´on permanente. Adicionalmente, se dispone de una emisora para conmutar entre los diferentes modos de vuelo, implementados en la m´aquina de estados, y para proporcionar referencias en funci´on del controlador activo en cada momento. 5.2. INTEGRACI ´ ON Una vez validada la soluci´on en Stateflow, se presenta como objetivo final y parte fundamental del proyecto su integraci´on con el hardware real Arduino descrito anteriormente. Adicionalmente, se desea que el trabajo propuesto sirva tanto de herramienta para investigaci´on como para docencia, especialmente en asignaturas relacionadas con el modelado de sistemas f´ısicos y de Control autom´atico. Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, Valencia ISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC) El hecho de que se haya probado en simulaci´on previa a su implementaci´on permite ahorrar tiempo de desarrollo, ya que las pruebas pueden hacerse en un ordenador, y no es necesaria la disponibilidad de la plataforma hasta el momento de la integraci´on. Para ello, se considerar´a como principal herramienta el Toolbox Real-Time Workshop R , que genera y ejecuta c´odigo C/C++ exportado de Simulink, Stateflow y las funciones del dise˜no, incluso para aplicaciones en tiempo real. Para programar la placa de control, existen dos opciones: bien desde el propio entorno de MATLAB, o bien importando el c´odigo anteriormente generado en el workspace del IDE gen´erico de Arduino [3] e integrando las diferentes funciones exportadas en el ejecutable principal. Es importante destacar que esta propuesta es compatible con otras plataformas VTOL. El procedimiento a seguir, para utilizar la propuesta actual en hardware de control diferente al planteado y otro modelo din´amico ser´ıa: Sustituci´on del modelo din´amico correspondiente a otro tipo de plataforma VTOL. Configurar adecuadamente las opciones de exportaci´on de c´odigo embebido en el Toolbox Real-Time Workshop R para la placa de control destino espec´ıfica. De manera opcional, es posible adem´as verificar el correcto funcionamiento del hardware destino del c´odigo exportado. Es lo que se conoce como “Hardware-in-the-loop”, y para el caso espec´ıfico de la plataforma Arducopter, existen librer´ıas (bloques “S-Function”) f´acilmente importables al entorno de desarrollo [10]. 6. CONCLUSIONES Y TRABAJOS FUTUROS Se ha presentado el dise˜no de una m´aquina basada en MATLAB Stateflow para la verificaci´on y validaci´on del software de control para un equipo rob´otico a´ereo y su integraci´on con plataformas embebidas de tiempo real. Este trabajo es una muestra de las m´ultiples opciones que dicha herramienta permite a la hora de introducir l´ogica de control en una plataforma de tipo quadrotor, aunque podr´ıa extenderse a otras configuraciones. Se han puesto de manifiesto las ventajas de utilizar la simulaci´on a la hora de desarrollar un proyecto de este tipo y la relativa simplicidad a la hora de a˜nadir nuevos bloques que permitan aumentar las funciones del sistema, como por ejemplo, a˜nadir distintas leyes de control y poder elegir en tiempo real cu´al es m´as conveniente usar, o incluso a˜nadir nuevas extensiones a la plataforma, como el control de un brazo manipulador externo, un giro-estabilizador para c´amaras o cualquier otro bloque de control de carga, por ejemplo. Una vez finalizado el desarrollo del proyecto se desea poder promover la utilizaci´on de esta librer´ıa para entornos acad´emicos bajo libre disposici´on. Agradecimientos Los autores desean expresar su agradecimiento al Ministerio de Econom´ıa y Competitividad (MINECO) por la financiaci´on de este trabajo, a trav´es de los proyectos DPI2012-37580-C02-02 y DPI2013- 44135-R. Del mismo modo, expresar nuestra mayor gratitud a Antonio Ventosa Cutillas por su inestimable colaboraci´on durante el desarrollo de este proyecto. Referencias [1] Asociaci´on espa˜nola de sistemas de vuelo pilotados de forma remota. http://www.aerpas.es/ [2] Plataforma Arducopter. http://copter.ardupilot.com/ [3] Plataforma Arduino. http://www.arduino.cc/ [4] Bouabdallah, S., Murrieri, P., y Siegwart, R., (2004) Design and Control of an Indoor Micro Quadrotor. En Proc. IEEE Int. Conf. on Rob. and Automat., volume 5, pp 4393–4398, New Orleans, USA. [5] Castillo, P., Lozano R., y Dzul, A.E., (2005) Modelling and Control of Mini-Flying Machines, Springer. [6] Corke, P., (2011) Robotics, Vision and Control. Fundamental Algorithms in MATLAB R , Springer. http:// petercorke.com/Robotics_Toolbox.html [7] Escareno, J., Rakotondrabe, M., Flores, G., y Lozano, R., (2013) Rotorcraft MAV having an onboard manipulator: longitudinal modeling and robust control, in European Control Conference (ECC). Z¨urich, Switzerland, pp 267- 269. [8] FlightGear flight simulator web page. Recurso electr´onico. http://www.flightgear.org/ [9] Conexi´on Flightgear con Simulink. Recurso electr´onico. http://www.mathworks.es/es/help/aeroblks/ working-with-the-flight-simulator-interface.html# f3-19707 [10] Hartley, W., (2012) APM2 Simulink Blockset. http://www.mathworks.com/matlabcentral/fileexchange/ 39037-apm2-simulink-blockset. [11] Lee, D., Chitrakaran, V., Burg, T., Dawson, D., y Xian, B., (2007) Control of a remotely operated quadrotor aerial vehicle and camera unit using a fly-the-camera perspective, in 46th IEEE Conference on Decision and Control, pp 6412-6417. [12] Markosian, L.Z., Mansouri-Samani, M., Mehlitz, P.C., y Pressburger, T., (2007) Program Model Checking Using Design-for-Verification: NASA Flight Software Case Study, Aerospace Conference, 2007 IEEE , vol.1, no.9, pp 3-10. [13] Parra-Vega, V., Sanchez, A., y Izaguirre, C., (2012) Toward force control of a quadrotor UAV in SE(3), on IEEE 51st Annual Conference Decision and Control (CDC), pp 1802-1809. [14] PVS Specification and Verification System. http://pvs. csl.sri.com/ [15] Raffo, G.V., (2011) Robust Control Strategies for a quadrotor helicopter. An underactuated mechanical system. Ph.D.Thesis, Engineering School. University of Seville. [16] Mathworks MATLAB Stateflow R .http://www. mathworks.es/products/stateflow/