Equation Chapter 1 Section 1 Proyecto Fin de Grado Grado en Ingeniería de Tecnologías Industriales Desarrollo de un entorno Harware in the Loop para el AirWhale. Autor: Elena Manga Caballero Tutor: Daniel Limón Marruedo Dep. Ingeniería de Sistemas y Automática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2015
95
Embed
Proyecto Fin de Grado Grado en Ingeniería de …bibing.us.es/proyectos/abreproy/90473/descargar_fichero/...iii Proyecto Fin de Grado Grado en Ingeniería de las Tecnologías Industriales
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Equation Chapter 1 Section 1
Proyecto Fin de Grado
Grado en Ingeniería de Tecnologías Industriales
Desarrollo de un entorno Harware in the Loop para
el AirWhale.
Autor: Elena Manga Caballero
Tutor: Daniel Limón Marruedo
Dep. Ingeniería de Sistemas y Automática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2015
iii
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías Industriales
Desarrollo de un entorno Harware in the Loop para
el AirWhale.
Autor:
Elena Manga Caballero
Tutor:
Daniel Limón Marruedo
Profesor titular
Dep. de Ingeniería de Sistemas y Automática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2015
v
Proyecto Fin de Grado: Desarrollo de un entorno Harware in the Loop para el AirWhale.
Autor: Elena Manga Caballero
Tutor: Daniel Limón Marruedo
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2015
El Secretario del Tribunal
vii
ix
Agradecimientos
Este proyecto de final de grado no solo incluye las horas de trabajo y el esfuerzo por parte del autor que lo ha
realizado, sino también muchas preocupaciones y sueños intranquilos por parte de una familia siempre muy
unida a susodicho. Es por ello que sin querer acudir a tópicos, pero sin poder evitarlo, me es necesario
agradecer a mi familia el cariño y apoyo que siempre me han brindado. No sólo para este proyecto con el que
me graduaré como ingeniera, sino por esos cuatro años que han estado conmigo cuando suspendí, cuando
aprobé, cuando lloré y sobre todo, cuando reí.
A mis niñas que han estado ahí desde hace tantos años que ni recuerdo qué era de mi vida antes de conocerlas.
Sabéis tan bien como yo todo lo que hemos pasado. Una de las cosas de las que más me enorgullezco es de
tener unas amigas únicas como vosotras, con las que sé que siempre puedo contar si lo necesito.
Paco, has sido una constante para mí estos cuatro años, siempre dispuesto a escuchar las tonterías de esta
sensiblera y a animarla a seguir. No sé como has aguantado pero seguro que tú tampoco sabes cuanto lo
agradezco.
A todos aquellos que siempre creyeron en mí incluso más que yo misma, a todos esos amigos que intentaban
sacarme de casa para animarme y no se cansaban de intentarlo, aunque todos sabemos que no era fácil. Por
todos los apuntes, los consejos, los oídos y los abrazos que siempre estaban ahí cuando lo necesitaba.
Ingenieros en papel o no, hoy os graduais conmigo.
A mi tutor, Daniel, por estar ahí siempre que ha podido, sacando tiempo incluso de donde no lo había para
conseguir que esto funcionara. Capaz de contagiarme de tranquilidad incluso cuando lo veía todo negro. No
podría haber elegido un tutor mejor.
A mis compañeros de EsiTech con esas ganas de sacar adelante el proyecto fuera como fuere y en especial a
Alejandro por su gran capacidad de trabajo en equipo y por ser tan buen compañero. Gracias chicos.
Todos aquellos que os sabéis mencionados en estas palabras, muchas gracias simplemente por estar.
xi
Resumen
El proyecto AirWhale se basa en la creación de un nuevo híbrido formado por la combinación entre un
vehículo multirotor y un dirigible. Su objetivo es sacar lo mejor de ambos y mejorarlo. En este documento se
incluirá una breve introducción al proyecto AirWhale y se hará mención especial a todos aquellos que han
trabajado en él para conseguir siga adelante.
La creación de una nueva aeronave es un proyecto muy ambicioso que tiene detrás un estudio extenso de la
materia. De la teoría a la práctica siempre hay un gran salto que con frecuencia no es fácil de dar. Para facilitar
las cosas, en este proyecto se intenta crear un escalón intermedio entre ambas, un entorno muy semejante a la
práctica pero dentro del marco teórico.
El proyecto que este documento contiene es el desarrollo de un entorno virtual que simulará en la medida de lo
posible el comportamiento el AirWhale. Para obtener dicho entorno se han estudiado varios caminos a seguir
como bien se explicará en estas páginas.
xiii
Abstract
The AirWhale project consists in the creation of a new hibrid by the combination of a multirotor vehicle and
an airship. Its goal is to take the best out of them and improve it. In this document a brief introduction to the
AirWhale project will be included and everyone who worked to carry it out.
Creating a new aircraft is a very ambitious project backed by an extensive study of the subject. There is always
a great leap from theory to practice, usually not easy to make. In order to make things easier, in this project the
creation of an intermediate step is intended, an environment very close to practice but inside the theoretical
framework.
The project in this document is the development of a virtual environment that simulates the aircraft to be
designed as best as possible. To obtain this environment several ways have been explored, as it will be
En esta sección se definen la localización y la orientación de los motores y las hélices así como los
tanques de los que se alimentan. En el siguiente apartado se entrará más en detalle sobre los tipos de
motores y hélices disponibles en JSBSim.
Los motores vienen definidos en archivos aparte incluidos en el directorio engine y en esta sección se
debe declarar el archivo que corresponde a los motores de esta aeronave.Además de localizar los
motores, es necesario definir el tanque de alimentación del motor para tener en cuenta la variación de
combustible en vuelo. En el ejemplo declaramos un tanque “0” de FUEL que alimentará al motor
AirWhale_engine. El tanque “0” es un caso particular ya que no es necesario su uso pero si su
definición, esto se explicará en el apartado Motores.
Ejemplo 3-4
<propulsion>
<engine file="AirWhale_engine">
<location unit="IN">
<x> 98.92 </x>
<y> -13.12 </y>
<z> -40.00 </z>
</location>
<orient unit="DEG">
<pitch> 0.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
Estudio Previo
24
</orient>
<feed>0</feed>
<thruster file="direct">
<location unit="IN">
<x> 98.92 </x>
<y> -13.12 </y>
<z> -40.00 </z>
</location>
<orient unit="DEG">
<pitch> 0.00 </pitch>
<roll> 0.00 </roll>
<yaw> 0.00 </yaw>
</orient>
</thruster>
</engine>
<tank type="FUEL" number="0">
<location unit="IN">
<x> 98.92 </x>
<y> 0.00 </y>
<z> -3.20 </z>
</location>
<capacity unit="LBS"> 0.11 </capacity>
<contents unit="LBS"> 0.06 </contents>
</tank>
</propulsion>
Aerodynamics o aerodinámica
En esta sección se definen todas las fuerzas y momentos que influyen a la aeronave. Esta sección
junto con el control de vuelo son las más complejas del FDM. En ella intervienen una gran cantidad
de funciones y aunque se tiene una estructura general de la sección, no es tan simple como las
anteriores. Haciendo uso de las funciones necesarias, en esta sección se especifican la fuerza o el
momento total para cada uno de los tres ejes los tres ejes traslacionales (LIFT | DRAG | SIDE ó X |
Y | Z ó AXIAL | NORMAL | SIDE) y los tres rotacionales (PITCH | ROLL | YAW).
Control de vuelo y definición del sistema
Aquí se definirán los actuadores y sensores con los que cuente la aeronave así como las leyes de
control de la misma. Es posible tener en cuenta las zonas muertas de los actuadores.
En JSBSim se pueden incluir de forma relativamente sencilla filtros, integradores, condicionales,
sumar o multiplicar componentes así como se facilita la implantación de controladores PIDs.
25
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Buoyance o flotabilidad
JSBSim permite incorporar a la aeronave células de gas puramente de hidrógeno, helio o aire.
También es posible incluir globos compensadores de aire para controlar la presión del gas y los
momentos debido al aire que pueden almacenar. Esta sección no es necesaria en vehículos aéreos que
no aplique.
Considerando la célula de gas como un elipsoide, se localiza el centro de la misma y sus dimensiones.
También es necesario saber la plenitud inicial de la célula en un rango de 0 a 1, especificar la relación
máxima de presión con respecto a la atomsférica y la capacidad de la válvula.
Se considerará el calor transmitido transmitido al gas para el comportamiento del mismo así como se
necesitarán las funciones que modelen el comportamiento del gas en el interior de la célula.
Reacciones externas
Aquí se incluyen todas las reacciones no definidas a priori de la aeronave. Un ejemplo de reacción
externa podría ser el aire que absorbe un dirigible para aumentar peso y disminuir altura. En dicho
caso, sería necesario localizar el punto donde se encuentra la válvula y se definirá la fuerza que realiza
ejerce el aire obtenido sobre la aeronave.
Comunicación por puerto IP
JSBSim da la posibilid de realizar una conexión por puerto IP con otros programas o aplicaciones. Se
deberán especificar los datos a transmitir. En el envío de datos es posible elegir el protocolo de envío
UDP o TCP así como a qué tipo de conexión está orientado y la frecuencia de muestreo.
Es posible establecer distintas conexiones con diferentes puertos transmitiendo datos dispares.
3.2.2.3 Motores
JSBSim da a elegir entre los cinco tipos distintos de motores que incorpora según cual se aproxime más al
empleado en el vehículo a representar.
Motor de combustión interna. Este motor convierte la energía química de un combustible
directamente en energía mecánica. La combustión se produce en el interior de la máquina, típicamente
dentro de un cilindro tapado por un piston que transmitirá la energía mecánica en un movimiento de
traslación. Este movimiento de traslación se convertirá a rotacional. Para un vehículo aéreo, JSBSim
da la posibilidad a este tipo de motor de generar el movimiento por medio de hélices de dos tipos: de
sustentación, como las de los helicópteros, llamadas ROTOR, o las que dan movimiento a un fluido
como pueden ser las que incluye un simple ventilador.
Motor eléctrico. Este motor genera energía mecánica a partir de la energía eléctrica. La corriente a la
que se somete la máquina crea un campo magnético que induce un movimiento rotatorio. La
propulsión de estos motores puede ser la dada directamente por el motor o incluyendo hélices de
rotación como en el caso del motor de combustión interna.
En JSBSim no se considera la energía consumida por el motor eléctrico ya que no se han incluído aún
baterías en el programa. Para incorporar este tipo de motores será necesario asociarles un tanque de
combustible simbólico definido con el fin de que el programa no detecte error en código.
Motor de cohete. Esta máquina produce el movimiento gracias al empuje que genera la expulsión de
gases de la cámara de combustión a través de una tobera. En JSBSim las toberas únicamente son
Estudio Previo
26
empleadas con este tipo de motores y es necesario modelarlas.
Turbina. Este tipo de máquinas obtiene la energía de un fluido para luego transformarla en energía
mecánica. En este motor no es necesario definir ningún tipo de propulsor ya que la turbina de por sí ya
genera el flujo de fluido necesario para el movimiento.
Turbohélice. Este motor cuenta con un eje a través del cual se transmite la rotación a las hélices que
generarán elmovimiento. La energía se obtiene de los gases de combustión antes de su expulsión. En
esta máquina es posible emplear el mismo tipo de hélice con las que cuenta el motor de combustión
interno.
3.3 HIL en MATLAB
MATLAB (MATrix LABoratory) es una herramienta matemática muy
potente con lenguaje de programación propio. Este programa tiene muchas
y muy diversas utilidades para el ámbito de la investigación. La Escuela
Superior de Ingenieros de la Universidad de Sevilla en la actualidad
dispone de una licencia acedémica para este programa y la gran mayoría
de sus alumnos cuentan con conocimientos básicos del mismo. Entre otras
cosas, ese es uno de los motivos por lo que se eligió como herramienta
definitiva para realizar el HIL tras descartar la opción de obtener el FDM
para FlightGear con el modelo en JSBSim.
MATLAB cuenta con la posibilidad de realizar la conexión por puerto serie
necesaria para la comunicación con APM además del poder de cálculo necesario para trabajar con el modelo y
facilidades para la simulación.
Para la realización de este proyecto, se plantea como objetivo desarrollar un HIL en SIMULINK, un entorno
de bloques para simulación que ofrece una interfaz en MATLAB capaz de implementar algoritmos y de
importar y exportar datos. Los archivos en el entorno de bloques que es SIMULINK se guardan en memoria
en un tipo de extensión propia, SLK.
En MATLAB se tiene el modelo matemático de la aeronave mientras que el control lo realizará APM. El
bucle de control se cierra con la comunicación entre el software y la plataforma, el envío/recibo de datos se
realiza por puerto serie en paquetes de datos.
Realizando el HIL en SIMULINK será necesario contar con paquetes que se encarguen de la transmisión y
tratamiento de datos. Por falta de material, no se ha realizado la comunicación a tiempo real sino que se han
ajustado los tiempos de muestreo para minimizar el retardo.
Ilustración 3-9 – Logotipo de
MATLAB
Posición y orientación
Actuaciones Posición y orientación
3-10 – Esquema de HIL con
MATLAB
27
Desarrollo de un entorno Harware in the Loop para el AirWhale.
El modelo se encargará de interpretar las actuaciones para obtener el estado de la aeronave, ese estado incluye
las posiciones y orientación de la misma. Ese estado que proporcionará el modelo será el que cerrará el bucle
de control una vez enviado al APM por puerto serie.
Por otro lado, por protocolo UDP MATLAB mandará lo necesario para definir la posición de la aeronave que
son las coordenadas en longitud, latitud, z y los ángulos ψ, θ, Φ. La dirección IP a emplear viene dada por
defecto y será 127.0.0.1.
El modelo del sistema se incluirá en un subsistema en el que, como se verá en capítulos posteriores, se
realizará el tratamiento que se requiera sobre las actuaciones para simular el comportamiento de la aeronave.
Estudio Previo
28
29
Desarrollo de un entorno Harware in the Loop para el AirWhale.
4 COMUNICACIÓN POR
PUERTO SERIE
n lo relevante a la comunicación, como cualquier emisor haría antes de enviar un mensaje, es necesario
informarse del idioma en el que se desenvuelve el receptor para así conseguir una correcta comprensión
del lenguaje. Aún a nivel informático, no olvidamos las bases de la comunicación y antes de entablar
una relación entre los implicados, se estudia cómo tratan cada uno de ellos la transmisión y recepción de
mensajes.
Nuestra placa de control será una plataforma APM 2.6 como bien se ha explicado con anterioridad y cuenta
con una serie de librerías especiales para la comunicación. Como antes se ha destacado, para una mayor
comprensión del firmware de APM, se recomienda acceder al proyecto de final de grado del alumno Alejandro
Romero Galán [6]. La función que emplearemos para la comunicación, mandará por puerto serie una cadena
de caracteres en código ASCII que el receptor del mensaje tendrá que interpretar. En dicha función, como se
acostumbra en C, se definirá el tipo en el que se enviará como cadena de caracteres para el envío de datos.A
continuación se incluirá la función de envío tal y como se codifica en APM. La terminación ‘LF’ (\n) o retorno
de carro no es necesario añadirla para una comunicación por puerto serie pero siempre es conveniente definir
un terminador para maor seguridad en el envío de un dato o paquete de datos.
hal.console->printf("%f \n", Dato_enviado);
Por el contrario, la función empleada para leer los datos que llegarán a la plataforma almacenará un número
comprendido entre 0 y 255 por cada dato que se mande. Almacena lo que recibe como un carácter entero de 8
bits. Dichas función será la siguiente:
Dato_recibido = hal.console->read();
Para comenzar, se empezó a estudiar la comunicación con APM a través del puerto serie por defecto del
software de Arduino modificado para esta plataforma. Dicho puerto serie recibe y envía carácter a carácter
cualquier dato introducido por teclado en código ASCII en una variable de 8 bits. Para interpretar los datos
numéricos que recibe ArduPilot se podrá integrar en el código la porción de código incluida en el
E
El mayor problema de la comunicación es la ilusión con
la que se ha logrado.
- George Bernard Shaw -
Comunicación por puerto serie
30
Anexo A.
Un punto a destacar es el tiempo de “arranque” del puerto serie. Una vez se abre el puerto, APM tarda un
tiempo en comenzar una comunicación fluida. Este tiempo de arranque puede estar comprendido entre 0.02 y
10 segundos. Este tiempo de arranque se hará en la primera lectura por puerto serie de la información enviada
por APM.
Una vez familiarizados con la comunicación por el serial de Arduino, se dará un paso adelante hacia nuestro
objetivo y se comenzará a transmitir datos entre la plataforma y MATLAB.
Matlab cuenta con una serie de funciones orientadas a la comunicación por puerto serie. Por orden de uso la
primera función se te tiene es serial que recibe el nombre del puerto USB al que estará conectada la placa.
Durante la realización de este proyecto se ha empleado el puerto USB ‘COM3’ por lo que la función quedará:
APM=serial(‘COM3’);
Una vez llamada a la función, se almacenará en el workspace la variable APM de tipo serial que identifica
dicho puerto serie. Dentro de la misma función es posible definir propiedades del puerto. Por defecto,
MATLAB considerará la velocidad de baudios o Baudrate como 9600 que es el valor más típicamente
empleado, sin embargo, APM2.6 trabaja a una velocidad de 115200. Para identificar el puerto de
comunicación serie con 115200 de Baudrate se podrá llamar a la función serial de la siguiente forma:
APM=serial('COM3','BaudRate',115200);
También es posible cambiar las propiedades con la función:
set('BaudRate',115200)
Una vezdefinido el puerto, se abrirá para la transmisión de mensajes con la función fopen.
En caso de que todo lo anterior no funcione, es conveniente comprobar si MATLAB reconoce algún puerto
serial conectado por USB, para ello se puede escribir “instrfind” en la ventana de comandos. Las funciones a
emplear en MATLAB para la comunicación serán fwrite para la escritura y fscanf para la lecura.
Ya abierto el puerto, se irán dando pequeños pasos hasta conseguir la transmisión final que cuenta con
paquetes de 6 datos en un mismo envío. El primer pequeño paso será mandar un dato entero desde APM y ver
que se recibe bien. Se comprobará que la recepción de datos será análoga a la que se produce por el puerto
serie de Arduino. Por ello se utilizará la función str2num para convertir la cadena ASCII en un vector de
números flotantes.
Por otro lado, gran sorpresa al encontrar que al recibir datos enteros que MATLAB ha enviado anteriormente,
APM recibe dos enteros diferentes. Después de varias pruebas se llegó a la conclusión de que por cada entero
que MATLAB envía, APM recibirá dos int8 que simbolizan los siguiente:
Resto de la división por el número de veces que
supera 255.
Número de veces que se supera 255
De esta forma si envío un dato “TOTAL” recibiré a y b siendo:
31
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Una vez comprendida la mecánica de la transacción se realizarán pruebas sobre los tiempos de envío
fácilmente se pueden hacer programas (siempre uno en MATLAB y otro en APM que realiza lo que se desea)
paramedir los tiempos de envíos que se realizarán. La siguiente imagen muestra los resultados de una prueba
en la que MATLAB mandará una recta dato a dato, entre los envíos leerá lo que APM responde que deberá ser
el mismo dato enviado y lo almacenará. En esta prueba se muestra el tiempo, en el eje x, frente a los datos
recibidos, en el eje y. Se intenta demostrar que los tiempos de respuesta en la comunicación no está
determinado a priori, dependen del tiempo de cómputo de APM que puede ser variable y de lo que MATLAB
tarde en leer por el serial. Se recomienda que dicha lectura no sea de información valiosa al ser posible que se
mezcle con lo que pueda que se encuentre en el puerto serie en ese momento.
Ilustración 4-1 – Retrasos en la transmisión
Claramente se observan saltos temporales cuando el tiempo de cómputo es mayor que la media. La pendiente
de esta recta debería de ser constante pero como se puede observar, por los tiempos no lo es.
Es necesario añadir que al comienzo, en la comunicación APM recibía valores distintos de los enviados que en
caso de estar trabajando con la placa, inestabilizarían el sistema. La Ilustración 4-2 muestra la respuesta frente
al tiempo de APM ante un envío constante de 1500. El status de envío en rojo, indica que el problema no está
en el recibo ya que los datos se reciben bien en MATLAB, pero no se reciben o envían bien desde APM.
Ilustración 4-2 – Comunicación fallida
Para solucionar esto se pondrá una espera mínima de 5 milisegundos entre cada lectura de valor por puerto
serie de APM.
Comunicación por puerto serie
32
33
Desarrollo de un entorno Harware in the Loop para el AirWhale.
5 SISTEMA CONTROLADO
e simulará el modelo de la planta con controladores discretos en ArduPilot para obtener la respuesta del
sistema ante una entrada en referencia. Se realizará un script del modelo que se explicará más adelante en
el capítulo 0. Dicho script contempla la relación dinámica en función de la configuración geométrica de
los actuadores del AirWhale y se podrá encontrar en el Anexo B. Esta simulación servirá como referencia a la que se realizará en simulink. Como ya se comentó, se darán
pequeños pasos para llegar a nuestro final por lo que se seguirá un orden de trabajo para llegar hasta el HIL tal
y como lo deseamos.
Ilustración 5-1-Pasos a seguir
La simulación del modelo en script en MATLAB no tiene en cuenta los posibles retrasos en la comunicación
que anteriormente se ha visto. Esto es así porque el tiempo de muestreo que toma el controlador y el tiempo de
muestreo del sistema a nivel de cálculo son el mismo. En el momento en el que el sistema recibe una acción de
control, calculará el estado para el siguiente instante de muestreo, haya o no haya pasado ese tiempo en la
realidad. El controlador recibirá el estado, tardará el tiempo pertinente en los cálculos de las acciones de
control, 59.4ms de media, y las devolverá al modelo. En este marco de simulación, no se tendrá en cuenta el
tiempo de cálculo ya que realmente, el único tiempo que “avanza” es el de integración del modelo que es igual
al tiempo de muestre.
Controlar modelo en script desde MATLAB
Controlar el modelo en script de MATLAB
desde APM
Controlar el sistema en simulink desde APM visualizando
inmediatamente la respuesta del sistema.
S
Comparación
Comparación
Sistema controlado
34
En la Ilustración 5-2 – Esquema de comunicación se muestra un esquema de cómo sería la comunicación
anteriormente mencionada considerando la línea inferior azul el ArduPilot.
Considerando esto, la respuesta del sistema no deberá verse afectada por el retraso en la transmisión siempre y
cuando suceda dicha transmisión.
En caso de normalizar los datos transmitidos, puede que resulte contradictorio empleando un PID pero se
estabilizará con un error en régimen permanente Ese error tiene una explicación lógica. Los datos transmitidos
estarán normalizados en función del rango de trabajo. Dado que trabajamos con ángulos en grados, el rango de
trabajo se considera [0 360] y la trasmisión admite [0 65535]. Es por ello que la normalización se hará
considerando que 360º corresponden a un envío de un dato por valor de 65535. Teniendo esto en cuenta, la
resolución con la que se trabaja será de 1*360/65535 que es una resolución de 0.0055 grados. Este valor sería
el error en régimen permanente que presenta la Ilustración.
5.1 Controlador en MATLAB
Ahora se compararán los datos obtenidos empleando el mismo controlador en la plataforma APM y en
MATLAB. El modelo que se usará será el mismo y la única diferencia en código será la transmisión del
estadoa la plataforma y el recibo de las acciones de control frente al controlador implementado en MATLAB.
En la siguiente imagen se expondrán los resultados obtenidos controlando únicamente el ángulo θ para
obtener una referencia de 0.5º.
Ilustración 5-2 – Esquema de comunicación
xk
Modelo en Funcionamiento Modelo en Funcionamiento Modelo en Funcionamiento
xk xk uk uk uk
Tm Tm
35
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Ilustración 5-3 – Seguimiento en referencia del ángulo θ
Como se puede observar, las formas que tomarán las curvas serán las mismas siendo más suave con el
controlador implementado en APM. Para evitar cualquier fallo de código, se ha intentado replicar lo más
fielmente posible el controlador de la plataforma en un script.
Tras realizar varios experimentos con resutlados similares se ha estudiado en qué momento de la prueba se ha
realizado algún cálculo de manera diferente para resultar de esta forma. En un principio, como es lógico se
achacó a un fallo en la comunicación. Los datos recibidos por APM se han analizado devolviéndolos a
MATLAB y se ha comprobado que ahí no radica el error. Comprobada la transmisión y la similitud de los
controladores únicamente queda como respuesta el tratamiento que la plataforma haga a los datos.
Es posible que internamente el controlador realice cálculos que necesiten de mayor precisión que la que puede
aportar APM2.6.
Cuando el sistema controlado por matlab se inestabiliza, también lo hará el controlado por la plataforma y
viceversa pero siempre como en la imagen anterior, más suavemente.
5.2 SIMULINK
SIULINK no permite obtener de Workspace una variable serial ya declarada ni trabajar la comunicación por
puerto serie en funciones, por lo que tendremos que cambiar los métodos hasta ahora usados de transmisión.
SIMULINK sí dispone, sin embargo, de una serie de bloques especiales para la comunicación por puerto serie
en tiempo de simulación, Serial Receive, Serial Send y Serial Configuration mostrados en la siguiente imagen.
El primer bloque será el encargado de recibir datos. APM manda carácter a carácter por lo que se deberá leer
en int8 un número determinado de caracteres. Se ha llegado ha llegado a un compromiso entre emisor y
receptor en el que APM mandará los datos en punto flotante. De esta forma, cada dato recibido por Serial
Receive tendrá un tamaño fijo de 8 bits. En esta emisión no se empleará terminador ya que el final del paquete
acaba a los n*8 bits que se proponga recibir. Al mismo tiempo, no se deben incluir espacios o comas entre los
0 1 2 3 4 5 60
1
2
3
4
5
6
7
8
tiempo en segundos
Ángulo
s e
n g
rados
Theta controlado en Mátlab
Theta controlado en APM
1 2 3 4 5 6 7-10
-5
0
5
10
15
20
25
30
tiempo en segundos
Ángulo
s e
n g
rados
actuación del controlador en apm
actuacion del controlador en matlab
Sistema controlado
36
números enviados desde APM. Las salidas de este bloque deberán convertirse a números flotantes por medio
de una función incluída en el Anexo C. Dicho bloque necesitará además el tiempo de muestreo con el que trabajamos porque de ello dependerá el
tiempo de actualización de los actuadores, cuando lea la entrada por puerto serie.
A su vez, en caso de que por cualquier motivo, dicho bloque no reciba datos, el status de dicho bloque
señalizará 0. Se empleará un mantenedor también incluído en el Anexo D.
para que no se actualice a 0 el valor de salida ya que en simulación esto podría inestabilizar la aeronave.
Ilustración 5-4 – Bloques de Serial en SIMULINK
Por otro lado, el bloque de Serial Receive emplea el tiempo de muestreo heredado. No es capaz de enviar en
tiempo continuo y si se intenta enviar una señal de tal calibre, genera errores. Para evitar errores siempre es
conveniente poner un bloque conversor con el tiempo de muestreo que se desee. Este bloque además se
empleará porque los datos que se enviarán a APM seguirán siendo uint16 como hasta ahora.
El último bloque, Serial Configuration define las propiedades del puerto que como ya comentamos será la
velocidad en baudios, de 115200.
El mayor problema de la comunicación con simulink será el retraso acumulado. A diferencia de simular en
script, simulink no para la simulación porque no reciba un dato, simplemente mantiene en el tiempo y retrasa
el recibo,aumentando el tiempo de ejecución del bloque. Además también hay que considerar que cada bloque,
tanto de envío como de recibo se ejecutará en serie, nunca en paralelo, un motivo de peso para la acumulación
de retrasos en función del tiempo que tarde cada bloque. En la ilustración 5.5 se muestran los resultados de las
pruebas realizadas en relación a dicho retraso.
37
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Ilustración 5-5 - – Acumulación de Retraso en Simulink
Dicha prueba consiste en mandar desde simulink las actuaciones de los dos actuadores laterales y APM
únicamente reanviará el paquete recibido. Como se puede observar, a medida que avanza el tiempo, la línea de
los datos recibidos y enviados se distancia, esto se traduce a que el retraso en la comunicación se acumula y
aumenta lentamente.
Simulink también cuenta con una desventaja y es que cuando ejecuta un bloque, para el tiempo y deja de
contar hasta que finaliza la ejecución y vuelve a contar desde el instante en el que se paró. Esto a la hora de
sincronizarnos con programas externos a MATLAB como FlightGear es problemático por lo que se añadirá un
bloque de OPC que obliga a SIMULINK a una vez finalizada la ejecución de un bloque, sumar al tiempo
contado, el tiempo de ejecución de dicho bloque.
El archivo de simulink en el que se probarán las simulaciones tendrá la siguiente estructura:
Sistema controlado
38
Ilustración 5-6 – Modelo encapsulado del AirWhale en SIMULINK
El código implementado en APM para realizar el control y la comunicación ha sido realizado en conjunto con
el compañero de equipo Alejandro Romero Galán. Dicho código se incluirá en la memoria en el Anexo E. Se han realizado ensayos con simulink pero no se ha llegado a a un resultado satisfactorio. Como antes se veía,
existía un retraso en la comunicación que afecta al sistema. Es posible implementar el bucle de control en
simulink pero se acumulará el retraso y el sistema no funcionará correctamente. Teniendo en cuenta que el
sistema sin control se hace inestable, durante el tiempo de “arranque” del bloque serial, cuando el sistema
recibe únicamente “0” lo estamos dejando libre de realizar cualquier acción inesperada.
Aún así, se han obtenido resultados satisfactorios para una entrada al sistema desde APM como en la
Ilustración 5.5, pero no para el sistema en bucle cerrado de control. No se ha conseguido implementar el
control en SIMULINK correctamente.
39
Desarrollo de un entorno Harware in the Loop para el AirWhale.
6 MODELO
L modelo de la aeronave debe integrar todas las acciones necesarias para convertir las actuaciones
enviadas por el controlador a estado. Para ello es necesario contar con un modelo matemático del
sistema que proporcione la información necesaria.
El modelo del que se dispone lo han realizado Alejandro Romero Galán y Jose Luis Holgado Álvarez cuyos
proyectos se encuentran en las referencias de este documento. Este modelo únicamente contempla la
posibilidad de vuelo o caída, en ningún momento es posible mantenerse estático.
Las salidas del modelo son en metros para las coordenadas relativas al punto inicial y en ángulos para Φ, θ y ψ.
Hay que tener en tener en cuenta que el eje z apunta hacia tierra desde la aeronave en posición normal por lo
que para trabajar con dicha variable será necesario invertirla.
Por otra parte, este modelo trabaja con fuerzas en x y z además de con momentos en x, y, z. Las actuaciones
son sobre los rotores que según la velocidad de giro ejercerán una fuerza determinada en la dirección a la que
apunten. Es por esto que será necesario encontrar la relación entre la posición geométrica de los mismos y las
fuerzas en x y en z que comprende el modelo.
Esa fuerza no es la que proporciona el controlador ya que éste únicamente envía la señal en PWM tal y como
la reciben los actuadores. Aquí nos vemos con la necesidad de añadir una etapa más al modelo completo, y es
la conversión de PWM a fuerza.
También debemos tener en cuenta que los actuadores tiene un límite físico que pueden alcanzar por lo que se
limitará la señal en PWM.
La Ilustración 6-1 muestra el esquema de las etapas que incluirá el modelo completo del sistema.
Ilustración 6-1 – Diagrama de bloques del modelo encapsulado
6.1 Saturación
Los actuadores tienen una capacidad máxima que deberemos modelar en el HIL. Esto se entiende como la
saturación máxima permitida. Actualmente únicamente se tienen datos de los rotores por lo que no se
emplearán los servos. Mientras esto siga así, consideraremos en este bloque la entrada del servomotor como un
PWM de igual rango de trabajo que el de los rotores.
E
Modelo
40
El PWM máximo que permiten los variadores será de 2000 mientras que el mínimo será 0. Sin embargo,
experimentalmente se ha obtenido que los rotores laterales no empiezan a ejercer fuerza hasta un PWM mayor
de 1000, por lo que la aeronave real reaccionará igual ante una entrada a los actuadores de 1000 o de 0 de
PWM.
6.2 Conversión PWM a fuerza en Newton
El modelo de rotores seleccionados no tiene información suficiente sobre esta relación por lo que se realizarán
una serie de pruebas para obtenerla. Dandole escalones en PWM a los rotores y pesándolos somos capaces de
obtener la relación PWM con peso que disminuye. Con la gravedad como única aceleración a la que están
sometidos los rotores una vez estabilizados, se puede obtener la fuerza que proporciona cada PWM con la
Segunda Ley de Newton.
Se han obtenido tres puntos para la relación que son los que se muestran en la Tabla 6-1.
Tabla 6-1. Puntos experimentales de la relación PWM-Fuerza
PWM Peso en kg que sustenta Fuerza en Newton equivalente
considerando la gravedad 9.81m/s2
0 0 0
1200 0 0
1500 0.5 4.905
2000 0.8 7.848
Para obtener estos datos, se han dado escalones en PWM al prototipo del AirWhale de 2kg de peso y cuatro
rotores. Los rotores son iguales a los que se emplearán en el AirWhale, con un máximo de sustentación de
800g por actuador. Los alternadores acotan de 0 a 2000 la salida en PWM.
A partir de 1200 de PWM se empieza a levantar peso pero únicamente se sustentará el peso total de la
estructura y se levantará a 1500.
Obtendremos una curva de primer orden que pase por dichos puntos tal y como se muestra en la Ilustración
6-2.
41
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Ilustración 6-2 – Relación Fuerza-PWM
Actualmente no se están empleando servos por lo que la acción de control sobre los mismos es nula. No
podemos obtener la relación ángulo-entrada a los servomotores al no disponer aún de los mismos de estos para
hacer ensayos. Se hará la conversión como si se tratase de otro rotor.
En el Anexo A se incluye la función que se encargará de transformar los datos recibidos en PWM a Fuerza.
6.3 Conversión de fuerzas reales a normalizadas
Los actuadores reales del AirWhale son cuatro rotores y dos servomotores. Los rotores están posicionados de
la siguiente forma: dos traseros para el movimiento longitudinal y dos laterales para la sustentación. Los dos
servomotores varían el ángulo de inclinación en el plano XZ de los rotores traseros para facilitar el control del
cabeceo.
Estos actuadores serán los que controlará APM, sin embargo, el modelo toma como entradas las fuerzas en x,
y junto con los momentos para x,y,z (fx, fx, mx, my, mz). A estas actuaciones las llamaremos actuaciones
normalizadas. Esto genera la necesidad de convertir las actuaciones reales a normalizadas. Esta conversión se
realizará considerando las variables de las dimensiones mostradas en la Ilustración 6-3.
0 200 400 600 800 1000 1200 1400 1600 1800 20000
1
2
3
4
5
6
7
8
PWM
Fuerz
a
Modelo
42
Ilustración 6-3 – Actuadores del AirWhale
Considerando que estando los servos a cero grados, los rotores traseros quedan alineados con el eje X, al girar
el servo, el ángulo aumenta en sentido contrario a Z, hacia arriba de la aeronave. Teniendo esto en cuenta, la
relación de actuadores reales a normales es inmediata.
La relación de momentos es algo que podemos intuir para así comprobar la correcta obtención de las
ralaciones matemáticas.
Considerando que las alas no están en el eje Y, los rotores laterales generan un momento en dicho eje que
provocan cabeceo, pero esta influencia en el ángulo de cabeceo no nos permite el control del mismo con
dichos actuadores pero sí lo hacen los rotores traseros.
El ángulo de guiñada, únicamente se puede controlar con los actuadores traseros.
Por otro lado, como es de esperar, los rotores laterales incluyen en el alabeo y los traseros también gracias
debido a los servomotores.
Lo ideal sería que este HIL también sirviera para simular la respuesta de los los sensores tomando como
aeronave la construida por los compañeros del equipode automática. Dicha aeronave cuenta con cuatro rotores
en cruz además de los dos traseros. La posición y orientación de dichos rotores se muestra en la A
continuación se incluyen las ecuaciones pertinentes para dicho prototipo, en el modelo encapsulado,
únicamente sería necesario sustituir las ecuaciones anteriores por las siguientes.
Y0
X0 z0
43
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Ilustración 6-4 – Esquema del prototipo del AirWhale
Modelo
44
45
Desarrollo de un entorno Harware in the Loop para el AirWhale.
7 VISUALIZACIÓN
l paquete Aerospace Blockset de simulink incluye bloques de animación para la simulación en vuelo.
Existen bloques que cuentan con la comunicación directa con FlightGear, resuelta vía UDP. Estos bloques
envían la posición y orientación de la aeronave a FlightGear, que únicamente lo muestra de forma visual.
La Ilustración 7-1 muestra el bloque que se usará para la transmisión de datos desde MATLAB 2013 a
FlightGear. Actualmente MATLAB 2015 acepta las versiones
La siguiente aeronave será un avión comercial de la compañía Boeing. El modelo 737-200, más reducido que
el que verán a continuación, es el más empleado en una de las compañías low cost de vuelo más polémicas que
hay en la actualidad y de la que probablemente hayan oído hablar, Ryanair.
Este modelo en 3D lo han realizado Innis Cunningham (3D), Heiko Schulz (3D and panel) a los que como
como se ha comentado anteriormente, no se desea restar méritos en su trabajo. La aeronavecomo se verá en
FlightGear está muy conseguida.
Ilustración 9-1 – Zeppelin NT
Ilustración 9-2 – Boeing 737-300
53
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Por último se incluirá el modelo del cohete HL20 cuyo copyright pertenece a MathWorks,Inc.Esta nave
espacial fue desarrollada por la NASA que no llegó a lanzarse.
Ilustración 9-3 – HL-20
Ilustración 9-4 – Sencilla interfaz para elegir aeronave y llamar a FlightGear
Interfaz inicial
54
55
Desarrollo de un entorno Harware in the Loop para el AirWhale.
FUTURAS MEJORAS
Hay personas a quienes les gustan los retos, también hay ingenieros a los que no les gustan, pero son casos
aislados. Personalmente yo siento más satisfacción consiguiendo algo en lo que me he esforzado que algo que
me ha sido dado con facilidad y con la finalización de este proyecto siento que me queda pendiente de
realizar.
Este proyecto no ha podido dar todo los frutos que podría haber hecho como el lector puede pensar tras
haberlo leído. Es complicado contabilizar el trabajo realizado en la realización del mismo debido a todos los
callejones sin salida encontrados, que no han aportado al contenido final. El proyecto comenzó con mucha
ilusión por parte de esta alumna y ha ido cambiando en el transcurso del tiempo. Por falta de recursos no se ha
podido investigar más afondo ciertos temas para dejarlos zanjados y es por ello que este proyecto tiene un
frente abierto de mejoras muy amplio. Entre otros, habría que investigar la razón de por qué el control en APM
es distinto al realizado en MATLAB con códigos análogos. A esta cuestión se le ha dedicado un tiempo de
estudio considerable sin encontrar respuesta alguna más que la comentada en capítulos anteriores
Es una desilusión que el HIL final implementado en SIMULINK no quede para su inmediato uso y esta
alumna no se siente satisfecha por que el mismo no vaya a quedar reflejado en esta memoria de proyecto
aunque seguirá trabajando en conseguirlo.
Como ya se ha comentado anteriormente y se ha ido comentando durante el documento, hay varias mejoras a
realizar a este proyecto. Los caminos que creo serían los más correctos seguir acontinuación en la línea del
proyecto aparte de los comentados en este mismo capítulo serían entre otros:
Sincronización a tiempo real. El fin del HIL es la simulación en timpo real tal y como si fueran los
sensores de los que recibo los datos. SIMULINKtiene configuraciones especiales para trabajar a
tiempo real con las que habría que trabajar para conseguir una correcta sincronización sin cúmulo de
retrasos.
Crear alguna especie de interfaz en MATLAB o incluso dentro de SIMULINK capaz de variar los
parámetros del sistema mientras se simula y los waypoints del planificador.
Como citas de autores en este mismo proyecto he mencionado a Napoleón Bonaparte con citas que bien sin
saber que eran suyas siempre me han gustado. Una de ellas es la del capítulo tres que dice así: “El éxito no está
en vencer sino en no desanimarse nunca”. Con esto quiero decir que puede que en el período de realización de
este proyecto no se haya conseguido todo lo planeado en su comienzo.Tal y como se ha avanzado cuando se
encontraban obstáculos, se seguirá avanzando tras la entrega de este documento.
FUTURAS MEJORAS
56
57
Desarrollo de un entorno Harware in the Loop para el AirWhale.
ANEXO A
//Interpretar caracteres de datos numéricosrecibidos por puerto serie en APM
uint16_t a[10];
while(1)
{
i=0;
hal.console->printf("Mete un numero");
while(!hal.console->available()){
hal.scheduler->delay(5);
}
while(hal.console->available()){
a[i] = hal.console->read();
i++;
}
i=i-1;
for (cons=0; cons<=i; cons++){
b=b+pow(10,(i-cons))*float(a[cons]-48);
}
Anexo A
58
59
Desarrollo de un entorno Harware in the Loop para el AirWhale.
ANEXO B
El valor de b (b[]) viene definido en la función empleada pero no se incluirá en el anexo por contar con 500
valores que se pueden observar fácilmente en la Ilustración 6-2.
%Función que transforma PWM en Fuerza function [f1,f2,f3,f4,f5,f6] = fcn(F1,F2,F3,F4,F5,F6) b=[];
if F1=<1201 f1=0; else f1=b(F1-1200); end
if F2=<1201 f2=0; else f2=b(F2-1200); end
if F3=<1201 f3=0; else f3=b(F3-1200); end
if F4=<1201 f4=0; else f4=b(F4-1200); end
if F5=<1201 f5=0; else f5=b(F5-1200); end
if F6=<1201 f6=0; else f6=b(F6-1200); end
Anexo B
60
61
Desarrollo de un entorno Harware in the Loop para el AirWhale.
ANEXO C
% Función para convertir un número double dado en caracteres ASCII a double.
function y = fcn(u)
[M,N]=size(u); p=1; numero=zeros(uint8(M/8),1); ent=numero; dec=numero; if u(1)==0 else for i=1:8:(M-7) coma=0; entero=[0 0 0 0 0 0 0]; decimal=[0 0 0 0 0 0]; for j=0:7 if u(j+i)==46 coma=j+1; end for j=1:coma-1 entero(7-coma+j+1)=double(u(i+j-1)-48); end end
if coma>0 for j=coma:7 decimal(j-coma+1)=double(u(i+j)-48); end
end diez=[1000000 100000 10000 1000 100 10 1]; ent(p)=entero*diez'; div=[0.1 0.01 0.001 0.0001 0.00001 0.000001 0.0000001]; dec(p)=decimal*div'; numero(p)=ent(p)+dec(p); p=p+1; end end y = numero;
Anexo C
62
63
Desarrollo de un entorno Harware in the Loop para el AirWhale.
ANEXO D
%%Función mantenedora de valores anteriores recibidos para cuando se produce
una lectura insatisfactoria del puerto serie
function y = fcn(status,anterior,actual) if status==0 y=anterior; else y=actual; end
Anexo D
64
65
Desarrollo de un entorno Harware in the Loop para el AirWhale.