verificacion y validaci on de sistemas de … · verificacion y validaci on de sistemas de control...

Actas de las XXXV Jornadas de Automática, 3-5 de septiembre de 2014, ValenciaISBN-13: 978-84-697-0589-6 © 2014 Comité Español de Automática de la IFAC (CEA-IFAC)

VERIFICACION Y VALIDACION DE SISTEMAS DECONTROL DE VUELO PARA MAV-VTOL BASADAS EN

MATLAB STATEFLOW

Pablo Rodrıguez1, Jesus G. Villagomez2, Manuel Vargas2, Francisco R. Rubio2

[email protected] , 2{villagomez, mvargas, rubio}@us.esDepartamento de Ingenierıa de Sistemas y Automatica, Universidad de Sevilla

Resumen

Se presenta el desarrollo de una solucion para laverificacion y validacion de sistemas de gobierno ycontrol de vuelo para pequenas plataformas de tipoVTOL (Vertical Take-Off and Landing). Para lasimulacion del vehıculo se dispone del correspon-diente modelo dinamico, que sera interconectadocon diferentes subsistemas de control de estabiliza-cion y posicion, gobernados por una maquina deestados definida en MATLAB Stateflow. El con-junto de simulaciones para la verificacion del di-seno de la solucion propuesta son llevadas a cabomediante Simulink. El objetivo es disponer de me-canismos que permitan evaluar el correcto funcio-namiento de prototipos antes de ser evaluados encondiciones reales.

Palabras clave: Arduino, Docencia, MATLABStateflow R©, Quadrotor, Simulacion.

1. INTRODUCCION

El uso de plataformas MAV-VTOL (MiniatureAutonomous Vehicle - Vertical Take Off and Lan-ding) [5] ha experimentado un notable crecimien-to en los ultimos tiempos. Bien para investigacioncomo para uso domestico, este tipo de vehıculosson ideales principalmente gracias a su bajo cos-te y al amplio conjunto de aplicaciones en las quepermite ser utilizado: desde vigilancia aerea has-ta transporte de carga. Su uso esta cada vez masextendido e incluso normativas de tipo legal estansiendo desarrolladas para poder legislar su aplica-cion futura en entornos urbanos [1]. En el ambitode la Academia, existen numerosos trabajos quecombinan el estudio de controladores para la es-tabilizacion y estimacion del estado [4][15], bienen interiores o exteriores, gracias a las posibili-dades de expansion sensorial que permiten estosvehıculos. La inclusion de sensores exteroceptivos(camaras, sensores de tipo laser, etc.) al sistemano es mas que una evolucion del mismo que permi-te posibilidades de navegacion autonoma, inclusoen entornos no estructurados. Trabajos recientesponen de manifiesto la capacidad de ampliacionfuncional e interaccion con el entorno que per-

miten estas plataformas, mediante la inclusion depequenos brazos manipuladores [7], actuadores decamara giro-estabilizados [11] o sensores de pre-sion y contacto para diferentes tipos de aplicacio-nes [13].

Sin embargo, la integracion de los diferentes sub-sistemas que conforman estas plataformas y suconfiguracion y adaptacion no es trivial. Comoplataforma aerea robotica, es imprescindible quela combinacion de software y hardware embarca-do funcione segun lo establecido, siendo robusto afallos de tipo sensorial o bien de perdida de comu-nicacion con el enlace de tierra, entre otros. En ca-so contrario, cualquier excepcion no contempladaen el desarrollo del software, derivara en un falloque provocarıa grandes desperfectos en la plata-forma y riesgos para terceros, con el consiguientecoste economico tanto de materiales como de ho-ras de trabajo. Por ello, la evaluacion del softwareembarcado antes de su uso es imprescindible parapoder detectar fallos de codificacion o situacionesno contempladas.

Las soluciones actuales, economicamente viables,que combinan hardware y software mas extendidasestan basadas en entornos de microprogramacionen lenguage C/C++ y hardware basado en Ar-duino, conocidas como Arducopter [2]. Periodica-mente la Comunidad aporta nuevas actualizacio-nes del firmware del dispositivo e incluye nuevasmejoras y funcionalidades. A nivel de investiga-cion, lo que se pretende es poder reutilizar partede estas aportaciones para poder avanzar en cam-pos como el control o la fusion sensorial, pudiendoacceder a cualquier elemento hw/sw del sistema ypoder reconfigurarlo, si fuera necesario. Si bien esuna plataforma muy extendida, no es posible unacomprobacion por simulacion del sistema, de talmanera que ante cualquier modificacion del codi-go fuente, o bien una reformulacion de la logica deaplicacion, la unica depuracion y verificacion posi-bles, incluyendo el comportamiento de los contro-ladores, es mediante el despegue de la plataformay comprobando que la evolucion de la misma noderiva en situaciones de inestabilidad. Para entor-nos como investigacion y docencia, son situacionesno admisibles.


Se hace por tanto imprescindible el desarrollo deentornos que permitan una simulacion completadel sistema para su verificacion, control de super-vision, planificacion de tareas, gestion de fallos yposterior validacion. Es lo que se conoce tıpica-mente como “Software-in-the-loop”: como maqui-na de estados que permite probar el comporta-miento del sistema ante cualquier entrada o eventoexterno, comprobando que la salida se correspondecon lo previamente disenado. Existen otras tecni-cas mas avanzadas de verificacion y validacion demodelos software: son las denominadas tecnicasbasadas en modelo o “Model checking” [12][14].Estas tecnicas estan basadas en logicas de tipomodal y descriptiva para la representacion del co-nocimiento y automatizacion del comportamiento.Son tecnicas que permiten una evaluacion exhaus-tiva del sistema. Sin embargo, graficamente no esposible ver su evolucion y a nivel academico sondifıciles de implantar a corto o medio plazo.

La solucion propuesta en este trabajo, para di-senar e implementar una maquina de control deestados e integrarla en una plataforma de ti-po quadrotor, esta basada en la combinacion deMATLAB Stateflow R© y el software de simula-cion MATLAB Simulink R©, muy extendido a ni-vel academico [16]. Stateflow es un entorno pa-ra el modelado y simulacion de logica de decisioncombinatoria y secuencial basado en maquinas deestado y diagramas de flujo. Permite la represen-tacion de diagramas de transicion de estado conel fin de modelar la evolucion del sistema anteeventos internos, externos o condiciones basadasen tiempo.

El desarrollo del presente trabajo queda estructu-rado como sigue: en la seccion 2 se presenta bre-vemente una descripcion del modelo dinamico dela plataforma utilizada para la experimentacion,de tipo quadrotor. Las secciones 3 y 4 presentanen detalle la solucion propuesta y diferentes alter-nativas para la representacion de las salidas delsistema, respectivamente. La seccion 5 explora lacapacidad de integracion del diseno propuesto enhardware real y las principales conclusiones y pro-puestas de trabajo futuro son presentadas en laseccion 6.

2. MODELADO DINAMICO

Uno de los puntos clave de la solucion propuestaes la modularidad que presenta. Es posible reutili-zar la misma maquina de estados para el gobiernode cualquier plataforma de tipo VTOL, intercam-biando el modelo dinamico del vehıculo bajo es-tudio y los controladores de estabilizacion y posi-cion correspondientes. Ası, en esta propuesta, seha utilizado el modelo dinamico correspondiente a

un vehıculo denominado quadrotor, con 4 motorescoplanarios.

Desde el punto de vista dinamico, un quadrotorconsiste en una masa puntual suspendida en el ai-re sobre la cual se aplican diferentes fuerzas y mo-mentos, combinando tan solo las velocidades delos diferentes rotores [4][5]. Para generar un movi-miento de balanceo o roll (angulo φ), se produceun desequilibrio entre las fuerzas f2 y f4 (Figura1). Analogamente, para un movimiento de cabeceoo pitch (angulo θ), el desequilibrio se realizara en-tre las fuerzas f1 y f3. El movimiento de guinada,o yaw (amgulo ψ), es resultado del desequilibrioentre los pares de fuerzas (f1,f3) y (f2,f4) produ-cidas por pares de motores que giran en sentidosopuestos. Como consecuencia de magnitudes po-sitivas en los angulos de balanceo y cabeceo, seproducen movimientos de tipo lateral y longitu-dinal, respectivamente, consiguiendo ası desplaza-mientos traslacionales. Desde el punto de vista delnumero de entradas manipulables y grados de li-bertad, el sistema se considera subactuado, de ma-nera que tan solo se dispone de 4 senales de actua-cion (motores f1...4) para controlar los 6 grados delibertad (orientacion y posicion) propios de un sis-tema aereo. El empuje total proporcionado por larotacion de los motores se obtendra como la sumade las fuerzas que ejercen los mismos.

Figura 1: Representacion de fuerzas y pares resul-tantes sobre la estructura de tipo quadrotor .

Bajo ciertas consideraciones [15], es posible plan-tear las ecuaciones que rigen la dinamica en dossubsistemas interconectados: traslacion (ecuacion1) y rotacion (ecuacion 2):

mξ +mge3 = fξ (1)

M(η)η + C(η, η)η = τη (2)

Los principales sistemas de coordenadas relevantesen el modelado son: sistema de referencia inercial,


supuesto fijo sobre la superficie de la Tierra, {W}(World coordinate frame), y el sistema {B} (Bodycoordinate frame), supuesto solidario al movimien-to del vehıculo. Se tiene que WξB = [x y z]> ∈ R3

representa la posicion del centro de rotacion delvehıculo, expresado en el marco de referencia iner-cial. WηB = [φ θ ψ]> ∈ R3 son los denomina-dos angulos de Tait-Bryan; fξ ∈ R3 son los fuer-zas aplicadas en cada eje; ` es la distancia en-tre el origen del sistema B y el eje de rotacionde cada motor (se asume estructura simetrica);τη ∈ R3 son los pares generados como consecuen-cia del desequilibrio de fuerzas; m es la masa delhelicoptero; g es el modulo de la aceleracion dela gravedad; M(η) ∈ R3×3 es la matriz de iner-cia; C(η, η) ∈ R3×3 es la matriz de Coriolis ye3 = [0 0 1]> ∈ R3.

3. DESCRIPCION DE LASOLUCION

Siguiendo una descripcion de tipo top-bottom, sedispone de tres elementos principales interconec-tados que componen la solucion propuesta: maqui-na de estados, o diagrama de Stateflow; bloques decontrol e implementacion del modelo dinamico dela plataforma (Figura 2).

3.1. DIAGRAMA STATEFLOW

El diagrama de Stateflow permite definir logica dedecision compleja en el control de la plataforma deforma grafica y estructurada, con el fin de simularla respuesta del sistema a entradas externas, even-tos y condiciones temporales. En esta propuesta,existen dos elementos principales para el diseno:estados y transiciones.

Los estados representan modos de funcionamien-to del sistema, que se ejecutan de forma exclu-siva o en paralelo. En estos se establecen valo-res para variables y se incluyen funciones relati-vas a la semantica de Stateflow, recurriendo a blo-ques externos que incluyen funciones de MATLABo diagramas de Simulink. Se organizan de formajerarquica y pueden relacionarse entre sı mediantetransiciones, que incluyen algun tipo de restric-cion o condicion y permiten gestionar el paso deun estado a otro.

3.1.1. Descripcion de los estados

Si bien la definicion de los diferentes estados noes unica, a continuacion se expone el conjuntomınimo de estados necesarios para recoger lalogica basica relativa a la evolucion de un VTOL,tanto en tierra como en el aire (Figura 3).

Tierra

Considerado como el estado inicial. Se establecepara comprobar y calibrar los distintos compo-nentes del quadrotor , tales como GPS, enlace RC,sonar, barometro, IMU, sensor de flujo optico. etc.Si se realiza correctamente, el sistema estara listopara realizar una transicion ante el evento “Volar”y conmutar al estado “Aire”.

Aire

El estado “Aire”se define desde que la plataformaesta disponible para iniciar el vuelo. A su vez sedescompone de los siguientes subsistemas:

Despegue El despegue es la fase siguienteal estado “Tierra”, y se encarga de propor-cionar referencias en altura para un despegueestable y coordinado de la plataforma, por loque ademas establece a cero las referenciasde orientacion. Establece las condiciones deinicio y monitoriza los bloques de control ro-tacional y el control de altura.

Vuelo En el modo “Vuelo”se establecen cua-tro modos que se diferencian en las referenciasproporcionadas a la plataforma y, por tanto,en el tipo de trayectorias a marcar como refe-rencia. Cada uno de estos estados incluye unafuncion de Simulink donde se obtienen las re-ferencias incluidas como entradas externas.

Modo 0. Estabilizacion

Este modo proporciona referencias en posi-cion y velocidades angulares, con el objetivode mantener estable la plataforma en tornoa unos valores fijos de los angulos que defi-nen la orientacion. Se establece por defectoy ademas, se debe pasar por el en cualquiertransicion entre los otros tres estados, comose comentara mas adelante en la seccion (Sec-cion 3.1.2).

Modo 1. Estabilizacion en altura

Similar al modo anterior en cuanto a la estabi-lizacion de la plataforma, pero anadiendo co-mo grado de libertad adicional controlado laaltura respecto al suelo. Permite el movimien-to en la direccion vertical proporcionando unvalor de referencia zref , que puede ser unaconstante o una variable proporcionada porun generador de trayectorias que proporcionela referencia. Este bloque tambien puede seraplicable a los dos siguientes modos.

Modo 2. Movimiento en el plano

En el modo 2 se mantiene constante la re-ferencia de altura a la que se encuentra en


Figura 2: Modelo de la solucion. Se representan bloque de Stateflow (izq); bloques de control (centro); yrepresentacion del modelo dinamico de la plataforma (dcha.)

ese instante y se proporciona una referenciaen posicion en el plano XY, bien constanteo proporcionada por el generador de trayec-torias. En este caso dicho sistema definirıauna serie de waypoints que conformarıan latrayectoria deseada. Este bloque permite in-cluir algoritmos de planificacion de caminosque expanden las utilidades de la plataformaal aumentar su nivel de autonomıa.

Modo 3. Movimiento en XYZ

En el ultimo modo son proporcionadas refe-rencias para los 6 grados de libertad de laplataforma, permitiendo un movimiento libreen el espacio tridimensional. Conserva las ca-racterısticas del modo 2 pero anade la posi-bilidad de variar referencias en altura. Moni-toriza y gestiona tanto los bloques de controlrotacional como del control traslacional.

3.1.2. Transiciones

Tierra - Aire

Esta transicion verifica la comunicacion conla estacion base, estado de sensores, voltajede baterıas y enlace RC con la emisora, con-firmando ası que todos los componentes estanoperativos y la plataforma esta lista para vo-lar de forma segura.

Despegue - Vuelo

Tiene como objetivo confirmar que el quadro-tor ha despegado y se encuentra estable, com-probando que la altura es la de referencia es-tablecida para este modo, y ası poder iniciarel estado Vuelo.

Transicion entre modos de vuelo

El modo de vuelo es una variable externa in-troducida por el usuario y puede tomar valo-res consecutivos del 0 al 3. Aunque los cua-tro modos de vuelo son independientes y tie-nen su propia logica, para cambiar entre sı losmodos “1”, “2” y “3” es necesario pasar pri-mero por el estado “0” de “Estabilizacion”,con el fin de garantizar una transicion segu-ra en tiempo finito. Una vez verificada la es-tabilidad, se proceden a comprobar en cadacaso los siguientes parametros mediante unafuncion denominada “ok”, que realiza las si-guientes actuaciones segun el tipo de controlseleccionado:

1. Control en altura. Se debe comprobar laveracidad de los valores del sonar, ası co-mo el margen entre la altura de referen-cia y la altura actual, para comprobarque es un movimiento realizable y segu-ro.

2. Control en posicion. Deben verificarse lacobertura GPS, ası como los valores dereferencia deseados y elaborar unos valo-res de transicion entre el estado y la re-ferencia para suavizar la trayectoria, entiempo finito.

El tipo de control en cada caso es el siguiente:

• Transicion 0→ 1: Control en altura.

• Transicion 0→ 2: Control en posicion.

• Transicion 0→ 3: Control en altura y enposicion.


3.2. Modelo dinamico

El bloque denominado Quadrotor en la figura(Figura 2) recoge la implementacion del modelodinamico de la plataforma presentada en la seccion(Seccion 2). La entrada al sistema, proporcionadapor el bloque de control, se correspondera con lospares de actuacion (τ a):

τ a =

τφa

τθaτψa

=

`f2 − `f4

`f3 − `f1

κ((f1 + f3)− (f2 + f4))

(3)

y el empuje total deseado, calculado como:

T=∑

fi, i = 1 . . . 4 (4)

donde κ recoge diferentes parametros dependien-tes del motor y rotor seleccionados. Estas entradasson direccionadas al bloque denominado “ControlMixer”, encargado de convertir estos pares y em-puje total en velocidades de giro de los rotores.La aplicacion de estos provocara la evolucion delvector de estados representado como:

x =[

x y z φ θ ψ x y z φ θ ψ]

(5)

Adicionalmente, pueden anadirse modelos de per-turbaciones externas, tales como viento o efectosuelo, mediante bloques propios que incluyan elmodelado de estos efectos, o los propios del Aero-espace Toolbox.

Figura 3: Representacion del diagrama principalde estados Stateflow y transiciones.

3.3. CONTROL

El conjunto de bloques relativos al control estangobernados por la maquina de estados y propor-cionan las senales de actuacion a la plataformapara lograr las referencias deseadas. Si bien es unelemento clave en el diseno de la solucion global,para un primer desarrollo se ha optado por reutili-zar controladores para plataformas de tipo VTOLdisponibles en [6]. Consisten basicamente en con-troladores lineales en posicion y velocidad (linea-les y angulares), tanto para estabilizacion comopara traslacion. Para un mayor detalle sobre laimplementacion de las leyes de control, se refiereal lector a la referencia indicada.

Tıpicamente, debido a la dinamica de los subsis-temas que conforman el modelo de este tipo deplataformas (Seccion 2), la tarea del control sedescompone en control rotacional y control lon-gitudinal [4][5][15] (alternativamente de estabili-zacion y traslacion). Bajo estas premisas, el mo-delo presentado en la figura (Figura 2) presentaesta descomposicion, lo que permite implementaruna logica de gobierno de los diferentes bloques decontrol:

En funcion del modo de vuelo actual delsistema, la maquina de estados habilitara ono (senal ENABLED) diferentes subsistemas.Por ejemplo, si el modo de vuelo estableci-do es “Estabilizacion”, el subsistema de con-trol traslacional sera deshabilitado hasta nue-va conmutacion.

La interfaz que presentan los bloques de con-trol, tanto al diagrama de estados como almodelo dinamico, es similar, independiente-mente de las leyes que esten ejecutando (li-neales, no lineales, por ejemplo). Esto permi-te la adicion de nuevos bloques de control, sinmodificar el diseno global (tan solo el sub-sistema al que afecte), para ser evaluados yverificados. Este detalle se puede observar enla figura (Figura 4). Pueden anadirse tantosmodos de control como se quiera, teniendolosen cuenta en la logica de Stateflow.

Uno de los objetivos del diseno inicial era po-der permitir una conmutacion en “caliente”entre las diferentes leyes de control. Tanto elusuario como el sistema, pueden, en cualquiermomento y si el sistema lo cree conveniente,poder conmutar entre leyes de estabilizaciono traslacion.

El bloque de control traslacional (Figuras 2,4) to-ma como referencia la posicion (WξB

ref ) y pro-porciona las referencias al control rotacional. Los


Figura 4: Subsistema de control traslacional. Seobserva el detalle de la senal ENABLE para po-der simular la habilitacion de diferentes leyes decontrol en “caliente”.

modos de vuelo que utilizan este tipo de controlson el de “Movimiento en el plano” y “Movimientoen XYZ”.

En el caso del control rotacional, se tiene comoentrada la posicion angular de referencia (propor-cionada por el bloque de control traslacional o porel propio modo de vuelo en el bloque de Stateflow)y se obtienen como salida los pares correspondien-tes a cada angulo para realizar el movimiento.

4. SIMULACION

El objetivo principal de este trabajo era desarro-llar una solucion para poder simular los diferentesestados logicos por los que puede pasar el quadro-tor , de manera segura. Los resultados de simu-lacion permiten evaluar diferentes aspectos de lasolucion propuesta: evaluacion de las leyes de con-trol, comportamiento ante perturbaciones, conmu-tacion entre diferentes estados, etc.

4.1. RESULTADOS INICIALES

El hecho de utilizar Simulink permite un analisisinmediato de los resultados de simulacion median-te graficas. A continuacion se muestran algunos delos resultados mas interesantes. En la figura (Fi-gura 5), puede observarse la evolucion temporalde los valores correspondientes de posicion linealy posicion angular, y ser comparados con el modode vuelo. La grafica se ha obtenido a partir de una

simulacion de tsim = 40s, donde:

Modo 0: Intervalo de simulacion: [0-10]s. Modode vuelo “Estabilizacion”: Referencias en po-sicion y orientacion a 0: WξB

ref = 01x3 (m),WηB

ref = 01x3. El objetivo es mantener fijoel quadrotor en la posicion final que alcanzadespues del despegue.

Modo 1: Intervalo de simulacion: [10-20]s. Mo-do de vuelo “Estabilizacion en altura”: Refe-rencias en posicion WξB

ref = [0 0 8]> (m), yorientacion WηB

ref = [0 0 0]>. Se proporcio-na una referencia fija en altura manteniendola posicion XY.

Modo 2: Intervalo de simulacion: [20-30]s. Mo-do de vuelo “Movimiento en el plano XY”:Las referencias en posicion se establecen comoWξB

ref = [−1,5 −1,5 z]> (m). Se conserva laaltura del intervalo anterior y se proporcionauna referencia para que la plataforma vueleen el plano.

Modo 3: Intervalo de simulacion: [30-40]s.Modo de vuelo “Movimiento en el espacioXYZ”: Referencias en posicion WξB

ref =[1,5 1,5 4]> (m). La plataforma realiza unatrayectoria 3D hacia un punto fijo de referen-cia.

Figura 5: Evolucion temporal de las variables“Modo”, posicion lineal y posicion angular duran-te una simulacion

4.2. FLIGHTGEAR

FlightGear [8] es un simulador de vuelo, de codigoabierto, que permite visualizar el vector de estado


de la plataforma de una forma grafica gracias asus multiples opciones de conexion con otro soft-ware. En este caso, se dispone del bloque “Flight-Gear Preconfigured 6DoF Animation” del ToolboxAerospace Simulink, cuyas entradas son longitud,latitud, altitud, y posicion angular (pitch, roll yyaw) (Figura 6(a)).

Figura 6: FlightGear (a) Diagrama de conexiona-do necesario para visualizacion de resultados enel simulador, y (b) Esquema de conexion con lasalida del sistema.

FlightGear dispone de una gran variedad de mo-delos de aeronaves, tanto de ala fija como rotato-ria, sin embargo no se ha encontrado un modelonativo de quadrotor , por lo que se ha optado pordisponer de un modelo de helicoptero que ilustrade forma similar la dinamica de este (Figura 7).

Figura 7: Ejemplo de visualizacion de la evolucionde la plataforma con FlightGear.

Para realizar la conexion de FlightGear y Simu-link, es necesario colocar en el modelo un blo-que denominado “Generate Run Script” (Figura6(b)). Al abrir FlightGear y ejecutar este script,se sincronizan los datos de conexion por red y per-mite generar un archivo con extension *.bat queservira de ejecutable para el FlightGear con lascondiciones y parametros iniciales que se hayanindicado en el script [9].

5. DESCRIPCION HARDWARE

5.1. PLATAFORMA HW

La plataforma hardware utilizada durante el desa-rrollo de este trabajo esta basada en la solucionArducopter [2]. Mas concretamente, la version uti-lizada es la denominada APM 2.5, la cual contieneen una misma placa PCB tanto el microprocesa-dor como todos los sensores relativos a la IMU(Inertial Measurement Unit) o unidad de medidainercial, y externo a la placa proporciona la ante-na receptora de senal GPS modelo uBlox LEA-6Hy el magnetometro. Para medir la altura respectoal suelo se utiliza un sonar modelo MB1200.

Salvo pequenas modificaciones, el software embe-bido proporciona el conjunto de medidas necesa-rias para la realimentacion sensorial (WηB) y per-mite el cierre del lazo de control de estabilizaciona 100 Hz. Para la obtencion de los datos necesariospara el cierre del lazo de posicion (WξB), se utili-zan en combinacion el sensor GPS, sensor de flujooptico y opcionalmente una camara. En este ulti-mo, es necesario ademas la inclusion de una placade hardware mas potente que permita el procesa-miento de informacion visual.

Los motores empleados son tıpicos brushless, mo-delo T-Motor MT4006 de 740 RPM, los cuales,en funcion del numero de celdas de la baterıa yla configuracion del rotor, proporcionaran un em-puje determinado. El control de estos motores serealiza mediante variadores de frecuencia (ESC-Electronic Speed Controller) de hasta 30 A, delfabricante T-Motor , que implementan un controlde velocidad a bajo nivel y permiten envıo de re-ferencia desde la placa de control a 400 Hz.

A nivel de comunicaciones, se dispone de un enla-ce de telemetrıa de 433 Mhz del fabricante 3DRo-botics, el cual permite el envıo periodico de lasdiferentes variables necesarias para una monito-rizacion permanente. Adicionalmente, se disponede una emisora para conmutar entre los diferentesmodos de vuelo, implementados en la maquina deestados, y para proporcionar referencias en fun-cion del controlador activo en cada momento.

5.2. INTEGRACION

Una vez validada la solucion en Stateflow, se pre-senta como objetivo final y parte fundamental delproyecto su integracion con el hardware real Ar-duino descrito anteriormente. Adicionalmente, sedesea que el trabajo propuesto sirva tanto de he-rramienta para investigacion como para docen-cia, especialmente en asignaturas relacionadas conel modelado de sistemas fısicos y de Control au-tomatico.


El hecho de que se haya probado en simulacionprevia a su implementacion permite ahorrar tiem-po de desarrollo, ya que las pruebas pueden hacer-se en un ordenador, y no es necesaria la disponibi-lidad de la plataforma hasta el momento de la inte-gracion. Para ello, se considerara como principalherramienta el Toolbox Real-Time Workshop R©,que genera y ejecuta codigo C/C++ exportado deSimulink, Stateflow y las funciones del diseno, in-cluso para aplicaciones en tiempo real. Para pro-gramar la placa de control, existen dos opciones:bien desde el propio entorno de MATLAB, o bienimportando el codigo anteriormente generado enel workspace del IDE generico de Arduino [3] e in-tegrando las diferentes funciones exportadas en elejecutable principal.

Es importante destacar que esta propuesta es com-patible con otras plataformas VTOL. El procedi-miento a seguir, para utilizar la propuesta actualen hardware de control diferente al planteado yotro modelo dinamico serıa:

Sustitucion del modelo dinamico correspon-diente a otro tipo de plataforma VTOL.

Configurar adecuadamente las opciones deexportacion de codigo embebido en el Tool-box Real-Time Workshop R© para la placa decontrol destino especıfica.

De manera opcional, es posible ademas verificarel correcto funcionamiento del hardware destinodel codigo exportado. Es lo que se conoce como“Hardware-in-the-loop”, y para el caso especıfi-co de la plataforma Arducopter, existen librerıas(bloques “S-Function”) facilmente importables alentorno de desarrollo [10].

6. CONCLUSIONES YTRABAJOS FUTUROS

Se ha presentado el diseno de una maquina basa-da en MATLAB Stateflow para la verificacion yvalidacion del software de control para un equiporobotico aereo y su integracion con plataformasembebidas de tiempo real. Este trabajo es unamuestra de las multiples opciones que dicha he-rramienta permite a la hora de introducir logicade control en una plataforma de tipo quadrotor ,aunque podrıa extenderse a otras configuraciones.Se han puesto de manifiesto las ventajas de utilizarla simulacion a la hora de desarrollar un proyectode este tipo y la relativa simplicidad a la hora deanadir nuevos bloques que permitan aumentar lasfunciones del sistema, como por ejemplo, anadirdistintas leyes de control y poder elegir en tiem-po real cual es mas conveniente usar, o inclusoanadir nuevas extensiones a la plataforma, comoel control de un brazo manipulador externo, un

giro-estabilizador para camaras o cualquier otrobloque de control de carga, por ejemplo. Una vezfinalizado el desarrollo del proyecto se desea po-der promover la utilizacion de esta librerıa paraentornos academicos bajo libre disposicion.

Agradecimientos

Los autores desean expresar su agradecimiento alMinisterio de Economıa y Competitividad (MINE-CO) por la financiacion de este trabajo, a traves delos proyectos DPI2012-37580-C02-02 y DPI2013-44135-R. Del mismo modo, expresar nuestra ma-yor gratitud a Antonio Ventosa Cutillas por suinestimable colaboracion durante el desarrollo deeste proyecto.

Referencias

[1] Asociacion espanola de sistemas de vuelo pilotados de for-ma 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) De-sign and Control of an Indoor Micro Quadrotor. En Proc.IEEE Int. Conf. on Rob. and Automat., volume 5, pp4393–4398, New Orleans, USA.

[5] Castillo, P., Lozano R., y Dzul, A.E., (2005) Modellingand Control of Mini-Flying Machines, Springer.

[6] Corke, P., (2011) Robotics, Vision and Control. Fun-damental 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 EuropeanControl Conference (ECC). Zurich, Switzerland, pp 267-269.

[8] FlightGear flight simulator web page. Recurso electronico.http://www.flightgear.org/

[9] Conexion Flightgear con Simulink. Recurso electroni-co. 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 aerialvehicle and camera unit using a fly-the-camera perspec-tive, 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 CheckingUsing Design-for-Verification: NASA Flight Software Ca-se Study, Aerospace Conference, 2007 IEEE , vol.1, no.9,pp 3-10.

[13] Parra-Vega, V., Sanchez, A., y Izaguirre, C., (2012) To-ward force control of a quadrotor UAV in SE(3), on IEEE51st Annual Conference Decision and Control (CDC), pp1802-1809.

[14] PVS Specification and Verification System. http://pvs.csl.sri.com/

[15] Raffo, G.V., (2011) Robust Control Strategies for a qua-drotor helicopter. An underactuated mechanical system.Ph.D.Thesis, Engineering School. University of Seville.

[16] Mathworks MATLAB Stateflow R©. http://www.mathworks.es/products/stateflow/

verificacion y validaci on de sistemas de … · verificacion y validaci on de sistemas de control...

Documents