proyecto fin de grado grado en ingeniería de...

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

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


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


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


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


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

http://www.holycows.net/JSBSim/Building_JSBSim_with_Visual_C++.pdf

17


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

http://www.holycows.net/JSBSim_Script_Tutorial.pdf

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

http://jsbsim.sourceforge.net/aeromatic2.html


19


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


<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


<brake_group>LEFT </brake_group>

<retractable>{0</retractable>

</contact>

<contact type="STRUCTURE" name="LEFT_WING">


<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">


<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">


<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">


<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


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


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


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


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


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


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


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


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


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


Ilustración 6-4 – Esquema del prototipo del AirWhale

Modelo

44

45


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


</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


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


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 -

https://en.wikipedia.org/wiki/Luftschiffbau_Zeppelin

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


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


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


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


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


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


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


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


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()

{


}

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

////////////////////

///////////////////////////////////////////////////////////////////// Bucle principal

///////////////////////////////////////////////////////////////////////////////

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

////////////////////

void loop()

{

Anexo E

68

// Definiciones

float altura;

float PWM_motor1 = 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


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



}

// Se pilla el primer número (0-255)

dato1 = hal.console->read();



}

// Se pilla el segundo número (0-60)

dato2 = hal.console->read();



}

dato3=hal.console->read();



}

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


/////////////////

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


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


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

proyecto fin de grado grado en ingeniería de...

Documents