View
6
Download
0
Category
Preview:
Citation preview
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
explained in the following pages.
xv
Índice
Agradecimientos ix
Resumen xi
Abstract xiii
Índice xv
Índice de Tablas xvii
Índice de Figuras xix
Notación xxi
1 Instrucción 1 1.1 ESITECH 1 1.2 Proyecto AirWhale 3
1.2.1 Participación en el concurso de Fly Your Ideas 5
2 Equipo Automático 10 2.1 División del trabajo 11 2.2 Placa de control 11
3 Estudio Previo 13 3.1 Mission Planner 14 3.2 Simulador de vuelo 15
3.2.1 FlightGear 15 3.2.2 JSBSim 16
3.3 HIL en MATLAB 26
4 Comunicación por puerto serie 29
5 Sistema controlado 33 5.1 Controlador en MATLAB 34 5.2 SIMULINK 35
6 Modelo 39 6.1 Saturación 39 6.2 Conversión PWM a fuerza en Newton 40 6.3 Conversión de fuerzas reales a normalizadas 41
7 Visualización 45 7.1.1 Configuración de FlightGear para simulación 46 7.1.2 Tratamiento de datos para usarlos en la visualización 47
8 Planificador de trayectoria 49
9 Interfaz inicial 51
FUTURAS MEJORAS 55
Anexo A 57
Anexo B 59
Anexo C 61
Anexo D 63
Anexo E 65
Referencias 75
xvii
Índice de Tablas
Tabla 3-1. Sistema de medidas en JSBSim 19
Tabla 4-1. Puntos experimentales de la relación PWM-Fuerza 40
xix
Índice de Figuras
Ilustración 1-1 – Logo de EsiTech 2
Ilustración 1-2 – Grupos de trabajo de EsiTech 2
Ilustración 1-3 – Organigrama de la organización 3
Ilustración 1-4- Primer prototipo del AirWhale 4
Ilustración 1-5- Prototipo intermedio AirWhale 4
Ilustración 1-6- Prototipo final del AirWhale 5
Ilustración 1-7 – Portada del equipo en para la segunda fase del concurso de FYI 6
Ilustración 2-1 – Esquema de trabajo del equipo automático 10
Ilustración 2-2- Placa ArduPilot Mega 2.6 12
3-1 – Esquema de HIL con MP 14
Ilustración 3-2 – Logotipo de Mission Planner 14
Ilustración 3-3 – Elección Waypoints en Mission Planner 15
Ilustración 3-4- Logotipo actual de FlightGear 15
Ilustración 3-5 – Interfaz de FlightGear, selección de aeronave. 16
Ilustración 3-6- Logotipo de JSBSim 16
Ilustración 3-7- Ventana de comandos con todas las opciones del JSBSim 17
Ilustración 3-8 – Sistema de referencia estructural en JSBSim 18
Ilustración 3-9 – Logotipo de MATLAB 26
Ilustración 3-10 – Esquema de HIL con MATLAB 26
Ilustración 4-1 – Retrasos en la transmisión 31
Ilustración 4-2 – Comunicación fallida 31
Ilustración 5-1-Pasos a seguir 33
Ilustración 5-2 – Esquema de comunicación 34
Ilustración 5-3 – Seguimiento en referencia del ángulo θ 35
Ilustración 5-4 – Bloques de Serial en SIMULINK 36
Ilustración 5-5 - – Acumulación de Retraso en Simulink 37
Ilustración 5-6 – Modelo encapsulado del AirWhale en SIMULINK 38
Ilustración 6-1 – Diagrama de bloques del modelo encapsulado 39
Ilustración 6-2 – Relación Fuerza-PWM 41
Ilustración 6-3 – Actuadores del AirWhale 42
Ilustración 6-4 – Esquema del prototipo del AirWhale 43
Ilustración 7-1 – FlightGear Simulink Block 45
Ilustración 7-2 – Equivalencia X, Y a longitud y latitud 47
Ilustración 7-3 - Subsistema de Visualizador 48
Ilustración 8-1 – Planificador de trayectoria 49
Ilustración 9-1 – Zeppelin NT 52
Ilustración 9-2 – Boeing 737-300 52
Ilustración 9-3 – HL-20 53
Ilustración 9-4 – Sencilla interfaz para elegir aeronave y llamar a FlightGear 53
xxi
Notación
UAV Unmanned Aircraft Vehicle o dron
HIL Harware in the Loop
FYI Fly Yor Ideas
FDM Flight Dynamics Model
VRP Vehicle Reference Point
CG Centro de gravedad
CAM Cuerda Aerodinámica Media
FG FlightGear
APM ArduPilotMega
asen Función arcoseno
sen Función seno
cos Función coseno
Índice de Figuras
22
1 INSTRUCCIÓN
l mundo de la aeronáutica ha cambiado mucho desde que Leonardo da Vinci diseñaba planeadores o
desde que los hermanos Wright realizaron su primer vuelo. Lo que para muchos era imposible en
aquella época, ahora lo vemos todos los días y pocas son las personas que no se hayan montado ya en un
avión comercial.
A día de hoy, no sólo es posible hacer que un aparato vuele, sino que hay quien tiene uno propio y no es difícil
de conseguir. Gracias a los esfuerzos de muchas personas en conjunto, existen guías de todo tipo para crear tu
propio dron. No sólo eso, incluso existen juguetes para niños que vuelan con señal de radiocontrol.
Actualmente podemos encontrar muchos estudios realizados sobre UAV. En IEEE hay 5009 artículos
relacionados y más de la mitad son de los últimos cuatro años.
El estudio de drones es un tema muy atractivo y ya hay muchas universidades trabajando en ello, incluyendo a
la Universidad de Sevilla. Nuestra universidad cuenta con varios departamentos con proyectos relacionados
dentro de la Escuela Superior de Ingeniería, como el Proyecto Integrado FP7 ARCAS del departamento de
Ingeniería de Sistemas y Automática.
El interés por estas aeronaves es tal que en España se ha regulado el uso legal de los mismos en estos últimos
años de acuerdo al peso y la altura de vuelo del dron.
1.1 ESITECH
A finales del curso académico 2013/2014, un grupo de alumnos inspirados por los avances realizados en
drones, tomó la inciativa de formar un equipo con aquellos interesados en investigar sobre el tema y trabajar en
un único proyecto conjunto. Para conseguir la financiación para los materiales necesarios, se formó en la
escuela una asociación contando con el consejo y asesoramiento de un grupo de profesores sin el cual no
habría sido posible. Así nació EsiTech.
E
Si puedes soñarlo, puedes hacerlo.
- Walt Disney -
Instrucción
2
EsiTech está formado por alumnos de distintas ramas de la ingeniería dispuestos a aportar sus conocimientos a
los proyectos de la asociación. El trabajo hasta ahora se ha dividido en equipos como se observa en la
Ilustración 1-2, para trabajar concurrentemente.
Ilustración 1-2 – Grupos de trabajo de EsiTech
Equipo Mecánico- Aeronáutico:
Alvaro Romero Calvo
Inmaculada Gómez Vázquez
Javier Eduardo Mitjavilla Samayoa (Jefe de Equipo)
Juan Carlos Mancebo Sánchez
Equipo Electrónico:
Ana Caballos Torroba
Juan Carlos Martín Rodríguez (Jefe de equipo)
EsiTech
Equipo Automático
Equipo Mecánico-
Aeronáutico
Equipo Electrónico
Ilustración 1-1 – Logo de EsiTech
3
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Miguel Ángel Rogrigo Lisboa
Equipo Automático:
Alejandro Romero Galán (Jefe de equipo)
Elena Manga Caballero
José Luis Holgado Álvarez
Siendo las posiciones de cada uno dentro de la asociación la que se muestra en la Ilustración 1-3.
1.2 Proyecto AirWhale
La asociación EsiTech está barajando varios proyectos para el futuro pero actualmente cuenta con un único
proyecto activo, el proyecto AirWhale.
Este proyecto nació a partir de la idea de un quadrotor. Un quadrotor consiste en un vehículo aéreo cuya
sustentación y movimiento lo proporcionan cuatro rotores en cruz. El juego con las velocidades de cada uno de
estos rotores proporciona los pares y el empuje necesarios para su movimiento. Ahora es relativamente fácil
conseguir uno de estos drones y su comportamiento está bastante estudiado y es conocido, tanto como lo son
sus virtudes y defectos.
El tiempo de vuelo de un quadrotor depende directamente de la capacidad de la batería que incluya. A mayor
capacidad de batería, más pesará la misma y más velocidad deberán alcanzar los rotores para sustentar dicho
peso, por lo que consumirán más potencia.
Con esto en mente, se pensó en una aeronave que se mantuviera en vuelo un período largo de tiempo con poco
consumo para compensar el peso de las baterías, un dirigible. El gas almacenado en el dirigible compensa el
peso de la aeronave. En un comienzo, de la fusión de ambas ideas surgió el primer prototipo del AirWhale, el
más sencillo y práctico a primera vista, una bolsa esférica de helio con rotores alrededor para proporcionar el
movimiento, como se puede ver en la Ilustración 1.4.
EsiTech
PRESIDENTE José Luis Holgado
SECRETARIO Juan Carlos Mancebo
RELACIONES PUBLICAS Elena Manga
TESORERO Miguel Ángel
Rodrigo
Ilustración 1-3 – Organigrama de la organización
Instrucción
4
La función inicial del AirWhale como se adivina, no era el transporte de pasajeros. El primer objetivo
propuesto era ser capaz de tomar imágenes nítidas en vuelo.
Este modelo inicial no es aerodinámicamente estable por lo que se tuvo que rediseñar. Para obtener una mayor
estabilidad, se consideró alargar en la aeronave longitudinalmente y distribuir los rotores de modo que dos
quedasen como en un dirigible convencional mientras los otros dos se dispusieron a los lados. De este modo
con los pares se pueden controlar los ángulos de alabeo, cabeceo y guiñada.
A partir de este modelo, se diseñó el prototipo definitivo que cuenta con tres modulos de helio y se puede
observar en la Ilustración 1-6.
Ilustración 1-5- Prototipo intermedio AirWhale
Ilustración 1-4- Primer prototipo del AirWhale
5
Desarrollo de un entorno Harware in the Loop para el AirWhale.
La evolución que ha seguido el modelo del AirWhale tiene por detrás el trabajo de todo el equipo mecánico-
aeronáutico que ha trabajado en el diseño estructural, en la estabilidad y la aerodinámica del mismo. No se
entrará en más detalles de dicha evolución ya que entra dentro de las competencias de dicho equipo. [1] [2] [3].
Al mismo tiempo que evolucionaba el modelo estructural de la aeronave lo hacía su electrónica interna. Los
objetivos a cumplir del AirWhale estaban fijados desde el comienzo del proyecto y los demás equipos
trabajaban en paralelo para conseguirlos. Dichos objetivos eran los siguientes:
Velocidad máxima de crucero: 5m/s.
Autonomía de vuelo: 1h.
Altura máxima que alcanza en vuelo: 20m.
Capaz de despegar, desplazarse y aterrizar correctamente en un recinto cerrado.
1.2.1 Participación en el concurso de Fly Your Ideas
Una vez formada la asociación y comenzado a trabajar en el AirWhale, al inicio del curso académico
2014/2015, se decidió participar en el concurso de Fly Your Ideas lanzado por AIRBUS GROUP. FYI es un
concurso a nivel internacional realizado cada dos años en el que compiten jóvenes estudiantes de todo el
mundo. El concurso cuenta con tres fases, los participantes tienen que defender sus proyectos para conseguir
llegar a la final. Dichos proyectos deben ser ideas innovadoras relacionadas con el mundo de la aeronáutica.
Ilustración 1-6- Prototipo final del AirWhale
Instrucción
6
Durante dicho concurso, AIRBUS pone en contacto a cada equipo con un supervisor que ayudará y guiará al
grupo con el fin de que defiendan sus ideas lo mejor posible.
El proyecto AirWhale se presentó en Octubre de 2014 al concurso con el apoyo del profesor Daniel Limón
Marruedo. Para la presentación al concurso se cambió la función de la aeronave y se orientó al transporte de
pasajeros. Su imagen es la de un vehículo de transorte aéreo ecológico de media distancia, la alternativa aérea
a los trenes que transportan pasajeros entre provincias.
Solo uno de los dos equipos que se presentaron al concurso de la Universidad de Sevilla pasó la primera fase.
Resultó una grata sorpresa ver que el AirWhale pasó a la siguiente fase. Para esta segunda fase era necesario
realizar una portada y un video de presentación. La portada del equipo puede verse en la Ilustración 1.7.
Desafortunadamente la idea no llegó a la ronda final pero la experiencia fue muy enriquecedora.
Los miembros de la asociación representantes del AirWhale en FYI fueron:
José Luis Holgado Álvarez
Juan Carlos Martín Rodriguez
Inmaculada Gómez Vázquez
Juan Carlos Mancebo Sánchez
Javier Eduardo Mitjavilla Samayoa
Ilustración 1-7 – Portada del equipo en para la segunda fase del concurso de FYI
10
2 EQUIPO AUTOMÁTICO
l primer paso para conseguir un control adecuado de la aeronave es la organización del trabajo. Es
necesario identificar los pasos a realizar y su finalidad. En la Ilustración 2.1 se muestra un esquema
muy básico de los pasos a seguir. Contando con un equipo de tres personas, es posible dividir el
trabajo en bloques para trabajar de forma eficiente y concurrente.
Ilustración 2-1 – Esquema de trabajo del equipo automático
ELECCIÓN ELECTRÓNICA
CONSTRUCCIÓN DEL PROTOTIPO
VERIFICACIÓN
OBTENCIÓN MODELO DEL
SISTEMA
DISEÑO DEL HIL
ADAPTACIÓN FIRMWARE DE
ARDUPILOT
DISEÑO DE LEYES DE CONTROL E
IMPLEMENTACIÓN
E
La fortaleza está en nuestras diferencias, no en nuestras
similitudes.
- Stephen Covey-
11
Desarrollo de un entorno Harware in the Loop para el AirWhale.
2.1 División del trabajo
Para controlar la aeronave es necesario estudiar el comportamiento de la misma y realizar un modelo
matemático en el que probar los controladores. El modelo matemático del AirWhale que se empleará está
basado en el proyecto de final de carrera de Javier Eduardo Mitjavila Samayoa [1], miembro de la asociación
ESITECH. Ha sido necesario trabajar sobre el modelo y pasarlo a espacio de estados para la implementación
de los controladores, el modelo definitivo a utilizar se incluirá en el capítulo referente al modelo.
El trabajo de control se dividirá en tres grandes bloques: obtención de leyes de control e implementación,
adaptación del firmware de APM y diseño de un entorno HIL para la verificación.
Del diseño de las leyes de control se encargará Jose Luis Holgado Álvarez.
Para la actualización del firmware en la plataforma elegida es necesario investigar el código
implementado en el Ardupilot, que será la placa elegida para controlar la aeronave. Esta tarea recaerá
sobre Alejandro Romero Galán.
Por otro lado, es en este proyecto final de grado donde se trata el diseño del entorno HIL para la
verificación de los controladores en la plataforma Ardupilot.
Por otro lado, Alejandro Romero Galán y Jose Luís Holgado Álvarez han construído un prototipo básico del
AirWhale para comprender mejor la aeronave y los actuadores. Este prototipo también puede servir como
alternativa al HIL para la verificación de los controladores.
2.2 Placa de control
Como microprocesador en el que se implementarán los controladores debe tener la capacidad suficiente para
realizar las operaciones pertinentes así como para recibir los datos de los sensores y tratarlos si fuera necesario.
En vuelo, la aeronave tiene que contar con una serie de sensores capaces de determinar su posición y
orientación. La placa proporcionada por el departamento de Ingeniería de Sistemas y Automática para
controlar el AirWhale es ArduPilot Mega 2.6 o APM 2.6.
La plataforma cuenta con un acelerómetro, un giróscopo y un barómetro que proporcionan los datos necesarios
para poder obtener las cordenadas de la aeronave. Otras versiones anteriores de APM cuentan con un
magnetómetro pero en esta versión se ha optado por evitar las interferencias que este pudiese inducir en la
placa y se ha facilitado la conexión externa en caso de requerirse. También cuenta con entradas adaptadas para
GPS y telemetría. La placa cuenta con 9 entradas analógicas y 8 digitales por la que se comunicará con los
actuadores.
A nivel de código, se programa en lenguaje C/C++. El firmware incluído por defecto es muy extenso y cuenta
con muchas librerías orientadas, en todos los niveles de progración, al control de un UAV. Este firmware
incluye la comunicación por puerto serie con el software de Mission Planner.
Para mayor detalle del firmware de APM 2.6, se puede consultar el trabajo final de grado de Alejandro
Romero Galán cuyo proyecto cuenta con la actualización de dicho firmware para su adaptación a nuestra
aeronave [6].
Equipo Automático
12
Ilustración 2-2- Placa ArduPilot Mega 2.6
13
Desarrollo de un entorno Harware in the Loop para el AirWhale.
3 ESTUDIO PREVIO
a simulación en Hardware in the Loop es una técnica normalmente usada para probar sistemas de
tiempo real complejos. El sistema a probar en este caso es la plataforma APM2.6 con los controladores
y debe interaccionar con la simulación para comprobar su correcto funcionamiento. Se entiende que
dicho HIL emula los sensores a nivel analógico. La plataforma a emplear dispone de los sensores integrados
en una misma placa y se emplearán funciones de librerías facilitadas para obtener la información de los
mismos. Es por eso que la emulación de sensores en este caso se hará facilitando la información que
proporcionan dichas funciones.
El fin del HIL es la comprobación visual del diseño e implementación de los controladores. En el Ardupilot
Mega 2.6 se implementará el sistema de control. La plataforma gestiona la acción a realizar y la manda al
actuador correspondiente. Dichos actuadores serán los rotores, que crearán los pares y empujes para conseguir
el movimiento deseado de la aeronave.
El propósito del HIL es recibir las actuaciones desde APM y ver la respuesta del modelo dinámico de la
aeronave ante las mismas para luego emular la lectura de los sensores ante el comportamiento de la aeronave.
Para ello es necesario un modelo del AirWhale capaz de proporcionar la información anterior a partir de las
actuaciones.
En este capítulo se explican las diferentes opciones contempladas para leer las actuaciones proporcionadas por
la platforma APM 2.6 y obtener la trayectoria que seguirá la aeronave
El proyecto inicial era muy ambicioso. Contaba con un planificador de trayectoria que comunicase todos los
datos proporcionados por APM a un simulador de vuelo. El modelo del sistema se debería incluir en dicho
simulador de vuelo de tal forma que el comportamiento de la aeronave simulada coincidiese con el del
AirWhale.
Como planificador de trayectorias en un comienzo se contempló la posibilidad de utilizar Mission Planner. La
plataforma APM 2.6 tiene la comunicación a través de puerto serie con Mission Planner resuelta, facilitando
así el proceso a nivel de código de Ardupilot. Dicho programa cuenta con la posibilidad de emplear un
simulador de vuelo tal como FlightGear o Xplane.
El esquema del HIL que se planea realizar en un principio cuenta con Mission Planner como planificador y
coordinador de la información. Será el que se comunique con la plataforma APM y a la vez con el programa
de visualización. Dicho programa que como más adelante se explicará será FlightGear. FlightGear mostrará
gráficamente por pantalla a la aeronave en vuelo pero será necesario un modelo dinámico del modelo detrás
para estimar cómo se desarrolla el vuelo. Este modelo dinámico se plantea hacer en JSBSim tal y como se
L
El éxito no está ne vencer siempre, sino en nunca
desanimarse
- Napoleón Bonaparte -
Estudio Previo
14
expone en el apartado 3.2.
Más adelante se descartará la opción de emplear Mission Planner por problemas a la hora de hacer un FDM
compatible con el simulador elegido y se decidió utilizar MATLAB.
En los siguientes apartados se entrará más en detalles al respecto.
3.1 Mission Planner
Mission Planner es un programa gratuito de control en tierra para la
plataforma Ardupilot sólo válido para sistemas Windows. Este programa se
comunica con la plataforma por terminal serie, siendo capaz, entre otras cosas,
de proporcionar la lectura de los sensores estando la aeronave en vuelo, así
como de ordenarle una trayectoria a seguir por medio de waypoints.
La Ilustración 3.2 muestra una captura pantalla del menú principal del programa con las posiciones elegidas
por las que queremos que se realice el vuelo. Siguiendo los puntos seleccionados, la aeronave daría una vuelta
por los alrededores de la Escuela Superior de Ingenieros de la Universidad de Sevilla.
Ilustración 3-2 – Logotipo
de Mission Planner
3-1 – Esquema de HIL con MP
Simulador
Mission Planner APM2.6
FlightGear
JSBSim
FDM Planificador Controladores
Estados
Acciones de control Actuaciones
Estados y
referencia
HIL
15
Desarrollo de un entorno Harware in the Loop para el AirWhale.
Ilustración 3-3 – Elección Waypoints en Mission Planner
Este programa también cuenta, como se ha comentado en otros apartados, con la opción de trabajar en un
entorno HIL. Para ello, se facilita la conexión por protocolo UDP con distintos programas: X-Plane
FlightGear, AeroSim RC, JSBSim.
De entrada, se descartó la posibilidad de usar X-Plane por ser un software de pago y de AeroSim RC por no
adaptarse a nuestras necesidades. Por otro lado, JSBSim proporciona datos de la respuesta del sistema pero no
la visualización en vuelo del vehículo. Por todo esto, se optó por utilizar FlightGear como simulador de vuelo.
3.2 Simulador de vuelo
3.2.1 FlightGear
FlightGear es un simulador de vuelo gratuito creado íntegramente por voluntarios de todo
el mundo y disponible para varios sistemas, entre ellos los más populares: Linux,
Macintosh y Windows. Este programa incluye en el paquete de instalación una serie de
aeronaves y escenarios de libre uso.
El usuario es capaz de pilotar una aeronave directamente desde la cabina de piloto con los
mandos correspondientes y puede ver la aeronave desde distintos ángulos de visión.
Para utilizar este simulador de vuelo es necesario contar con un modelo en 3D de la
aeronave así como con el modelo dinámico de vuelo de la misma.
Es posible emplear este programa para la simulación ya que como se explicó con anterioridad, que Mission
Planner ofrece la posibilidad de conectarse en un entorno HIL con este programa. Ardupilot ya cuenta con la
configuración necesaria para trabajar en dicho entorno por medio de Mission Planner.
Para utilizar FG como simulador es necesario disponer del modelo dinámico del sistema en soporte
informático compatible con el programa. Dado que nuestra aeronave cuenta con la sustentación propia de
Ilustración 3-4-
Logotipo actual
de FlightGear
Estudio Previo
16
vehículos más ligeros que el aire se decidió realizar el FDM con JSBSim.
Ilustración 3-5 – Interfaz de FlightGear, selección de aeronave.
3.2.2 JSBSim
JSBSim es un programa de código abierto utilizado
para codificar de forma estructurada el modelo
dinámico de vuelo (FDM) de una aeronave. Este
programa se creó en un comienzo orientado a su uso
para el simulador de vuelo gratuito FlightGear pero
actualmente también es empleado directamente para
obtener datos del comportamiento del modelo de la
aeronave. Es posible instalar el programa en
sistemas Windows, Linux y Macintosh.
El modelo de la aeronave se codifica en lenguaje XML (eXtensible Markup Language). Esto facilita el
estructurar las especificaciones de la aeronave a la vez que permite el uso de dicha información. Los archivos
XML que definen una aeronave se almacenan en un fichero del mismo nombre de la aeronave dentro de la
carpeta JSBSim\aircrafts. En los siguientes apartados se tratará más en profundidad la estructura que debe
seguir el model dinámico de una aeronave para JSBSim en XML.
La instalación del programa en sistemas Windows no es trivial. A continuación se facilitará un enlace donde se
encuentra una guía detallada de instalación en inglés del programa para Windows XP con Visual C++2008
Express. También es posible seguir esta guía para la instalación del programa en otras versiones de Windows y
Visual Studio sin mayor complicación.
http://www.holycows.net/JSBSim/Building_JSBSim_with_Visual_C++.pdf
Para llamar al programa JSBSim es necesario hacerlo desde la ventana de comandos. Para realizar las pruebas
es necesario contar con un código en XML que especifique las acciones a realizar para dicha prueba y luego
hacer que el programa lo ejecute.
Ilustración 3-6- Logotipo de JSBSim
17
Desarrollo de un entorno Harware in the Loop para el AirWhale.
El código más usualmente utilizado como ejemplo de pruebas para este programa es el c1723.xml, que viene
incorporado junto con otros scripts en la carpeta JSBSim\scripts en el paquete inicial de instalación. Este
código usa la aeronave Cessna 172, llamada c172x en JSBSim, y la hace volar proporcionando los datos del
vuelo.
Para ejecutar dicho script únicamente sería necesario escribir Debug\JSBSim –script=scripts\c1723.xml en la
línea de comandos dentro de la carpeta donde se haya instalado el programa. La ejecución del programa
genera un archivo JSBout172B.csv en el que se almacenarán los datos generados. A la hora de representar
dichos datos de forma gráfica es posible utilizar el programa gratuito GNUPLOT para mayor facilidad.
Se recomienda el uso de este programa en versiones de Windows XP o para sistemas operativos Linux. A
continuación se adjunta un tutorial del uso de scripts y GNUPLOT para generar datos con JSBSim al que se
puede acceder directamente desde la página oficial de JSBSim.
http://www.holycows.net/JSBSim_Script_Tutorial.pdf
En caso de Windows se abre escribiendo cmd en el buscador de la barra de inicio y pulsar la tecla INTRO. En
la Ilustración 3-7 se muestran las distintas opciones que da a realizar JSBSim.
Es posible ejecutar cualquier script en el programa a tiempo real añadiendo --realtime tras el nombre del
script al que se llama en cuestión.
Ilustración 3-7- Ventana de comandos con todas las opciones del JSBSim
Mission Planner permite una conexión directa con JSBSim pero ésta no es la utilidad que se ha buscado para el
modelo dínamico de vuelo ya que este último no permite ver la aeronave en vuelo. Para este proyecto se
estudió la posibilidad de usar el modelo del AirWhale para emplearlo en FlightGear.
La codificación del FDM no es sencilla y la información de la que se dispone es incompleta. Sin embargo, es
posible crear el modelo de una aeronave estable fácilmente a partir de ciertos datos requeridos con la
Estudio Previo
18
herramienta aeromatic que se encuentra en la página oficial de JSBSim. Los datos principales que se necesitan
de la aeronave son los siguientes:
Peso máximo de despegue
Tipo, longitud, peso y envergadura de la aeronave
Cuerda aerodinámica media (CAM)
Brazos del estabilizador horizontal y vertical así como su área
Ángulo de incidencia de las alas y el área de las mismas
Matriz de inercia
Número de motores y tipo de los mismos
Disposición de los motores
El código que genera aeromatic es para una aeronave estándar por lo que tendría que ser modificado para
conseguir un vehículo aéreo como el AirWhale. JSBSim cuenta actualmente con vehículos más ligeros que el
aire como el Zeppelin Luftschifftechnik LZ N07 (ZLT-NT en JSBSim). En un comienzo se estudio el código
de esta aeronave para generar en XML el FDM definitivo del AirWhale.
El mayor problema de JSBSim es todas las funciones y propiedades que incluye. No hay suficiente
documentación acerca de los mismos. Aún a pesar de que se inició el proyecto orientado a usar FlightGear
como simulador de vuelo con el FDM generado con JSBSim, debido a los problemas que se encontraron para
definir el modelo dinámico de la aeronave, se optó por otras opciones.
En los siguientes subapartados, se explicará la estructura básica del código que define una aeronave con este
programa y se incluirán ejemplos a partir del trabajo realizado para una mejor comprensión.
3.2.2.1 Conceptos Básicos
JSBSim trabaja con varios sistemas de referencia definidos según sea más conveniente. El sistema de interés
para localizar posiciones de la estructura es el sistema de referencia estructural, este se muestra en la
Ilustración 1-2. Dicho sistema de referencia contiene el eje X en la dirección diseñada de movimiento en
sentido contrario. En eje Z aumenta hacia arriba de la aeronave mientras el eje Y lo hace hacia la derecha
mirándola.
Ilustración 3-8 – Sistema de referencia estructural en JSBSim
19
Desarrollo de un entorno Harware in the Loop para el AirWhale.
El programa reconoce una gran cantidad de funciones elementales que son de uso común en el lenguaje XML
como son las funciones trigonométricas y operacionales básicas.
Es posible también definir valores con diferentes unidades para facilitar el proceso. Las unidades recogidas son
algunas del sistema internacional y del sistema anglosajón así como otros. En Tabla 3-1 se encuentran
recogidas gran parte de las unidades que acoge este programa.
Tabla 3-1. Sistema de medidas en JSBSim
Medidas Unidades del sistema internacional Otras unidades
Longitud Metros (M) Pulgadas (IN), pies (FT)
Masa Kilogramos (KG) Libras (LBS), slug (SLUG)
Tiempo Segundos (SEC)
Ángulos Radianes (RAD) Grados (DEG)
Fuerza Newton (N)
Potencia Vatios (WATTS) Caballos (HP)
Tensión superficial Newton por metro (N/M) Libras por pie (LBS/FT)
Velocidad Metros por segundo (M/SEC) Nudos(KNS), pies por segundo
(FT/SEC)
Area Metros al cuadrado (M2) Pies al cuadrado (FT2), pulgadas
al cuadrado (IN2)
Volumen Metros al cubo (M3)
Litro (LTR), Centímetros cúbicos
(CC), pies al cubo (FT3), pulgadas
al cubo (IN3)
Densidad superficial Kilogramo por metro cuadrado
(KG*M2)
Slug por pies al cuadrado
(SLUG*FT2)
Amortiguación N/M/SEC LBS/FT/SEC
Presión Pascales (PA)
Pulgadas de mercurio (INHG),
libras por pie al cuadrado (PSF),
atmósferas (ATM), libras por
pulgadas al cuadrado (PSI)
3.2.2.2 FDM de la aeronave
Estudio Previo
20
Los ejemplos incluidos en este apartado son partes ya modificadas del código generado por aeromatic para
los datos del AirWhale. Algunos de ellos están en unidades internacionales aunque esta herramienta genera
por defecto otro tipo de unidades.
Para comenzar, el FDM de una aeronave cuenta con distintas secciones a incluir:
Metrics o medidas típicas de la aeronave.
La estructura típica de esta sección se puede observar en el Ejemplo 3-1 y no suele variar mucho
entre las distintas aeronaves. En esta sección se definen algunos de los valores que se requieren en
aeromatic como son: área de las alas, envergadura, ángulo de incidencia de las alas, el CAM o el
brazo y el área de los estabilizadores. También se definirán las coordenadas de los puntos importantes
de la aeronave como son:
AERORP. Punto de referencia aerodinámico. Es el punto donde se calculan las fuerzas y
momentos
EYEPOINT. El punto donde se calculan los efectos del vuelo sobre el piloto.
VRP. Usualmente es el origen de coordenadas y suele estar colocado en la nariz de la
aeronave.
Ejemplo 3-1
<metrics>
<wingarea unit="M2"> 1.681 </wingarea>
<wingspan unit="M" > 2.134 </wingspan>
<wing_incidence> 0.79 </wing_incidence>
<chord unit="M" > 0.793 </chord>
<htailarea unit="M2"> 0.52 </htailarea>
<htailarm unit="M" > 0.7375 </htailarm>
<vtailarea unit="M2"> 0.52 </vtailarea>
<vtailarm unit="M" > 0.5 </vtailarm>
<location name="AERORP" unit="M">
<x> 1.57 </x>
<y> 0.00 </y>
<z> 0.00 </z>
</location>
<location name="EYEPOINT" unit="IN">
<x> 10.24 </x>
<y> -24.00 </y>
<z> 65.00 </z>
</location>
<location name="VRP" unit="M">
21
Desarrollo de un entorno Harware in the Loop para el AirWhale.
<x>0</x>
<y>0</y>
<z>0</z>
</location>
</metrics>
Mass balance o balance de masas.
En esta sección típicamente se define cómo van distribuídas las masas de la aeronave y sus
características.
Es necesario definir los componentes de la matriz de inercias.
La localización del centro de gravedad, CG
La carga que porte el vehículo se considera localizada en puntos concretos y es necesario
incluirla. El AirWhale no transporta carga alguna pero en el el siguiente Ejemplo 3-2 se
considera una carga de 0.1 libras.
Ejemplo 3-2
<mass_balance>
<ixx unit="KG*M2"> 467187 </ixx>
<iyy unit="KG*M2"> 5403 </iyy>
<izz unit="KG*M2"> 471913 </izz>
<ixy unit="KG*M2"> 39338.3 </ixy>
<ixz unit="KG*M2"> 1156.39 </ixz>
<iyz unit="KG*M2"> 9997.15 </iyz>
<emptywt unit="KG" > 3 </emptywt>
<location name="CG" unit="M">
<x> 1.46 </x>
<y> 0.00 </y>
<z> -0.20 </z>
</location>
<pointmass name="Payload">
<weight unit="LBS"> 0.1 </weight>
<location name="POINTMASS" unit="IN">
<x> 98.92 </x>
<y> 0.00 </y>
Estudio Previo
22
<z> -3.20 </z>
</location>
</pointmass>
</mass_balance>
Ground reactions o reacciones con tierra
Para la simulación es necesario definir los posibles contactos con tierra y de eso trata esta sección.
JSBSim distingue dos casos; el contacto de las ruedas con tierra (BOGEY) o del cuerpo con tierra
(STRUCTURE). En caso de ser un contacto del cuerpo con tierra, no es necesario definir algunas de
las variables incluidas en las definiciones de los contactos BOGEY.
La herramienta aeromatic genera unos datos típicos de contacto en función del tren de aterrizaje
elegido. Aún así, no es posible con una herramienta estándar definir nuestra aeronave por completo
por lo que es necesario revisar bien la localización de los puntos de contacto.
En el ejemplo únicamente se definen dos puntos de contacto pero es necesario definir todos los puntos
así como la localización de todos los trenes de aterrizaje como BOGEY y las puntas de las alas como
STRUCTURE (RIGHT_WING, LEFT_WING). En el caso del AirWhale, se ha definido un triciclo
como tren de aterrizajepor lo también habría que definir la localización de los dos trenes laterales
(RIGHT_MAIN, LEFT_MAIN). Otros posibles puntos de contacto también se podrían definir como
el del Ejemplo 3-3.
Ejemplo 3-3
<ground_reactions>
<contact type="BOGEY" name="NOSE_GEAR">
<location unit="IN">
<x> 16.63 </x>
<y> 0.00 </y>
<z> -15.36 </z>
</location>
<static_friction> 0.80 </static_friction>
<dynamic_friction> 0.50 </dynamic_friction>
<rolling_friction> 0.02 </rolling_friction>
<spring_coeff unit="LBS/FT"> 0.66 </spring_coeff>
<damping_coeff unit="LBS/FT/SEC"> 1.10 </damping_coeff>
<max_steer unit="DEG"> 0 </max_steer>
23
Desarrollo de un entorno Harware in the Loop para el AirWhale.
<brake_group>LEFT </brake_group>
<retractable>{0</retractable>
</contact>
<contact type="STRUCTURE" name="LEFT_WING">
<location unit="IN">
<x> 98.92 </x>
<y> -3.28 </y>
<z> -3.20 </z>
</location>
<static_friction> 1.00 </static_friction>
<dynamic_friction> 1.00 </dynamic_friction>
<spring_coeff unit="LBS/FT"> 2.21 </spring_coeff>
<damping_coeff unit="LBS/FT/SEC"> 2.21 </damping_coeff>
</contact>
</ground_reactions>
Propulsión
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
v0.9.3, v0.9.8/0.9.8a, v0.9.9, v0.9.10, v1.0, v1.9.1, v2.0, v2.4, v2.6, v2.8, v2.10, v2.12, v3.0 del programa.
La dirección IP y el puerto se pueden usar los que vienen dados por defecto en el bloque pero habrá que
estudiar el tiempo de muestreo más conveniente para nuestro sistema.
Antes de iniciar una simulación será necesario configurar FlightGear para la conexión. Matlab incluye un
bloque “Generate Run Script” que crea un código en archivo .bat para llamar al programa directamente desde
MATLAB con la todo lo requerido para la conexión. Hay ciertos campos a especificar que deberemos elegir:
FlightGear geometry model name. El nombre de la aeronave que se precisa.
Airport ID. La simulación e vuelo con FlightGear nos puede recordar a la visión desde Google Earth
E
En la guerra como en el amor, para acabar es
necesario verse de cerca.
- Napoleón Bonaparte -
Ilustración 7-1 – FlightGear Simulink Block
Visualización
46
pero la base de datos de este último no tiene comparación. FlightGear cuenta con una serie de
escenarios instalados por defectos a los que se pueden añadir todos los se deseen pero siempre serán
diferentes porciones de la tierra. En este campo deberemos de añadir un aeropuerto de entre esos
escenarios con los que cuenta el software de visualización.
Runway ID. Se le asignará una pista de aterrizaje a la aeronave. Un ejemplo de runaway serían 10L o
10R para el aeropuerto KSFO de san Francisco.
Initial altitude (ft). Altitud a la que estará la aeronave inicialmente en pies desde la pista de aterrizaje
la altura de visión.
Offset distance (miles). Distancia entre la aeronave y el aeropuerto en millas.
Initial heading (deg) y Offset azimuth son datos que en nuestras condiciones se atualizarán a sus
valores predeterminados por lo que será suficiente con dejar los indicados.
En la ventana File es necesario revisar la carpeta donde está instalado el software de FlightGear o el
archivo se creará sin problemas pero al ejecutar el código, la ventana de comandos de Windows será
capaz de abrir el programa al no encontrarlo en la dirección proporcionada.
Una vez generado el código, aparecerá en el directorio como un archivo.bat. Si la opción de comunicación
seleccionada es “enviar” como el caso a tratar, el código generado necesitará una pequeña modificación. Tras
la declaración de la aeronave a usar, en el código aparecerá lo siguiente:
--fdm=network,localhost,5501,5502,5503
FlightGear no reconoce este comando a la hora de ejecutarse y el programa no responde. Para ello se deberá
sustituir lo anterior por la línea incluida a continuación considerando el puerto elegido 5502:
--fdm=null --native-fdm=socket,in,30,localhost,5502,udp
7.1.1 Configuración de FlightGear para simulación
Para que todo este proceso funcione, la aeronave debe tener la configuración adecuada. Será necesario
disponer de una carpeta con el nombre de la misma en el directorio …\FlightGear\data\Aircraft\. Dentro de
ella debe haber un archivo XML llamado “nombre de aeronave-set” donde se specifique el modelo en vuelo
como “network”. Esta carpeta deberá contener también otra de nombre “Models” donde aparecerá un
archivo.ac con el modelo de la aeronave en 3D además de otro XML de igual nombre que la aeronave en el
que se describirá el movimiento de la misma. El modelo es posible realizarlo con distintos programas como
son AC3D, Blender, SketchUp o Wings 3D.
La información mínima necesaria que debe incluir el archivo principal “aeronave-set” es la definición del
modelo de vuelo así como la dirección del archivo “aeronave”. A continuación se incluye un ejemplo
considerando como hasta ahora, “aeronave” el nombre de nuestro vehículo.
Ejemplo 7-1
<PropertyList>
<sim>
<flight-model>network</flight-model>
<model>
<path>Aircraft/aeronave/Models/aeronave.xml</path>
</model>
47
Desarrollo de un entorno Harware in the Loop para el AirWhale.
</sim>
</PropertyList>
A su vez, en el archivo “aeronave” dentro de la carpeta “Models” tiene como requisito indispensable declarar
el modelo en 3D a volar. En el siguiente ejemplo se incluye el código necesario para declarar el modelo en el
archivo “aeronave”.
Ejemplo 7-2
<PropertyList>
<path>HL20.ac</path>
</PropertyList>
7.1.2 Tratamiento de datos para usarlos en la visualización
Cumpliendo lo anterior, el programa debería cargar con la aeronave estática en la posición inicial una vez
ejecutado el archivo.bat proporcionado por MATLAB modificado.
Por otro lado, el bloque a utilizar “FlightGear Preconfigured 6DoF Animation” considera las unidades de
longitud, latitud, angulos de alabeo, cabeceo y guiñada en radianes así como la altura en metros sobre el nivel
del mar. Habrá que tratar las unidades en las que trabaja el modelo matemático del AirWhale para poder
transmitirlas a FlightGear. Las unidades del modelo son grados para los ángulos de alabeo, cabeceo y guiñada
así como metros para la posición en X, Y, Z.
La longitud y la latitud son una forma de proporcionar la situación geográfica de un lugar en el globo
terráqueo. Se basa la división de la esfera que es la tierra en ángulos cortándola en dos líneas perpendiculares
para longitud y latitud determinando así una posición concreta en la tierra.
Para pasar la posición en X, Y, Z a longitud y latitud únicamente es necesaria una cuenta trigonométrica
considerando la altura desde el centro de la tierra como la altura en Z más el radio medio de la tierra que es de
6.371 km. Tomando el incremento en X como incremento en longitud y en Y para la latitud es muy sencillo
sacar la relación. Esta conversión se realiza en el bloque “(X, Y, Z) (long,lat,alt)”.
Ilustración 7-2 – Equivalencia X, Y a
longitud y latitud
Visualización
48
También será necesario limitar la altura proporcionada por el modelo. El modelo considera una disminución
de la altura de la aeronave siempre que la fuerza proporcionada por los actuadores sea menor que la de
sustentación. Si no se pone un límite inferior a la altura igual al nivel del suelo, la aeronave puede bajar hasta
llegar a niveles inferiores a la superficie terrestre. En caso de no tener esto en cuenta, FlightGear no dará error
pero la posición estará fuera del escenario esperado por lo que la imagen mostrada no tendrá apariencia de
paisaje como en otras posiciones.
El escenario elegido para la simulación es una pista de despegue del aeropuerto de KSFO, de San Francisco (-
122.3908, 37.62538, 35). Para conseguir que el movimiento en X e Y en radianes coincidan con las
direcciones deseadas, es necesario realizar una rotación de los ejes. Esta rotación se incluirá en el subsistema
“Rotación”. Esa rotación se realiza en con la siguiente matriz:
El subsistema realizado de visualización también convierte los ángulos de alabeo, cabeceo y guiñada a
radianes tal y como se proporcionan al bloque “FlightGear Preconfigured 6DoF Animation” con una simple
operación.
En la siguiente imagen se aprecia el visualizador con el tratamiento completo del espacio de estados ya
implementado en Simulink
Ilustración 7-3 - Subsistema de Visualizador
49
Desarrollo de un entorno Harware in the Loop para el AirWhale.
8 PLANIFICADOR DE
TRAYECTORIA
e ha diseñado un simple planificador de trayectorias para el sistema. El AirWhale por la longitud de su
cuerpo y la acción de los actuadores, no puede retroceder en el eje x a no ser que de una vuelta completa
completa. Esto lleva a que la referencia en el eje X sea clave para la planificación de la trayectoria. Es por
ello que se ha considerado avanzar al siguiente punto planificado una vez que la aeronave se encuentre a una
distancia mínima de 3m del waypoint. Una vez se cumpla lo anterior, se avanzará hasta el siguiente punto de
referencia.
El planificador que se ha diseñado únicamente crea varía lentamente la referencia desde el punto desde el que
se encuentra la aeronave al siguiente punto de referencia incorporando la dinámica de un sistema de primer
orden.
En todo momento el planificador estará comparando la referencia final en x con el punto en que se encuentra
la aeronave. Para ello emplearemos el bloque de Compare to Constant en MATLAB. Dicho bloque compara
continuamente el valor que se le proporciona con una constante. Tendrá como salida una variable booleana
que valdrá 0 si no se cumple la condición y tendrá valor 1 en caso contrario.
En el momento en el que se cumpla la condición, se pasará al siguiente punto de referencia que bien puede
venir desde workspace o estar almacenada de alguna forma en simulink.
Ilustración 8-1 – Planificador de trayectoria
S
Planificador de trayectoria
50
51
Desarrollo de un entorno Harware in the Loop para el AirWhale.
9 INTERFAZ INICIAL
e ha creado una pequeña interfaz en MATLAB empleando GUIDE para la inicialización del programa
FlightGear. Esta interfaz cuenta con tres botones que muestran tres aeronaves diferentes seleccionadas al
azar de entre todas las aeronaves creadas para FlightGear. De las aeronaves en FlightGear, se ha
sustraído el archivo .ac que contiene el modelo en 3D de la misma y se ha creado incluído en un directorio en
la carpeta del programa siguiendo el procedimiento explicado en el capítulo 0.
El autor de este documento en ningún momento se atribuye el mérito de haber creado dichos modelos y a
continuación mencionará a los responsables de que podamos ver estas aeronaves de la forma en que lo
hacemos.
La primera aeronave seleccionada para la observación en vuelo fue el dirigible Zeppelin NT de la compañía
alemana Zeppelin Luftschifftechnik GmbH. Este modelo para AirWhale ha sido diseñado por Anders
Gidenstam. En JSBSim no se cuenta con muchas aeronaves más ligeras que el aire y esta es una de esas pocas.
Habiendo trabajado con anterioridad en un intento de hacer el FDM del AirWHhale en JSBSim, esta autora
reconoce el mérito de este señor y en ningún momento desea importunarle robándole trabajo propio.
S
La alegría de ver y entenedr es lo más perfecto de la
naturaleza.
- Albert Einstein -
Interfaz inicial
52
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.
ANEXO E
#include <AP_Common.h>
#include <stdarg.h>
#include <AP_Progmem.h>
#include <AP_Param.h>
#include <AP_HAL.h>
#include <AP_HAL_AVR.h>
#include <AP_HAL_PX4.h>
#include <AP_HAL_Linux.h>
#include <AP_HAL_Empty.h>
#include <AP_Math.h>
#include <RC_Channel.h>
#include <AP_Motors.h>
#include <AP_Curve.h>
#include <AP_Notify.h>
#include <AP_GPS.h>
#include <AP_Mission.h>
#include <DataFlash.h>
#include <AP_InertialSensor.h>
#include <AP_ADC.h>
#include <GCS_MAVLink.h>
#include <AP_Baro.h>
#include <Filter.h>
#include <AP_AHRS.h>
#include <AP_Compass.h>
#include <AP_Declination.h>
#include <AP_Airspeed.h>
Anexo E
66
#include <AP_Vehicle.h>
#include <AP_ADC_AnalogSource.h>
#include <AP_Mission.h>
#include <StorageManager.h>
#include <AP_Terrain.h>
#include <AP_NavEKF.h>
#include <AP_ADC.h>
#include <AP_Rally.h>
#include <AP_Scheduler.h>
#include <AP_Compass_HMC5843.h>
#include <AP_InertialNav.h>
#include <AP_Buffer.h>
//////////////////////////////////////////////////////////////////////
///// AP_Hal 'instance'
//////////////////////////////////////////////////////////////////////
const AP_HAL::HAL& hal = AP_HAL_BOARD_DRIVER;
float Ref_roll = 0.5; // Referencia roll
float Ref_pitch = 0.5; // Referencia pitch
float Ref_z=5; // Referencia Z
float Kp_roll, Ti_roll, Td_roll; // Parámetros del PID del controlador Roll
float Kp_pitch, Ti_pitch, Td_pitch; // Parámetros del PID del controlador Pitch
float Kp_z, Ti_z, Td_z; // Parámetros del PID del controlador altura en Z
int T_roll = 1; // Tiempo de muestreo control roll
int T_pitch = 1; // Tiempo de muestreo control pitch
int T_z = 1; // Tiempo de muestreo control Z
float Uk_roll; // Variable de actuación (salida del PID control roll)
float Uk_pitch; // Variable de actuación (salida del PID control pitch)
float Uk_z; // Variable de actuación (salida del PID control Z)
float Ik_roll, Ik1_roll; // Variables para el término integral
67
Desarrollo de un entorno Harware in the Loop para el AirWhale.
float Ik_pitch, Ik1_pitch; // Variables para el término integral
float Ik_z, Ik1_z; // Variables para el término integral
float Ek_roll, Ek1_roll; // Variables para el error
float Ek_pitch, Ek1_pitch; // Variables para el error
float Ek_z, Ek1_z; // Variables para el error
uint16_t dato1;
uint16_t dato2;
uint16_t dato3;
uint16_t dato4;
float Xve[]={0,0,0}; // Vector de variables de estado a recibir
float roll;
float pitch;
float altura;
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////
///////////////////////////////////////////////////////////////////// SETUP
/////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////
void setup()
{
hal.scheduler->delay(1000);
}
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////
///////////////////////////////////////////////////////////////////// Bucle principal
///////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////
void loop()
{
Anexo E
68
// Definiciones
float altura;
float PWM_motor1 = 0;
float PWM_motor2 = 0;
float PWM_motor3 = 0;
float PWM_motor4 = 0;
float PWM_motor5=0;
float PWM_motor6=0;
float L1 = 0.8;
float L2 = 0.7;
int fin = 0;
int anti_roll = 0;
int anti_pitch = 0;
int anti_z = 0;
int16_t tecla;
float Fz = 0;
Ik1_roll=200; // Variables para el término integral
Ik1_pitch=200; // Variables para el término integral
Ik1_z=200;
Kp_roll=10.63;
Ti_roll=6.388;
Td_roll=4.419; // Parámetros del PID del controlador Roll
Kp_pitch=4.8054;
Ti_pitch=2.836;
Td_pitch=1.985; // Parámetros del PID del controlador Pitch
Kp_z=0;
Ti_z=9999;
Td_z=0;
//// INICIO BUCLE DE CONTROL ////
69
Desarrollo de un entorno Harware in the Loop para el AirWhale.
while(fin == 0){
/////////////////
//// Recepción de datos
/////////////////
// Se hace tres veces (tres datos)
for(int i=0; i<3; i++){
// Se espera a recibir algo
while(!hal.console->available()){
hal.scheduler->delay(10);
}
// Se pilla el primer número (0-255)
dato1 = hal.console->read();
while(!hal.console->available()){
hal.scheduler->delay(5);
}
// Se pilla el segundo número (0-60)
dato2 = hal.console->read();
while(!hal.console->available()){
hal.scheduler->delay(5);
}
dato3=hal.console->read();
while(!hal.console->available()){
hal.scheduler->delay(5);
}
dato4=hal.console->read();
// Se calcula el número equivalente
Xve[i] = float(dato1)+(256.000*float(dato2));
Anexo E
70
if (dato3==1){
Xve[i]=0-Xve[i];
}
// Se pasa el número al intervalo real de la variable
if(i==0){
roll = (Xve[i]*360/65536); // 0-65536 a 0-360 grados
}
if(i==1){
pitch = (Xve[i]*360/65536); // 0-65536 a 0-360 grados
}
if(i==2){
altura = (Xve[i]*60/(65536)); // 0-65536 a 0-60 metros
}
}
/////////////////
//// Controlador Roll
/////////////////
Ek_roll = Ref_roll - roll; // Se calcula el error
if(anti_roll == 1){ // Comprobación de anti Wind-Up
Ik_roll = Ik1_roll;
}else{
Ik_roll = Ik1_roll + Ek_roll; // Se actualiza integrador
}
Uk_roll = (Kp_roll * (Ek_roll + (((T_roll/1000)/Ti_roll)*Ik_roll) + (((Td_roll*1000)/T_roll)*(Ek_roll-
Ek1_roll)))); // Se halla actuación
Ik1_roll = Ik_roll; // Se actualizan valores de la iteración anterior para la siguiente iteración
Ek1_roll = Ek_roll;
/////////////////
//// Controlador Pitch
71
Desarrollo de un entorno Harware in the Loop para el AirWhale.
/////////////////
Ek_pitch = Ref_pitch - pitch;
if(anti_pitch == 1){
Ik_pitch = Ik1_pitch;
}else{
Ik_pitch = Ik1_pitch + Ek_pitch;
}
Uk_pitch = ((Kp_pitch)*(((Ek_pitch)) + (((T_pitch/1000)/(Ti_pitch))*(Ik_pitch)) +
(((Td_pitch*1000)/(T_pitch)*(Ek_pitch-Ek1_pitch)))));
Ik1_pitch = Ik_pitch;
Ek1_pitch = Ek_pitch;
/////////////////
//// Controlador Z
/////////////////
Ek_z = Ref_z - altura;
if(anti_z == 1){
Ik_z = Ik1_z;
}else{
Ik_z = Ik1_z + Ek_z;
}
Uk_z = ((Kp_z)*(((Ek_z)) + (((T_z/1000)/(Ti_z))*(Ik_z)) + (((Td_z*1000)/(T_z)*(Ek_z-Ek1_z)))));
Ik1_z = Ik_z;
Ek1_z = Ek_z;
/////////////////
//// Saturación y Anti WindUp
/////////////////
if(Uk_roll<-50){
Uk_roll = -50;
anti_roll = 1;
Anexo E
72
}else{
anti_roll = 0;
}
if(Uk_pitch<-60){
Uk_pitch = -60;
anti_pitch = 1;
}else{
anti_pitch = 0;
}
if(Uk_roll>50){
Uk_roll = 50;
anti_roll = 1;
}else{
anti_roll = 0;
}
if(Uk_pitch>60){
Uk_pitch = 60;
anti_pitch = 1;
}else{
anti_pitch = 0;
}
if(Uk_z>33){
Uk_z = 33;
anti_z = 1;
}else{
anti_z = 0;
}
if(Uk_z<0){
Uk_z = 0;
73
Desarrollo de un entorno Harware in the Loop para el AirWhale.
anti_z = 1;
}else{
anti_z = 0;
}
/////////////////
//// Conversión
/////////////////
PWM_motor1 = (((L1*(Uk_z)) - (2*Uk_pitch)) / (4*L1))+1700;
PWM_motor2 = (((L2*(Uk_z)) + (2*Uk_roll)) / (4*L2))+1700;
PWM_motor3 = (((L1*(Uk_z)) + (2*Uk_pitch)) / (4*L1))+1700;
PWM_motor4 = (((L2*(Uk_z)) - (2*Uk_roll)) / (4*L2))+1700;
/////////////////
//// Envío de datos
/////////////////
hal.console->printf("%f %f %f %f %f %f\n", PWM_motor1, PWM_motor2, PWM_motor3,
PWM_motor4, PWM_motor5, PWM_motor6);
}
}
AP_HAL_MAIN();
Anexo E
74
75
Desarrollo de un entorno Harware in the Loop para el AirWhale.
REFERENCIAS
[1] Javier Eduardo Mitjavila Samayoa, 'Diseño básico, Business Case y Prototipado Estructural del
AirWhale.' , 2015.
[2] Inmaculada Gómez Vázquez, 'Diseño y Cálculo de las Características Aerodinámicas y de Estabilidad de
un Dirigible Híbrido: Proyecto AirWhale.', 2015.
[3] Juan Carlos Mancebo Sánchez. Diseño 'Asistido por Ordenador del AirWhale y Cálculo Estructural de sus
alas. ', 2015
[4] http://jsbsim.sourceforge.net/
[5] http://wiki.flightgear.org/Main_Page
[6] Alejandro Romero Galán, 'Revisión y Modificación del Firmware de Libre Acceso ArdoCopter para su
uso en el Proyecto AirWhale.', 2015
[7] http://es.mathworks.com/
[8] Jose Luis Holgado Álvarez, 'Diseño,Construcción e implementación de controladores para seguimiento
de trayectorias del Porotipo AirWhale', 2015
Recommended