Control de vuelo y robótica

Vista previa del material en texto

Trabajo Fin de Grado
Control de vuelo para seguimiento de
trayectorias de un cuadricóptero
simulado mediante ROS/Gazebo
Autopilot for trajectory tracking of a
quadcopter simulated in ROS/Gazebo
Autora:
Maŕıa Ibáñez Rubio
Directores:
Rosario Aragüés Muñoz
Enrique Teruel Doñate
Grado en Ingenieŕıa Electrónica y Automática
Escuela de Ingenieŕıa y Arquitectura
Diciembre 2020
I
Resumen
Los cuadricópteros son uno de los robots aéreos más usados a d́ıa de hoy,
más comúnmente conocidos como drones. A causa de esto, la investigación y
desarrollo de sus tecnoloǵıas está en continuo crecimiento con el objetivo de
conseguir vuelos cada vez más autónomos. Al tratarse de tecnoloǵıas de un
elevado coste económico, en los primeros pasos de las investigaciones se hace
uso de simuladores. Esta alternativa, además de suponer una ventaja a nivel
económico, permite una experimentación más rápida y segura. Gazebo es uno
de los simuladores más usados en el ámbito de la investigación robótica y el
elegido para este proyecto. Para hacer posible su funcionamiento debe usar-
se ROS (Robot Operating System), cuya unidad fundamental son los nodos.
Son sus ejecutables y se organizan en paquetes. A lo largo del trabajo se ha
comprobado el potencial de su uso conjunto y con otros software muy usados
en el ámbito de la ingenieŕıa como Matlab.
El objetivo de este proyecto es el control del vuelo de un cuadricóptero simu-
lado siguiendo una trayectoria planificada. Para ello se han usado paquetes de
ROS, hector quadrotor, que modelan el comportamiento de un dron genérico
y su simulación. Para el control se ha desarrollado un módulo al que se supo-
ne la llegada externa de puntos planificados con una determinada separación
temporal que constituyen la trayectoria. Un algoritmo calcula la velocidad a
tomar por el dron en función de su posición y la planificación con una cier-
ta periodicidad. Esta velocidad es comunicada al modelado del dron, quien
efectúa los movimientos pertinentes.
Las simulaciones llevadas a cabo comprueban el correcto funcionamiento del
controlador implementado. El dron alcanza los objetivos en los tiempos espe-
rados con movimientos suaves y controlados. Además con ellas se han esta-
blecido las caracteŕısticas que han de tener los puntos planificados para que
aśı sea. Tanto los resultados como el análisis previo de las funcionalidades
del entorno de simulación pueden usarse en proyectos futuros con este mismo
tipo de aeronaves.
II RESUMEN
III
Índice de figuras
1.1. Izquierda: cuadricóptero de salvamento maŕıtimo. Derecha:
cuadricóptero comercial. . . . . . . . . . . . . . . . . . . . . . 1
1.2. Cuadricóptero desarrollado por Amazon. . . . . . . . . . . . . 2
1.3. Diagrama de Gantt de las tareas realizadas en el proyecto. . . 6
2.1. Logotipo de ROS. . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Esquema de comunicaciones entre nodos. . . . . . . . . . . . . 8
2.3. Logotipo de Gazebo. . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Logotipo de Matlab y Simulink. . . . . . . . . . . . . . . . . . 10
2.5. Visualización de hector quadrotor con sonar en Gazebo. . . . . 11
3.1. Ángulos de Euler en los ejes solidarios al cuadricóptero. . . . . 13
3.2. Diagrama de fuerzas del cuadricóptero. . . . . . . . . . . . . . 14
3.3. Esquema básico de control. . . . . . . . . . . . . . . . . . . . . 17
3.4. Trayectoria planificada mediante puntos intermedios. . . . . . 18
4.1. Interfaz gráfica de Gazebo. Hector quadrotor en un entorno
de demostración. . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Izquierda: Rviz. Derecha: terminal con nodo de telemanipula-
ción activado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Árbol de referencias. . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Grafo de nodos activos en la simulación de una demostración. 24
5.1. Esquema de controladores para el modelado del vuelo. . . . . 28
5.2. Modelado en Simulink para visualizar los datos de la simula-
ción ROS/Gazebo. . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3. Representación en 3D de las coordenadas espaciales del cua-
drado dibujado mediante el tema cmd vel. . . . . . . . . . . . 32
5.4. Coordenadas de posición reales (real) y deseadas (goal). Cua-
drado dibujado con /cmd vel. . . . . . . . . . . . . . . . . . . 33
5.5. Orientaciones reales (real) y deseadas (goal) o de reposo. Cua-
drado dibujado con /cmd vel. . . . . . . . . . . . . . . . . . . 34
IV ÍNDICE DE FIGURAS
5.6. Representación en 3D de las coordenadas espaciales del cua-
drado dibujado mediante action pose. . . . . . . . . . . . . . . 36
5.7. Coordenadas de posición reales (real) y deseadas (goal). Cua-
drado dibujado con action pose. . . . . . . . . . . . . . . . . . 37
5.8. Orientaciones reales (real) y deseadas (goal) o de reposo. Cua-
drado dibujado action pose. . . . . . . . . . . . . . . . . . . . 38
6.1. Esquema de controladores para el modelado del vuelo modifi-
cado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Interfaz gráfica de Gazebo. Hector posicionado en un mundo
vaćıo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3. Respuesta del controlador PID vz con Kp = 1. . . . . . . . . . 46
6.4. Respuesta del sistema con PID w con Kp = 1. . . . . . . . . . 47
6.5. Respuesta del sistema con PID vx con Kp = 1, siendo Kp = 1
en el controlador de la orientación. . . . . . . . . . . . . . . . 48
6.6. Respuesta del sistema con PID w con Kp = 15. . . . . . . . . 49
6.7. Respuesta del sistema con PID vx con Kp = 1, siendo Kp =
15 en el controlador de la orientación. . . . . . . . . . . . . . . 50
6.8. Respuesta del sistema con PID w con Kp = 15 y una corrección
de giro de π rad. . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.9. Respuesta del sistema ante vz superior a su valor máximo. . . 52
6.10. Respuesta del sistema ante vx superior a su valor máximo. . . 52
6.11. Representación en 3D de las coordenadas espaciales. Cuadrado
dibujado con el control desarrollado. . . . . . . . . . . . . . . 54
6.12. Coordenadas de posición reales (real) y deseadas (goal). Cua-
drado dibujado con el control desarrollado. . . . . . . . . . . . 55
6.13. Orientaciones reales (real) y deseadas (goal). Cuadrado dibu-
jado con el control desarrollado . . . . . . . . . . . . . . . . . 56
A.1. Interfaz de cliente para la acción pose de hector quadrotor. . . 66
C.1. Sensor láser Hokuyo UTM30LX. . . . . . . . . . . . . . . . . . 91
C.2. Datos publicados en el tema /scan. . . . . . . . . . . . . . . . 91
C.3. Simulación para medidas del láser en 7 puntos. . . . . . . . . . 92
V
Índice general
Índice de figuras I
Índice general VI
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Contexto de realización . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Objetivos y tareas . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . 4
2. Herramientas utilizadas 7
2.1. ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Gazebo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Matlab y Simulink . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Modelo de cuadricóptero . . . . . . . . . . . . . . . . . . . . . 10
3. Aspectos teóricos del cuadricóptero 13
3.1. Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Control de trayectoria y planificación . . . . . . . . . . . . . . 16
4. Hector quadrotor 19
4.1. Contenido del paquete . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Sensores en el hector . . . . . . . . . . . . . . . . . . . . . . . 25
5. Control de vuelo 27
5.1. Simulación del modelado matemático . . . . . . . . . . . . . . 27
5.2. Análisis de los modos de control . . . . . .. . . . . . . . . . . 29
5.2.1. Temas: /cmd vel y /command/twist . . . . . . . . . . 30
5.2.2. Acciones: Action pose . . . . . . . . . . . . . . . . . . . 35
5.2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . 39
6. Seguimiento de una trayectoria 41
6.1. Descripción del algoritmo de control . . . . . . . . . . . . . . . 41
6.2. Ĺımites de operación y ajuste del control . . . . . . . . . . . . 43
7. Conclusiones y trabajo futuro 57
7.1. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.2. Conclusión personal . . . . . . . . . . . . . . . . . . . . . . . . 58
7.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Bibliogrf́ıa 61
Anexos 63
A. Conceptos básicos ROS 63
A.1. Primeros pasos y herramientas básicas . . . . . . . . . . . . . 63
A.2. Nodos y comunicaciones . . . . . . . . . . . . . . . . . . . . . 64
A.2.1. Nodos suscriptores y publicadores . . . . . . . . . . . . 65
A.2.2. Nodos servidores y clientes . . . . . . . . . . . . . . . . 65
A.2.3. Parámetros . . . . . . . . . . . . . . . . . . . . . . . . 67
B. Código fuente de los nodos desarrollados 69
B.1. Conversor orientación de quaternio a ángulos de Euler . . . . . 69
B.2. Dibujo de un cuadrado . . . . . . . . . . . . . . . . . . . . . . 70
B.2.1. Nodo publicador del tema /cmd vel . . . . . . . . . . . 70
B.2.2. Nodo cliente de la acción pose . . . . . . . . . . . . . . 77
B.3. Control de trayectorias continuas . . . . . . . . . . . . . . . . 82
C. Lectura de datos recogidos por el láser Hokuyo UTM30LX 89
1
Caṕıtulo 1
Introducción
1.1. Motivación
Los cuadricópteros son los veh́ıculos aéreos no tripulados más comunes
hoy en d́ıa. Popularmente reciben el nombre de drones. En los últimos años
el uso de estas aeronaves ha crecido considerablemente. Inicialmente su uso
y desarrollo estuvo ligado al ámbito militar, hoy en d́ıa alcanza aplicaciones
de todo tipo. En la Fig. 1.1 se ilustran dos ejemplos de uso muy dispares.
El primero se trata de un dron que da apoyo a socorristas en playas, tanto
en tareas de salvamento como de vigilancia. En España han sido muy útiles
durante la crisis sanitaria originada por la COVID-19 facilitando el control
de aforos para garantizar la seguridad de los bañistas en muchas playas del
páıs [3]. Por otro lado, un cuadricóptero menos sofisticado y al alcance de
cualquier usuario, incorpora una cámara para realizar fotos y v́ıdeos durante
el vuelo, cuyo único fin es recreativo.
Figura 1.1: Izquierda: cuadricóptero de salvamento maŕıtimo. Derecha: cua-
dricóptero comercial.
2 CAPÍTULO 1. INTRODUCCIÓN
Otro ejemplo, más en sintońıa con este proyecto es el de la compañ́ıa Amazon,
Inc [4]. Actualmente está desarrollando un servicio de entrega con este tipo
de aeronaves de paquetes de un peso inferior a 2.3 kg, en menos de 30 minu-
tos y a un radio de 24 km de sus centros loǵısticos. Sus cuadricópteros son
autónomos y capaces de realizar vuelos en entornos dinámicos compartiendo
el espacio aéreo con cualquier otro usuario. En la Fig. 1.2 puede observarse
uno de los múltiples prototipos desarrollados para su servicio Prime Air. Es
la legislación la que impide implantar este tipo de tecnoloǵıas a d́ıa de hoy.
La Agencia Estatal de Seguridad Aérea (AESA) es la encargada de regular el
vuelo de drones en España, en el Real Decreto 1036/2017 del 15 de diciembre
se encuentra dicho reglamento.
Figura 1.2: Cuadricóptero desarrollado por Amazon.
En la actualidad el vuelo de un dron puede ser autónomo, sin necesidad de
supervisión, o remoto, controlado desde tierra por un piloto. En un mundo
cada vez más automatizado es el desarrollo del primero el que se encuentra en
auge. Para realizar un vuelo sin supervisión son necesarios datos del entorno
donde se lleva a cabo. Estos vuelos se realizan comúnmente con tecnoloǵıas
SLAM, Simultaneous Localization And Mapping. El cuadricóptero es capaz
de obtener datos del entorno en tiempo real y llevar a cabo el vuelo autónomo
en entornos desconocidos. El tratamiento de los datos es crucial para adap-
tar el vuelo a la aparición de obstáculos en la dirección de desplazamiento,
algo que no es posible cuando se realizan vuelos simplemente con trayecto-
rias planificadas. Las investigaciones en este campo actualmente se centran
en el desarrollo de algoritmos para mejorar el control durante el vuelo y la
optimización de los datos recogidos por los sensores.
1.2. CONTEXTO DE REALIZACIÓN 3
1.2. Contexto de realización
El presente trabajo se ha realizado dentro del departamento de Informáti-
ca e Ingenieŕıa de Sistemas de la Universidad de Zaragoza. Por otro lado se
ha contado con la experiencia de investigadores del Instituto de Ingenieŕıa
e Investigación de Aragón (I3A) con una amplia experiencia en este campo.
Se pretende que este proyecto sirva como gúıa para el desarrollo de otros
proyectos multi-robot de cuadricópteros, una de las lineas de investigación
de este departamento.
La simulación de robots es una manera rápida y económica de estudiar su
comportamiento. Cuando se trabaja con veh́ıculos aéreos no tripulados co-
mo en este caso, supone además una experimentación segura. El entorno de
simulación Gazebo/ROS (Robot Operating System) [1][6] usado en este pro-
yecto ofrece la posibilidad de controlar cualquier aspecto de la simulación,
por lo que es ampliamente empleado por la comunidad cient́ıfica en la expe-
rimentación con todo tipo de robots.
Por otro lado, el vuelo de drones para actividades de cierta relevancia, requie-
re una experiencia previa por parte del piloto y, dependiendo del peso de los
mismos, una licencia de vuelo. Con la simulación estas limitaciones carecen
de sentido. En el caso de vuelos autónomos la simulación es crucial para el
desarrollo de estas tecnoloǵıas. Permitiendo total versatilidad tanto en los
entornos como en las aeronaves y los componentes que incorporan. Además
de no ser necesario poseer f́ısicamente los robots para su estudio, algo muy
interesante en el ámbito de la enseñanza y la experimentación, contexto en
el que se desarrolla este proyecto.
1.3. Objetivos y tareas
El objetivo principal de este trabajo es el desarrollo o adaptación de
un simulador para un cuadricóptero. Se pretende simular un cuadricóptero
genérico de manera que los resultados obtenidos sean extrapolables a cual-
quier proyecto. Es por ello que el modelo debe ser configurable en cuestio-
nes tanto f́ısicas (peso, constantes aerodinámicas, etc) como de prestaciones
(sensores y actuadores) pudiendo adaptar la simulación a unas necesidades
concretas en todo momento. Como objetivo más concreto se llevará a cabo
el control de la trayectoria del cuadricóptero de manera continua durante su
vuelo. Dicho control hará que siga una trayectoria planificada previamente,
haciéndole cumplir las especificaciones espaciales y temporales fijadas por la
4 CAPÍTULO 1. INTRODUCCIÓN
misma. Se busca poder realizar un control a cualquier nivel.
Para llevar a cabo el trabajo se usará un entorno ROS/Gazebo, idóneo en
este caso como se verá a lo largo de la memoria, al tratarse de herramientas
creadas espećıficamente para el desarrollo y simulación de robots.
A continuación se enumeran las principales tareas realizadas:
1. Instalación, puesta en marcha y estudio básico de funcionamiento de
ROS y Gazebo.
2. Elección de cuadricóptero entre los existentes dentro del entorno ana-
lizando ventajas, inconvenientes y adaptación al proyecto.
3. Estudio teórico del modelado y control de cuadricópteros.
4. Análisis de prestaciones del cuadricóptero seleccionado para llevar a
cabo el control.
5. Diseño del control de vuelo. Estudio de alternativas, análisis y diseño
de algoritmos.
6. Experimentos para verificar el buen funcionamiento de lo desarrollado.
7. Elaboración de la documentación.
La organización temporal de estas tareas puede verse de manera aproximada
en el diagrama de Gantt de la Fig.1.3.
1.4. Contenido de la memoria
La siguiente memoria se estructura en 7 caṕıtulos complementados por
3 anexos. En el caṕıtulo 2 se describe el software usado para la realización
de este trabajo aśı como el modelo de cuadricóptero elegido. El caṕıtulo 3
detalla los fundamentos teóricos en los que se apoya el proyecto. Se presenta
el modelo matemático del cuadricóptero y la manera de realizar el control
de su trayectoria. En el caṕıtulo 4 se describen y detallan los aspectos más
relevantes sobre el paquete hector quadrotor obtenido en los repositorios de
GitHub [16]. En el caṕıtulo 5 se estudia el modelado del hector para la simu-
lación y las alternativas que ofrece para el control de su vuelo. Se desarrolla
una aplicación simple para apoyar el análisis. En el caṕıtulo 6 se describe
cómo se ha llevado a cabo el control para una trayectoria planificada con los
1.4. CONTENIDO DE LA MEMORIA 5
recursos del entorno de trabajo y los experimentos que comprueban el correc-
to funcionamiento. Por último, el caṕıtulo 7, reúne las conclusiones extráıdas
en el desarrollo del proyecto. El primer anexo detalla los conceptos básicos
de ROS, se explican algunas de las herramientas usadas o la manera de llevar
a cabo las comunicaciones. En el segundo anexo se recoge el código fuente
desarrollado a lo largo del proyecto. El último apoya una de las alternativas
expuestas para un trabajo futuro.
6 CAPÍTULO 1. INTRODUCCIÓN
Figura 1.3: Diagrama de Gantt de las tareas realizadas en el proyecto.
7
Caṕıtulo 2
Herramientas utilizadas
2.1. ROS
ROS [1] es un sistema operativo robótico que facilita el desarrollo de soft-
ware relacionado con aplicaciones robóticas. Está formado por un conjunto
de herramientas y bibliotecas todas ellas de código abierto. Desde su crea-
ción en Mayo de 2007 bajo el nombre de switchyard por el Laboratorio de
Inteligencia Artificial de Stanford no ha dejado de evolucionar de manera
colaborativa lo que supone una de sus principales ventajas.
Figura 2.1: Logotipo de ROS.
Es importante tener claros los conceptos principales de ROS aśı como su
funcionamiento básico previamente a cualquier implementación [2] [5]. Todo
el software del sistema se organiza a través de paquetes, estos contienen bi-
bliotecas y ejecutables entre otras cosas. A los ejecutables se les denomina
nodos y son la unidad fundamental dentro de ROS. El funcionamiento del
sistema se basa en la comunicación de dichos nodos que puede ser de tres
tipos. Se habla de nodos publicadores o suscriptores cuando el intercambio
de mensajes se hace entre varios nodos a través de temas (topics) . Los nodos
también se pueden comunicar a través de servicios o acciones. En estos tipos,
la comunicación es exclusivamente entre dos nodos que se desconectarán una
vez esta termine.
Para que cualquiera de estas comunicaciones sea posible debe existir un maes-
tro. Es el encargado de que los nodos se encuentren e intercambien dichos
8 CAPÍTULO 2. HERRAMIENTAS UTILIZADAS
mensajes. El maestro fija una serie de parámetros, variables globales, que de-
finen a cada uno de los nodos. A los parámetros se les puede considerar otro
tipo de comunicación. Un esquema de estas comunicaciones puede observarse
en la Fig. 2.2.
En el anexo A se encuentran detallados los primeros pasos para el inicio
del entono aśı como una descripción detallada de cada una de estas comuni-
caciones.
La versión de ROS usada en este proyecto es Kinetic Kame. Fue lanzada
en el 2016 y es la versión más antigua de las estables en funcionamiento.
Figura 2.2: Esquema de comunicaciones entre nodos.
2.2. Gazebo
Gazebo [6] será usado como software de simulación. Se trata de una po-
tente herramienta para la recreación de entornos y robots. Permite tanto el
uso de bibliotecas de modelos de ambos elementos como su diseño. Una de las
principales ventajas es que Gazebo está creado a través de paquetes de ROS
lo que hace que su uso conjunto sea muy satisfactorio. Con este software se
puede estudiar el comportamiento de un cuadricóptero en un determinado
entorno que sea de interés tanto a nivel dinámico como cinemático. Gazebo
ofrece una simulación muy realista de los entornos y el comportamiento de
robots en ellos. Para ROS Gazebo será como un nodo más pudiéndose dar
2.3. MATLAB Y SIMULINK 9
cualquier tipo de comunicación de las anteriormente citadas entre ellos. Los
plugins son los encargados de realizar esta comunicación, se definen como
bibliotecas a insertar en la simulación. Con estos elementos se consigue un
mejor control sobre Gazebo y al tratarse de bibliotecas son fáciles de com-
partir, añadir y eliminar en las simulaciones.
Cuando se lleva a cabo una simulación dentro de Gazebo es el simulador
quien marca el tiempo de la misma. El Real Time Factor, dato proporciona-
do en la interfaz visual de Gazebo, indica como de buena es la simulación y
la relación entre el tiempo real y el marcado, siendo 1 el caso óptimo. Nor-
malmente tomará valores en torno a 0.90 lo que hace que el tiempo de la
simulación sea más lento que el real. El valor de este factor depende, entre
otras cosas, de la complejidad del entorno y del robot simulado, a más com-
plejidad menor valor.
La versión de Gazebo es la 7.16.0 ya que es la que mejor se adapta a la
versión de ROS usada. Cabe decir que el realismo visual de la simulación
depende en parte del hardware usado, en este caso la tarjeta gráfica que se
posee no permite una visualización del todo realista pero no compromete
ningún otro aspecto.
Figura 2.3: Logotipo de Gazebo.
2.3. Matlab y Simulink
Matlab [7] es un potente software matemático de uso muy extendido en
el ámbito de la enseñanza, la investigación y empresarial. Dentro de él se
incluye Simulink [8], un entorno de programación visual. Estas herramientas
se usarán para la recogida y visualización de datos de la simulación, dada
la facilidad de conexión entre ROS y Simulink y el valor añadido que le
aporta su uso al proyecto. No obstante no es imprescindible. ROS incluye
herramientas para estas tareas: rqt plot para la visualización y rqt bag para
10 CAPÍTULO 2. HERRAMIENTAS UTILIZADAS
la recogida de datos.
Para ROS Simulink será un nodo más. Dentro de la libreŕıa de Simulink
Simulink Library Browser y concretamente en ROS se encuentran implemen-
tados bloques para efectuar las conexiones. La recogida y visualización de
datos será sencilla con el uso de bloques suscriptores a los temas de interés
como se verá a lo largo de la memoria. A diferencia de las herramientas ofre-
cidas por ROS se pueden efectuar las dos tareas en un mis mismo paso y
para todos los datos que se consideren de interés.
Figura 2.4: Logotipo de Matlab y Simulink.
La versión de Matlab que se ha usado es la R2018b.
2.4. Modelo de cuadricóptero
ROS ofrece la posibilidad de trabajar con robots aéreos no tripulados
tanto en simulación como apoyando el manejo real de estos. Algunos de ellos
son Gapter, Crazyflie o Erle-Copter. Por otro lado dentro de ROS también se
encuentra el paquete hector quadrotor [9] que permite el modelado, control
y simulación de un dron genérico que no se basa en ninguno existente en
el mercado. Fue desarrollado por Institute of Flight Systems and Automatic
Control, en Technische Universität Darmstadt.
Entre los objetivos de este trabajo no se encuentra la implementación real,
por eso se busca el cuadricóptero que ofrezca las mejores prestaciones en
cuanto a simulación y control dentro de los software a usar, ROS y Gazebo.
Para la toma de esta decisión fue esencial el asesoramiento de investigadores
del Instituto de Ingenieŕıa e Investigación de Aragón (I3A), y concretamen-
te del grupo de investigación ”Robotics, Perception and Real Time Group”
[10] dada su experiencia en el desarrollo de otros proyectos con robots tanto
aéreos como terrestres [11]. Se optó finalmente por el uso del paquete hector
quadrotor, su modelado es muy similar a cualquiera delos que existen en el
mercado, y por ello no habŕıa dificultades en la extrapolación de este trabajo.
Adicionalmente al paquete principal, existen otros que modelan funcionali-
dades para este cuadricóptero o para cualquier otro robot, como es el caso
2.4. MODELO DE CUADRICÓPTERO 11
del paquete hector slam. Esto supone que su uso sea muy común por lo que
existe numerosa documentación en la que apoyar este proyecto. Su desarrollo
está en continuo crecimiento y como cualquier componente de ROS es de
código abierto. A lo largo de la memoria se estudiará el funcionamiento de
este cuadricóptero y las funcionalidades que ofrece.
Figura 2.5: Visualización de hector quadrotor con sonar en Gazebo.
12 CAPÍTULO 2. HERRAMIENTAS UTILIZADAS
13
Caṕıtulo 3
Aspectos teóricos del
cuadricóptero
3.1. Modelado
La parte más relevante del modelado de un cuadricóptero es el movi-
miento de sus hélices y como este tiene lugar [12][13]. Dos giran en sentido
de las agujas del reloj y en sentido opuesto las otras dos. Esto hace posibles
los movimientos de elevación, balanceo, cabeceo y giro. Los tres últimos se
relacionan con los ángulos de Euler roll, pitch y yaw respectivamente, giros
sobre los ejes X, Y y Z del dron, Fig. 3.1.
Figura 3.1: Ángulos de Euler en los ejes solidarios al cuadricóptero.
Como puede observarse en la Fig. 3.2 el movimiento de la hélice da lugar a
una fuerza en la dirección positiva del eje Z y es el sumatorio de las cuatro el
que da lugar al movimiento del dron. F1 y F3 son las fuerzas correspondien-
tes a los motores que giran en sentido antihorario y F2 y F4 las de los que
14 CAPÍTULO 3. ASPECTOS TEÓRICOS DEL CUADRICÓPTERO
lo hacen en sentido horario. Una variación de altitud implica que todas las
fuerzas tengan el mismo valor. En el balanceo se mantienen constantes las
fuerzas F1 y F3 y se vaŕıan F2 y F4 el mismo valor pero de manera inversa.
Y de la misma manera para el cabeceo pero dejando constantes F2 y F4. Por
último si se eleva F1 y F3 y se disminuye F2 y F4 el dron girará sobre su eje
Z.
Figura 3.2: Diagrama de fuerzas del cuadricóptero.
Partiendo de estas ideas acerca de como se produce el movimiento se procede
al modelado cinemático en función de su posición. En primer lugar se define
su posición lineal y angular en el sistema de coordenadas inerciales, ξ y η
respectivamente. Siendo q el vector con el que se definen ambas de manera
conjunta, (3.1). Sobre el dron y en su centro de masas se definen las coor-
denadas no inerciales del cuerpo que darán lugar a dos nuevos vectores para
la posición lineal y angular, su derivada será la velocidad VB y ν respectiva-
mente, (3.2).
ξ =
xy
z
 η =
φθ
ψ
 q =
[
ξ
η
]
(3.1)
VB =
vx,Bvy,B
vz,B
 ν =
p
q
r
 (3.2)
La relación entre bases se define con la matriz de rotación R y Wη para
una transformación más concreta, el paso de velocidades angulares entre
3.1. MODELADO 15
coordenadas inerciales y no inerciales, (3.3). Ambas se componen de senos y
cosenos y son matrices 3x3.
ν = Wnη̇, ν =
1 0 −Sθ
0 Cφ CθSφ
0 −Sφ CθCφ
φ̇θ̇
ψ̇
 (3.3)
Por otro lado se asume que el dron es simétrico en el plano XY y por lo tanto
su tensor de inercia será una matriz diagonal, (3.4), con Ixx = Iyy. Por último
se definen las fuerzas y los momentos que ocasionan cada uno de los motores.
La fuerza es igual al producto de la constante de sustentación k y la velocidad
angular del motor wi al cuadrado, esta fuerza aparece en la dirección del eje
de giro del motor y recibe el nombre de empuje, (3.5). El momento tiene
dos contribuciones. Una debida a la inercia, aunque su bajo valor hace que
sea despreciable, y otra debida al producto de la constate de arrastre b y
la velocidad angular del motor wi al cuadrado, (3.6). Todas estas fuerzas y
momentos se dan en el eje Z. En el caso de los momentos en las componentes
que corresponden a φ y θ, giro entorno los ejes X e Y respectivamente. Su
valor será el producto de la suma de las velocidades angulares al cuadrado de
los motores perpendiculares a esos ejes por k y l, distancia entre el motor y el
centro de masas. El signo menos se debe a que los motores giran en sentidos
opuestos. Las ecuaciones de los momentos ilustran lo que ya se ha explicado
al principio de esta sección, dependiendo de la variación de las velocidades de
los motores se ocasiona el balanceo, el cabeceo o el movimiento de guiñada
(Row, Pitch, Yaw) o la elevación.
I =
Ixx 0 0
0 Iyy 0
0 0 Izz
 (3.4)
fi = kwi
2 −→ T =
4∑
i=1
fi = k
4∑
i=1
wi
2 (3.5)
τMi
= IM ẇi + bwi
2 −→ τψ =
4∑
i=1
τMi
= b
4∑
i=1
wi
2 (3.6)
TB =
0
0
T
 τB =
lk(−w2
2 + w2
4)
lk(−w2
1 + w2
3)
τψ
 (3.7)
16 CAPÍTULO 3. ASPECTOS TEÓRICOS DEL CUADRICÓPTERO
Para explicar la dinámica del cuadricóptero se usa el modelo de Newton-
Euler o Euler-Lagrange. En el primero la suma del empuje de los motores y
la acción de la gravedad serán igual a la suma del peso y la fuerza centŕıfuga,
si se trabaja en ejes inerciales esta será nula, (3.8) y (3.9) coordenadas del
cuerpo e inerciales respectivamente. En el segundo se define el lagrangiano
como la suma de la enerǵıas traslacional y rotacional menos la potencial,
(3.10) y (3.11).
mV̇B + ν(mVB) = RTG+ TB (3.8)
mξ̈ = G+RTB (3.9)
L(q,q̇) = (m/2)ξ̇T ξ̇ + (1/2)νT Iν −mgz (3.10)[
f
τ
]
=
d
dt
(
∂L
∂q̇
)
− ∂L
∂q
(3.11)
El modelado del vuelo del cuadricóptero en la simulación se basa en el mo-
delado matemático desarrollado en esta sección. Se explicará de manera más
detallada en el caṕıtulo 5.
3.2. Control de trayectoria y planificación
Con el control de la trayectoria de un cuadricóptero se busca llevarlo desde
una posición origen a una posición destino deseada. El origen del movimiento
del dron está en sus motores y en la velocidad angular que producen sobre
las hélices del mismo. Teniendo un control sobre dicha velocidad, el momento
y el empuje resultantes también estarán controlados y en consecuencia las
velocidades angulares y lineales de la aeronave. La posición y orientación se
pueden obtener a través de las derivadas de la velocidad lineal y angular
respectivamente. Las funciones que modelan el sistema relacionan todas las
variables citadas anteriormente como se ha visto en la sección anterior, lo que
hace posible un control del vuelo usando cualquiera de ellas, o dicho de otro
modo a cualquier nivel. El nivel más bajo supone actuar sobre los motores,
variando su tensión en función del movimiento deseado. En los niveles más
altos se sitúan los controles que actúan sobre las velocidades del dron para
variar la posición y orientación. En cualquier caso, el esquema de control será
similar al ilustrado en la Fig. 3.3. El sistema a controlar es el cuadricóptero y
las entradas a este serán las tensiones aplicadas sobres sus motores. El resto
3.2. CONTROL DE TRAYECTORIA Y PLANIFICACIÓN 17
de elementos del esquema dependerán del nivel al que se decida realizar el
control. En el caso de hacerse a un alto nivel la diferencia entre la posición
actual y deseada será entrada al controlador que calcule las acciones sobre
el sistema. Un sensor será el encargado de medir la posición actual del cua-
dricóptero. El controlador puede ser desde un simple PID a algoritmos de
control más sofisticados. Como se verá a lo largo de la memoria los paquetes
del hector traen implementados ciertos controles.
Figura 3.3: Esquema básico de control.
En la realidad el vuelo del cuadricóptero se ve afectado por efectos no ideales,
como pueden ser la fuerza de arrastre que se genera por la resistencia del aire
o la dependencia del empuje del ángulo de ataque. Incluir estos efectos en
el modelado harán que sea más fiel al comportamiento real de la aeronave
durante el vuelo. En muchos cosas estos efectos no son sencillos de modelar
y llevarlos a un simulador como es el caso.
En la f́ısica se define trayectoria como el lugar geométrico de las posiciones
sucesivas por las que pasaun cuerpo durante su movimiento [14]. Se habla
de trayectorias continuas como aquellas calculadas a partir de las especifica-
ciones del usuario para generar unos movimientos concretos y controlados en
tiempo real. Por lo tanto, junto con el control es necesario el cálculo o defi-
nición de los puntos intermedios. En la Fig. 3.4 se ilustra esta idea. Existen
múltiples métodos para planificar una trayectoria, depende de los objetivos
de la misma. Los algoritmos de planificación más simples tratan de mover
un dron, o cualquier otro robot, en el espacio libre del entorno teniendo en
cuenta las limitaciones del movimiento inherentes en los mismo. Un ejemplo
en este caso seŕıa los splines usados con robots articulados industriales. Al-
goritmos más sofisticados llevan al dron hasta un destino dado evitando los
obstáculos que se puedan dar durante su trascurso. Y aún más lo son aquellos
capaces de evitar obstáculos dinámicos [15].
18 CAPÍTULO 3. ASPECTOS TEÓRICOS DEL CUADRICÓPTERO
Este proyecto se centrará exclusivamente en el control de la velocidad del
cuadricóptero para el seguimiento de una trayectoria. Se supondrá que al
módulo de control llegan puntos intermedios previamente definidos en un
módulo de planificación y que son totalmente válidos. Un primera definición
de los puntos intermedios puede ser la composición de la posición y orien-
tación deseada del dron y el tiempo que emplea en llegar hasta ellos desde
sus condiciones de posición y orientación iniciales. Esta definición podrá ser
distinta una vez que se defina el algoritmo de control. Dichos puntos deben
ubicarse en el espacio libre de su alrededor y el desplazamiento hacia ellos
debe hacerse de manera segura y en un tiempo determinado, la condición
temporal lleva impĺıcita la velocidad a la que debe efectuarse el mismo.
Figura 3.4: Trayectoria planificada mediante puntos intermedios.
19
Caṕıtulo 4
Hector quadrotor
4.1. Contenido del paquete
El paquete hector quadrotor desarrollado por Stefan Kohlbrecher y Johan-
nes Meyer, siendo este último el encargado de su mantenimiento, está dividido
en una serie de subpaquetes que describen el modelado, control y simulación
de veh́ıculos aéreos no tripulados de cuatro motores. A continuación se enu-
meran y describen cada uno de ellos.
1. hector quadrotor description: contiene el modelo básico y variantes con
diferentes sensores.
2. hector quadrotor gazebo: contiene lo necesario para la simulación en
Gazebo.
3. hector quadrotor teleop: contiene lo necesario para el uso de joysticks
externos que manejan el quadrotor en la simulación.
4. hector quadrotor gazebo pluging : contiene complementos espećıficos pa-
ra la simulación del comportamiento del cuadricóptero en Gazebo.
5. hector quadrotor actions : se encuentran implementados comportamien-
tos del cuadricóptero (despegue, aterrizaje y posicionamiento) a través
de acciones.
6. hector quadrotor controller gazebo: contiene implementada la interfaz
ros contol RobotHWSim, este tipo de objetos simulan hardware del
robot, concretamente aqúı se simula el controlador.
7. hector quadrotor controllers : en él se describen los controladores básicos
para definir el modelado matemático de la aeronave.
20 CAPÍTULO 4. HECTOR QUADROTOR
8. hector quadrotor demo: contiene demostraciones del funcionamiento de
los paquetes.
9. hector quadrotor interface: en él se describen bibliotecas y nodos para
el control del cuadricóptero.
10. hector quadrotor model : en él se encuentran bibliotecas que modelan
aspectos del modelado matemático como puede ser las constantes ae-
rodinámicas.
11. hector quadrotor pose estimation: este paquete proporciona un nodo
y un conjunto de nodos, nodelet. Estima los 6 grados de libertad del
cuadricóptero con un filtro de Kalman extendido (EKF) a través de las
mediciones de varios sensores.
12. hector uav msgs : en él se describen tipos de mensajes que sirven para
el controlador del cuadricóptero además de algunos necesarios para la
recogida de datos de sensores que no se recogen en el paquete especifico
dentro de ROS para este fin (sensor msgs).
Dentro de los paquetes principales no se describen otros aspectos necesarios
para la simulación como por ejemplo el entorno. Es por eso que es necesario
añadir otros que lo complementen. A continuación se enumeran y describen
cada uno de ellos.
1. hector gazebo: contiene paquetes en los que se describen entornos y
complementos para la simulación en Gazebo.
2. hector localization: es un conjunto de paquetes que tienen implemen-
tados nodos capaces de obtener los 6 grados de libertad del dron o
cualquier otro robot.
3. hector models : contiene paquetes que describen el modelo componentes
de robots y sensores en archivos .urdf (Universal Robotic Description
Format).
4. hector slam: contiene paquetes relacionados con la navegación.
Todos los paquetes descritos y usados en este proyecto se han obtenido de
los repositorios de GitHub [16].
4.2. FUNCIONAMIENTO 21
4.2. Funcionamiento
El primer paso, tanto para entender el funcionamiento como para compro-
bar la correcta instalación, es lanzar las demostraciones que trae implemen-
tadas. Están descritas en archivos .launch con nombres indoor slam gazebo
y outdoor flight gazebo. Para lanzar las demostraciones usamos el comando
roslaunch como se explica en el anexo A.1. Tras esto se abre Gazebo y RViz,
una herramienta de visualización 3D que incluye ROS, Fig. 4.1 y Fig. 4.2.
RViz es útil para la visualización de datos recogidos de la simulación, por
ejemplo los de sensores. En este paso se inicia el entorno de simulación, se
posiciona a hector en él y se activa dos nodos para la telemanipulación a
través de un joystick: joy y teleop. Este último descrito dentro del paquete
hecto quadrotor teleop. Se opta por el uso de otro paquete de ROS, teleop
twist keyboard, que permite la telemanipulación a través de la consola y el
teclado sin necesidad de mandos externos. En cualquier caso se deben habi-
litar los motores mediante la llamada a su servicio previamente:
rosservice call /enable motors "enable: true"
rosrun teleop twist keyboard teleop twist keyboard.py
De estas demostraciones se extrae el esquema básico a seguir para cualquier
simulación futura.
1. Inicio del entorno y posicionamiento del cuadricóptero en este.
2. Activación de los motores.
3. Activación de los nodos que ejecuten una tarea concreta, en este caso
la telemanipulación.
Para llevar a cabo el control de la trayectoria se activaŕıa uno o varios no-
dos, previamente descritos, que realizarán la función manteniendo constantes
siempre que sea posible el resto de pasos.
La activación del nodo rqt graph muestra un grafo de los nodos y temas acti-
vos durante la simulación. En la Fig. 4.4 se puede observar el grafo de una de
las demostraciones. El grafo de cada simulación es único, aunque con nodos
comunes encargados del funcionamiento básico. Con ayuda de las herramien-
tas descritas en el anexo anteriormente citado para obtener información sobre
los nodos, se buscará la manera de controlar el hector con temas, servicios o
acciones descritas en él.
22 CAPÍTULO 4. HECTOR QUADROTOR
Todas las simulaciones con hector quadrotor comparten los nodos básicos a los
cuales se pueden sumar otros con prestaciones más especificas como por ejem-
plo el uso de un joytick o la telemanipulación por pantalla. A continuación se
detalla cada uno de los nodos básicos activados en una simulación genérica.
Se activan a través de la llamada del archivo spawn quadrotor.launch.
Figura 4.1: Interfaz gráfica de Gazebo. Hector quadrotor en un entorno de
demostración.
Figura 4.2: Izquierda: Rviz. Derecha: terminal con nodo de telemanipulación
activado.
Robot state publisher. Pertenece al paquete con su mismo nombre. Su
función es publicar el estado de un robot en tf, facilitando el trabajo con
múltiples sistemas de coordenadas. Tf hace un seguimiento de la variación4.2. FUNCIONAMIENTO 23
de todas las referencias en el tiempo de manera que cualquier otro componen-
te de ROS puede acceder a ella y saber el posicionamiento del cuadricóptero
en un determinado momento.
El tipo de dato de tf es geometry msgs/PoseStamped. Estos datos incluyen
por un lado un header, el encabezamiento en el que está el tiempo y la re-
ferencia de coordenadas, y por otro la posición, compuesta a su vez por un
cuaternio, para la orientación, y coordenadas.
Ground truth to tf. Este nodo pertenece al paquete message to tf. Se
encarga de traducir mensajes, la posición y orientación a tf concretamente.
A través de un argumento bool, use ground truth for tf, se puede elegir la
referencia absoluta para la traducción. Por defecto es true lo que quiere de-
cir que la referencia del robot parte de la absoluta de la simulación. Debe
ser falsa cuando se quiere trabajar con más de un robot. Activando el nodo
view frames dentro de paquete tf se genera un archivo pdf con el árbol de
referencia de la simulación. En la Fig. 4.3 se puede observar el árbol de refe-
rencias para una simulación en la que el parámetro es falso.
Este nodo es útil ya que publica la posición y la orientación del cuadricóptero
respecto a la referencia absoluta.
Figura 4.3: Árbol de referencias.
Pose estimation. Este nodo pertenece al paquete hector quadrotor pose es-
timation y su función es estimar la posición y coordendas del cuadricóptero
basándose en las mediciones de ciertos sensores. Su uso depende del valor
de un argumento bool, use ground truth for control, el cual da valor a otro,
pose estimation. Por defecto son true y false respectivamente por lo que el
nodo no se activa.
24 CAPÍTULO 4. HECTOR QUADROTOR
Dentro de spawn quadrotor.launch se hace llamada a controller.launch donde
se activan los siguientes nodos.
Controller spawer. Este nodo pertenece al paquete controller manager.
Proporciona toda la estructura necesaria para interactuar con los controla-
dores, con él se pude cargar, descargar, iniciar y detener a los mismos. Los
controladores se definen en archivos .yaml. Hector tiene definidos tres: posi-
tion, velocity y attitude.
Estop relay. Este nodo pertenece al paquete topic tools de tipo relay. Es
necesario para el control. Se encarga de retransmitir datos.
De la misma manera que en el caso anterior con la llamada al archivo ac-
tions.launch se activan los siguientes nodos.
Pose action, landing action y takeoff action. Todos pertenecen al paque-
te hector quadrotor actions y definen tres comportamientos del cuadricóptero:
el aterrizaje, el despegue y el movimiento a una determinada posición. Sus
mensajes son acciones por lo que se habla de clientes y servidores. Landing
action y takeoff action son clientes de pose action, el servidor. En el anexo
A.2.2 se explica con más detalle este tipo de comunicación.
Por último, estos nodos se activan como consecuencia de la llamada a start.launch
para iniciar el entorno de simulación.
Gazebo y gazebo gui Ambos pertenecen al paquete gazebo ros, son nece-
sarios para la comunicación entre ROS y el entorno de simulación Gazebo.
Figura 4.4: Grafo de nodos activos en la simulación de una demostración.
4.3. SENSORES EN EL HECTOR 25
4.3. Sensores en el hector
El modelo básico de hector quadrotor viene provisto de un sonar para
medir la altura del vuelo. Es posible variar su posición y parámetros en el
archivo quadrotor base.urdf. Publica en el tema /sonar height datos del tipo
sensor msgs/Range.
El resto de sensores que posee son plugins de Gazebo, complementos que
añaden funcionalidades a la simulación. Están descritos en el archivo qua-
drotor sensors.gazebo.xacro, son los siguientes:
1. IMU (Inertial Measurement Unit). El nombre del plugin es quadro-
tor imu sim, publica en el topic /raw imu mensajes del tipo
sensor msgs/Imu que contiene la orientación, la velocidad angular, la
aceleración linear y la covarianza de cada una de estas. Este sensor se
compone de acelerómetros y giróscopos que miden velocidad, orienta-
ción y fuerzas de gravedad actuantes. Se usa para el posicionamiento.
2. Barómetro. El nombre del plugin es quadrotor baro sim, publica en el
topic /pressure height mensajes del tipo geometry msgs/PointStamped.
Mide la presión atmosférica. Permite conocer la altura del vuelo con
gran precisión.
3. Magnetómetro. El nombre del plugin es quadrotor magnetic sim, pu-
blica en el topic /magnetic mensajes del tipo
geometry msgs/Vector3Stamped. Mide fuerzas magnéticas para cono-
cer la orientación en la superficie terrestre.
4. GPS. El nombre del plugin es quadrotor gps sim, publica la posición en
el topic /fix, mensajes del tipo geometry msgs/NavSatFix, y la veloci-
dad en /fix velocity, mensajes del tipo geometry msgs/Vector3Stamped.
Posiciona el cuadricóptero de manera más precisa que el IMU.
A este listado es posible añadir otros si fuera necesario en la aplicación a
desarrollar. En el paquete hector models se encuentra la descripción de otros
sensores que es posible usar como láseres o cámaras. El hector ilustrado en
la Fig. 2.5 trae incorporado un láser en la parte inferior de su chasis.
26 CAPÍTULO 4. HECTOR QUADROTOR
27
Caṕıtulo 5
Control de vuelo
5.1. Simulación del modelado matemático
El modelo matemático descrito en el caṕıtulo 3 explica como se produce
el vuelo de un cuadricóptero. Para su modelado en la simulación de hector
quadrotor se define el paquete hector quadrotor controllers. Dentro de este se
encuentra descrito el modelo como un plugin de Gazebo cuyo contenido son
tres controladores: position, velocity y attitude. Dichos controladores actúan
en cascada y en ese orden siendo su salida final el empuje y los momentos
que provocan el movimiento del cuadricóptero [17]. En la Fig. 5.1 se esque-
matiza este modelado de manera simplificada. Las flechas azules representan
las formas incidir externamente al plugin, a través de los temas /cmd vel o
/command/twist a los que está suscrito Gazebo o con la acción pose descri-
ta en otros paquetes. La comunicación entre los controladores tiene lugar a
través de parámetros internos. Cada uno de los controles está formado in-
ternamente por controladores proporcionales, integrales y derivativos cuyos
parámetros están descritos en el mismo paquete, archivo controller.yaml. Las
constantes derivan de los parámetros intŕınsecos de los motores o la aero-
dinámica del cuadricóptero estudiada con modelos de cuadricópteros reales.
Carece de sentido modificar los valores de cualquiera de ellos. Para el se-
guimiento de trayectorias o cualquier otra tarea deberá hacerse un control a
un nivel superior. El controlador de posición por su parte no modela ningún
aspecto f́ısico real. Se trata de un simple proporcional en el que se calcula la
velocidad en función del error de posición, podŕıa resultar interesante modi-
ficarlo para variar los resultados.
28 CAPÍTULO 5. CONTROL DE VUELO
Figura 5.1: Esquema de controladores para el modelado del vuelo.
Se usará la herramienta Simulink para la recogida y análisis de datos durante
todo el trabajo. En la Fig. 5.2 se puede observar el diagrama de bloques en-
cargado de recoger los datos de la simulación que posteriormente se tratarán
en Matlab. En la parte izquierda se encuentran los bloques suscriptores a
temas de ROS pero es el inspector de datos de la simulación quien se encar-
ga de recabar los indicados por los śımbolos azules de la parte derecha. En
cualquier simulación realizada en este proyecto interesa conocer la posición
y orientación del dron real frente a la deseada en función del tiempo, los
cuatro bloques centrales se suscriben a los temas que publican estos datos.
La posición, en cualquier caso, se representa por un punto en IR3 y la orien-
tación mediante los ángulos de Euler Yaw, Pitch y Roll. Para visualizar los
ángulos de Euler se ha implementado previamente un nodo, Quaternion to
Euler, que publica la orientación dada por elnodo ground truth to tf , en
forma de cuaternio, como dichos ángulos. Los cuaternios transformados en
ángulos de Euler toman valores entre 0 y π radianes positivos o negativos,
cuando se supera el valor π el ángulo pasa a ser negativo e incrementa su
valor hasta hacerse 0. El código fuente de este nodo se encuentra en el anexo
B.1. El bloque final se subscribe al reloj de Gazebo. Como ya se ha explica-
do en la sección 2.2 el simulador marca el tiempo y depende de factor Real
Time que coincida con el tiempo real. Además el valor de dicho factor no es
constante por lo que se estaŕıan obteniendo relaciones temporales erróneas
aún habiendo configurado los parámetros de simulación en Simulink. El ini-
cio de la simulación en Gazebo y Simulink no es simultaneo, lo que equivale
a otra fuente de error temporal. Por todo ello es imprescindible recoger las
lecturas del reloj para proceder al tratamiento y extracción de conclusiones
sobre cualquier variable. Puede ser interesante recoger datos de la velocidad
que se le está indicando externamente, si es el caso, el primer bloque estará
suscrito a este tema.
Con el fin de encontrar la manera idónea de controlar el cuadricóptero pa-
5.2. ANÁLISIS DE LOS MODOS DE CONTROL 29
ra desarrollar el objetivo principal de este proyecto, el control continuo de
trayectorias, se realizará un análisis de ambos modos de control disponibles,
temas y acciones. El control ha de permitir llevar al cuadricóptero desde su
posición a un destino en un determinado tiempo. En la siguiente sección se
procede al análisis.
Figura 5.2: Modelado en Simulink para visualizar los datos de la simulación
ROS/Gazebo.
5.2. Análisis de los modos de control
En simulaciones de robots en entornos Gazebo/ROS el dibujo de un
poĺıgono es una de las demostraciones que más se repite. Como ejemplos se
30 CAPÍTULO 5. CONTROL DE VUELO
han usado implementaciones en Turtlesim [18], paquetes desarrollados para
facilitar el aprendizaje de ROS. Se realizará el dibujo de un cuadrado durante
el vuelo a través de un nodo que publique mensajes en uno de los temas o
sea cliente de las acciones. Con este análisis se busca encontrar la manera de
controlar la trayectoria de manera continua además de la familiarización con
el entorno de trabajo y la escritura de nodos.
En cualquiera de las alternativas las posiciones deseadas serán las referencias
del control. En este caso concreto se busca la manera de indicar al cua-
dricóptero que ascienda hasta una determinada altura, concretamente 2 m,
y manteniéndola dibujar un cuadrado, de 3 m de lado, en el plano XY de
la referencia absoluta. Además dichos movimientos deben realizarse en un
tiempo dado. Para conocer la posición y orientación real se usará el tema
/ground truht to tf/pose, en el que se publica dicha información. El avance
del cuadricóptero debe hacerse en la dirección positiva de su eje X, coinciden-
te con su brazo rojo Fig. 2.5, por lo que también será necesaria la orientación
durante el vuelo. Dado que se está trabajando entre dos referencias, la abso-
luta y la solidaria a los ejes del cuadricóptero, las posiciones X e Y deseadas
serán dependientes del ángulo de Yaw (5.1) y (5.2), ángulo entre las dos re-
ferencias respecto del eje Z. Dicho ángulo variará su valor con escalones de
valor π
2
, (5.3). La posición en Z coincide en ambas referencias pero tomando
como cota cero el suelo solamente podrá tomar valores positivos y mayores
a la altura de los apoyos del cuadricóptero, aproximadamente 0.18 m. Los
ángulos Roll y Pitch los fijará el modelado en función de los movimientos.
x deseada = x actual + cos(yaw)longitud (5.1)
y deseada = y actual + sen(yaw)longitud (5.2)
yaw deseado = yaw actual + π/2 (5.3)
A continuación se explican las implementaciones llevadas a cabo para cada
alternativa y los resultados obtenidos.
5.2.1. Temas: /cmd vel y /command/twist
En un control llevado a cabo a través de cualquiera de los dos temas
disponibles, /cmd vel o /command/twist, la variable indicada con ellos será
la velocidad. La diferencia entre uno y otro radica en la complejidad de los
mensajes a publicar. En el primer caso los mensajes son simples, dos vectores
en los cuales se indica la velocidad angular y lineal relativa a los ejes soli-
darios al dron. Adicionalmente en el segundo caso sus mensajes poseen un
encabezamiento en el que contiene el momento de la publicación y la referen-
cia de coordenadas en la que se hace, pudiendo ser la absoluta o nuevamente
5.2. ANÁLISIS DE LOS MODOS DE CONTROL 31
la solidaria al cuadricóptero. En relación al modelado descrito inicialmente,
Fig. 5.1, solo estarán en uso los controladores velocity y attitude.
Con el fin de simplificar la implementación se usará el tema /cmd vel en
el cual se publicarán las velocidades oportunas en cada eje para cada movi-
miento. Dado que se indica la velocidad será sencillo cumplir las restricciones
temporales si se calcula la misma con los datos de tiempos y desplazamien-
tos. Nuevamente por simplicidad se indican valores constantes en todas ellas,
distintos de 0 cuando la posición u orientación deseada sea distinta de la real
con una cierta tolerancia.
En la Fig. 5.3 puede observarse la representación 3D de las coordenadas
del vuelo del cuadricóptero. La trayectoria real no coincide con la deseada.
Con la Fig. 5.4 es sencillo justificar el motivo, la altura real es ligeramente
mayor a la deseada como consecuencia de las tolerancias establecidas para
el posicionamiento en Z. En cuanto a las coordenadas XY la evolución del
posicionamiento real es correcto. La posición deseada se calcula en función
de la actual y la orientación del cuadricóptero. La existencia de un pequeño
error en ellas hace que la posición no se mantenga constante en 3 m cuando
debeŕıa ser aśı. La evolución de los ángulos durante el vuelo se refleja en la
Fig. 5.5. La variación en los ángulos de Roll y Pitch evidencian que el vuelo
no es totalmente horizontal, tal y como se describe en el modelo teórico del
caṕıtulo 3.
El código desarrollado en esta sección se encuentra en el anexo B.2.1. Es
posible visualizar la simulación llevada acabo en el canal de YouTube creado
para este proyecto [21].
32 CAPÍTULO 5. CONTROL DE VUELO
Figura 5.3: Representación en 3D de las coordenadas espaciales del cuadrado
dibujado mediante el tema cmd vel.
5.2. ANÁLISIS DE LOS MODOS DE CONTROL 33
(a) X.
(b) Y.
(c) Z.
Figura 5.4: Coordenadas de posición reales (real) y deseadas (goal). Cuadrado
dibujado con /cmd vel.
34 CAPÍTULO 5. CONTROL DE VUELO
(a) Roll.
(b) Pitch.
(c) Yaw.
Figura 5.5: Orientaciones reales (real) y deseadas (goal) o de reposo. Cua-
drado dibujado con /cmd vel.
5.2. ANÁLISIS DE LOS MODOS DE CONTROL 35
5.2.2. Acciones: Action pose
Dentro de los paquetes básicos de hector quadrotor hay implementadas
tres acciones: takeoff, landing y pose. Cada una da lugar a un nodo con su
nombre: takeoff action, landing action y pose action. El nodo pose action es
servidor de takeoff action y landing action y es a través de él como es posible
mover el cuadricóptero con este tipo de comunicación, en la Fig. 4.4 pueden
verse las comunicaciones entre ellos. En esta alternativa se hace uso de to-
dos los controladores que describen el modelo matemático de la Fig. 5.1, la
variable indicada externamente es la posición.
La acción pose publica en el topic /command/pose que constituye la en-
trada de position controller. El nodo a implementar será cliente del servidor
pose, en el anexo A.2.2 se explica como tiene lugar la comunicación. En el
se indica únicamente el objetivo al servidor pose, la posición y orientación
deseadas para poder dibujar el cuadrado calculadas como en el caso anterior
(5.1), (5.2) y (5.3). Las indicaciones se hacen respecto a la referencia absoluta
y sin partir de las condiciones iniciales del cuadricóptero, es posible modifi-
car estas premisas en el archivo spawn quadrotor.launchcomo se indica en
el capitulo 4 en la descripción del nodo pose estimation. En este caso no es
necesario conocer la posición deseada para llevar a cabo el control, position
controller la tiene en cuenta en sus cálculos relativos a la velocidad. Con esta
alternativa no es posible controlar el tiempo, y en definitiva la velocidad de
manera sencilla.
Los resultados se han extráıdo de una simulación cuya única indicación es
la posición y orientación deseadas, despreciando premisas temporales. En la
Fig. 5.6, representación 3D de las coordenadas espaciales reales y deseadas,
puede observarse como el cuadricóptero hace el dibujo de un cuadrado de
lados arqueados. Si además se observan las gráficas de la Fig. 5.7 pueden
ver sobrepasamientos de las posiciones deseadas. Esto lleva a la deducción
de que aun siendo bueno el posicionamiento final se realiza a una velocidad
muy elevada. Algo que se ve reafirmado en las variaciones de los ángulos Roll
y Pitch de la posición de reposo, Fig. 5.8.
El código desarrollado en esta sección se encuentra en el anexo B.2.2. Es
posible visualizar la simulación llevada acabo en de la misma manera que el
caso anterior [22].
36 CAPÍTULO 5. CONTROL DE VUELO
Figura 5.6: Representación en 3D de las coordenadas espaciales del cuadrado
dibujado mediante action pose.
5.2. ANÁLISIS DE LOS MODOS DE CONTROL 37
(a) X.
(b) Y.
(c) Z.
Figura 5.7: Coordenadas de posición reales (real) y deseadas (goal). Cuadrado
dibujado con action pose.
38 CAPÍTULO 5. CONTROL DE VUELO
(a) Roll.
(b) Pitch.
(c) Yaw.
Figura 5.8: Orientaciones reales (real) y deseadas (goal) o de reposo. Cua-
drado dibujado action pose.
5.2. ANÁLISIS DE LOS MODOS DE CONTROL 39
5.2.3. Conclusiones
El objetivo de este proyecto es el seguimiento de trayectorias continuas.
La propia estructura de comunicación de las acciones, las hace no aptas para
esta tarea. Cuando se indica una posición objetivo mediante estas no será
posible enviar uno nuevo mientras no se alcance y el servidor de la acción lo
notifique. Lo que da lugar continuos arranques y paradas del cuadricóptero.
Por otro lado, el posicionamiento está configurado para llevarse a cabo rápi-
damente por lo que cuanto más separado esté el cuadricóptero del objetivo
mayor será la velocidad para alcanzarlo. La comunicación con acciones ha si-
do creada para tareas que requieren un cierto tiempo. En este caso concreto,
las comunicaciones que se buscan son a frecuencias de intercambio de datos
altas. No es posible cumplir con la continuidad deseada.
El uso de cualquiera de los dos temas disponibles en el modelado, /cmd vel
o /command/twist, hace posible un control continuo y de manera más pre-
cisa. La mayor parte de robots simulados en Gazebo se controlan con el tema
/cmd vel, control sobre la velocidad. Haciéndolo con /command/twist en
la referencia del cuadricóptero daŕıa los mismos resultados pero dotaŕıa al
nodo de cierta versatilidad. Siendo posible el cambio de dicha referencia en
cualquier momento a la absoluta y teniendo información temporal de las
publicaciones, beneficioso en el caso de usar la herramienta /rqt plot para
dibujar gráficos durante la simulación, en la que solo es posible la visualiza-
ción de datos con sello temporal.
Respecto al desarrollo del código fuente de ambos nodos, cabe destacar que
la escritura para la comunicación mediante temas es más sencilla e intuitiva.
40 CAPÍTULO 5. CONTROL DE VUELO
41
Caṕıtulo 6
Seguimiento de una trayectoria
Todo el análisis, implementaciones y conclusiones hechas en caṕıtulos an-
teriores son la base de este caṕıtulo. Aqúı se describe e implementa el nodo
encargado de cumplir el objetivo de este proyecto, controlar el vuelo de un
cuadricóptero para que se desplace hasta un destino en un determinado tiem-
po. Ambos datos especificados de manera externa al módulo encargado de
llevar a cabo el control. Se empezará explicando de manera general cómo se
lleva a cabo el control. Después se procederá a explicar el ajuste y las limita-
ciones del algoritmo desarrollado. Por último, para justificar su utilidad, se
comparará con el control llevado a cabo en caṕıtulo 5.
6.1. Descripción del algoritmo de control
Se define como trayectoria continua aquella que es planificada a través de
las especificaciones de un usuario. En función de dicha panificación se gene-
ran los movimientos para llevarla a cabo. En este último punto se centrará
el algoritmo de control a implementar en esta sección, partiendo de una serie
de puntos que constituyen la planificación previa.
Tomando el modelado de cuadricóptero descrito en el caṕıtulo anterior e
incidiendo sobre él a través del tema /command/twist, se pretende controlar
la posición del mismo. La velocidad publicada en dicho tema será la tomada
por la aeronave en su vuelo. Dentro de velocity controller y attitude con-
troller se encuentra el control a más bajo nivel que calcula las fuerzas y
los momentos para hacer posible el movimiento, constituyen la salida de di-
cho modelado. El control de posición se realizará indicando las velocidades
previamente calculadas en función de los requisitos del posicionamiento. El
algoritmo a definir será el encargado de realizar dichos cálculos. Sus entradas
42 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
serán la posición deseada y real y el tiempo de desplazamiento entre ambas.
Este último dato junto con la posición deseada equivale a los datos proce-
dentes de la planificación de trayectorias. La posición real, como en otros
casos, puede ser obtenida a través del tema /ground truth to tf/pose. El
nodo relativo a su implementación se situará en el lugar que ocupa position
controller en el modelado expuesto en la Fig. 5.1, el resultado de este nuevo
esquema se encuentra en la Fig. 6.1. La entrada de la posición deseada no
se ha representado para que dicho esquema sea fiel a la implementación, los
puntos de la planificación se definirán internamente en el nodo.
Figura 6.1: Esquema de controladores para el modelado del vuelo modificado.
A pesar de que la planificación de la trayectoria no es un tema de estu-
dio en este trabajo es necesario definir cómo serán los puntos procedentes de
la misma. Se suponen puntos formados por las tres componentes del espacio
cartesiano relativos a la referencia absoluta y un tiempo, (x, y, z, t), cuyas
unidades son metros y segundos respectivamente. De proceder dichos puntos
del exterior ese tiempo seŕıa equivalente a la frecuencia de llegada entre los
mismos. De la misma manera que en el dibujo del cuadrado, se busca que
el cuadricóptero avance siempre en la dirección positiva de su eje X por lo
que nuevamente se estará trabajando entre dos referencias, la absoluta en la
indicación del posicionamiento y la del cuadricóptero para indicar las veloci-
dades. La orientación de la aeronave en la dirección del nuevo objetivo ha de
hacerse durante la marcha. En este caso la orientación deseada será igual al
ángulo que forma el vector definido por puntos (x,y) deseados cuando corta el
eje X positivo de la referencia absoluta, (6.1). Mientras que el cuadricóptero
avanza este ángulo va variando, a causa de x(t) e y(t). Lo que evidencia que
el control de orientación y avance no son independientes.
yawdeseado(t) = atan2(
ydeseada − y(t)
xdeseada − x(t)
) (6.1)
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 43
Definiendo vx, vy y vz como las velocidades lineales en los ejes X, Y y Z
solidarios al dron y w la velocidad angular en en el eje Z, vy será todo el
tiempo nula y será el valor del resto lo que deba fijar el algoritmo a desarro-
llar. La corrección en la orientación ha de ser lo más rápida posible evitando
el avance hacia una dirección equivocada. Las velocidades lineales, vx y vz,
deben hacer posible que el dron se desplace hasta la posición en el plano XY
y la altura deseadas en el tiempo dado. Conforme vaya pasando el tiempo el
error irá tendiendo a unvalor nulo por lo que las velocidades deben ser recal-
culadas constantemente para tener en cuenta las variaciones en la posición y
la orientación. El error de posicionamiento nunca llegará a ser exactamente
nulo y por lo tanto tampoco lo serán las velocidades, se definirá un cierto
error admisible entre los valores deseados y reales.
Al nodo donde se encuentra implementado el algoritmo se le ha nombra-
do como trajectoryControl.cpp. Su código fuente se encuentra en el anexo
B.3. Dicho nodo calculará y publicará las velocidades cada un cierto tiempo,
periodo de muestreo. Para llevar a cabo el control se han definido en él tres
controladores PID (6.2) y (6.3). Se corresponden con el control de movimien-
to del dron en cada uno de sus ejes, desplazamiento lineal en X y Z y giro en
Z. En la siguiente sección se valorará la necesidad de las diferentes acciones
y se definirán el control de manera más precisa.
u(t) = Kpe(t) +Ki
∫ t
0
e(t)dt+Kd
de(t)
dt
(6.2)
Ki =
Kp
τi
Kd = Kpτd (6.3)
6.2. Ĺımites de operación y ajuste del control
El mundo donde se lleva a cabo la simulación y el ajuste de los controla-
dores es un entorno vaćıo como el mostrado en la Fig. 6.2. En esta además es
visible el eje de coordenadas solidario al cuadricóptero, se encuentra girado
90o en Z respecto del eje de coordenadas absoluto.
Las acciones de un controlador PID son función del error de la variable sobre
la que se está efectuando el control. En este caso concreto la acción total del
control equivale a las velocidades vz, vx y w. La velocidad lineal en Z toma
valores de ambos signos para variar la altura de la aeronave. Las posiciones
deseadas y reales en este eje siempre serán positivas. El choque de su chasis
con el suelo, la cota 0, da lugar a la mı́nima, aproximadamente 0,18 m. La
44 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
Figura 6.2: Interfaz gráfica de Gazebo. Hector posicionado en un mundo
vaćıo.
velocidad lineal en X debe tomar valores siempre positivos según se ha des-
crito el control. Los puntos (x,y) deseados y reales pertenecen a cualquiera
de los cuatro cuadrantes del plano XY de vuelo. El error de los controladores
de estas dos velocidades se calculan según (6.4) y (6.5), siendo en ambas ttotal
el tiempo dado. El error de avance en el plano XY se calcula a partir de la
distancia eucĺıdea, de esta manera se consigue una velocidad siempre positi-
va independientemente del signo de las componentes (x,y) de los puntos. La
velocidad angular en Z tomará valores positivos cuando el giro se produzca
hacia la derecha y negativos en el caso de hacerlo a la izquierda. Una vez
más el error depende de la evolución temporal pero, a diferencia de los casos
anteriores, el error no tiene unidades de velocidad, m/s o rad/s en este caso,
si no rad (6.6). La velocidad de giro no se fija con el tiempo dado si no que
debe hacerse lo más rápido posible. El valor de este error no debe superar
en valor absoluto a π, en consecuencia a como se define la orientación en
Gazebo, por eso es necesario realizar una compensación si se da el caso.
ez(t) =
zdeseada − z(t)
ttotal − t
(6.4)
ex(t) =
√
(xdeseada − x(t))2 + (ydeseada − y(t))2
ttotal − t
(6.5)
eyaw(t) = yawdeseado(t)− yaw(t) (6.6)
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 45
Según las definiciones de los errores la respuesta del controlador de vz es
independiente del resto. Sin embargo las respuestas de los otros dos controles
son dependientes entre śı. Una correcta orientación llevará a un correcto
avance en el plano XY. Cada una de las acciones de un controlador PID trata
de mejorar la respuesta de una manera. Para un ajuste preciso es necesario
conocer la función de transferencia del sistema y sobre ella hacer un estudio
frecuencial que mejore su respuesta. Como no es posible conocer dicha función
de manera exacta se ha optado por realizar un ajuste emṕırico basado en las
ideas básicas de cada acción [19]:
1. Acción proporcional: es igual al error multiplicado por una constante
Kp. Provoca un aumento en la velocidad de la respuesta pero valores
muy elevados en su constante pueden llevar el sistema a la inestabilidad.
En su ajuste el resto de las acciones se hacen nulas y el valor de Kp se
va aumentando hasta conseguir la velocidad deseada en la respuesta.
2. Acción derivativa: es igual a la derivada del error multiplicada por
una constante Kd (6.3). Trata de anticiparse al error que pueda darse
en el sistema. Evita los sobrepasamientos originados por la inercia del
sistema ante una acción proporcional pura por lo que será necesaria
si se observan oscilaciones entorno al valor deseado tras una acción
proporcional. Para su ajuste se aumenta el valor de τd, a un tiempo
poco superior al periodo de muestreo, de manera que se consiga una
respuesta más estable.
3. Acción integral: es igual a la integral del error multiplicada por una
constante Ki (6.3). Trata de reducir el error en régimen permanente
pero valores muy elevados en su constante pueden llevar nuevamente el
sistema a la inestabilidad. Se usará esta acción de darse un error en la
respuesta estacionaria.
Previo al ajuste es necesario establecer el periodo de muestreo, T , que estará
limitado por el escalón temporal mı́nimo de Gazebo. Dicho valor es time step
publicado en el tema /gazebo/parameter descriptions por Gazebo. Puede ser
configurado entre 0 s y 10 s siendo 0,001 s su valor por defecto y el usado en
las simulaciones de este trabajo. Periodos muy próximos a dicho valor pueden
provocar errores como consecuencia de trabajar sobre un sistema en tiempo
real digital. Además T debe ser menor que la separación mı́nima entre puntos
planificados, los controladores tienen que tener tiempo suficiente para ofrecer
una buena respuesta. Por todo ello se fija un T 10 veces mayor al escalón del
reloj, 0,01 s. A continuación se procede al ajuste de los controladores par-
tiendo en todos los casos de una acción proporcional únicamente con Kp = 1.
46 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
Ajuste PID para el control de la altura
Para obtener la respuesta de este controlador se ha hecho nula la acción pro-
vocada por el resto. La trayectoria planificada está compuesta por un único
punto (0 m, 0 m, 1 m, 10 s), por lo que se espera una acción del controlador
entorno a 0,1 m/s, vz. Los resultados de la simulación llevada a cabo se pue-
den observar en la Fig. 6.3. La respuesta se ajusta con la deseada, el dron
alcanza una altura de 1 m en 10 s y se mantiene en un valor prácticamente
igual a ella. No será necesario modificar la constante Kp ni añadir una acción
integral. Puede observarse un pequeño sobrepasamiento del todo desprecia-
ble, tan solo un 1 % por encima del valor en régimen permanente, por lo que
tampoco será necesaria una acción derivativa en este caso.
Figura 6.3: Respuesta del controlador PID vz con Kp = 1.
Ajuste PIDs para el avance en el plano XY
Llevando el cuadricóptero a una cierta altura, posible gracias al ajuste an-
terior, se procede al ajuste del resto de controladores de manera que el roce
con el suelo no influya en el movimiento. La trayectoria planificada estará
compuesta por el punto (1 m, 1 m, 1 m, 10 s) y partirá de la posición (0,0)
del plano XY con una orientación de 0 rad en Z. La respuesta esperada es
una rápida orientación a π
4
rad de manera que el avance se produzca cuanto
antes en la dirección correcta. Los resultados de la simulación se recogen en
la Fig. 6.4 y la Fig. 6.5. El dron se sitúa en la posición deseada en el tiempo
deseado, el erro en régimen permanente se debe a las tolerancia fijada para
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 47
este desplazamiento. La posición exacta en X e Y no se alcanza pero si un
valor muy próximo. Las tolerancias evitan que el dron continúe moviéndose
cuando se encuentra en esta situación. Diferencias pequeñas en el posicio-
namiento pueden dar lugar a ángulos significativos por lo que en este caso
también seránecesario fijar una tolerancia. La corrección de la orientación
es lenta, lo que provoca un desplazamiento curvo entre las posición inicial y
deseada, Fig. 6.5a.
Para aumentar la velocidad de la respuesta del controlador de orientación
se aumenta su constante proporcional de manera gradual. Para un valor de
Kp = 15 se da la velocidad máxima de dicha respuesta. Las Fig. 6.6 y 6.7
recogen los resultados de una simulación para la misma trayectoria. La res-
puesta ahora satisface los requerimientos. Nuevamente, el dron alcanza la
posición (1 m,1 m) en 10 s ,despreciando el error ocasionado por las tole-
rancias. Es por eso que el controlador encargado de este desplazamiento se
mantendrá como un proporcional con Kp = 1. De la misma manera para el de
orientación, pero con Kp = 15. La respuesta es rápida, estable y sin errores
en el permanente, Fig. 6.6.
Figura 6.4: Respuesta del sistema con PID w con Kp = 1.
48 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
(a) Respuesta XY.
(b) Respuesta X.
(c) Respuesta Y.
Figura 6.5: Respuesta del sistema con PID vx con Kp = 1, siendo Kp = 1 en
el controlador de la orientación.
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 49
Figura 6.6: Respuesta del sistema con PID w con Kp = 15.
50 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
(a) Respuesta XY.
(b) Respuesta X.
(c) Respuesta Y.
Figura 6.7: Respuesta del sistema con PID vx con Kp = 1, siendo Kp = 15
en el controlador de la orientación.
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 51
Con el objetivo de conocer el tiempo que cuesta corregir el error máximo,
π rad, se lleva a cabo una simulación con un punto distinto, (-1 m, 0 m, 1 m,
10 s) y las mismas condiciones iniciales. Este tiempo depende del controlador
de orientación y de la velocidad del avance en el plano XY. El controlador
tarda aproximadamente 3 s en corregir dicha orientación en estas condiciones
de simulación, Fig. 6.8.
Figura 6.8: Respuesta del sistema con PID w con Kp = 15 y una corrección
de giro de π rad.
El valor de las velocidades reales tomadas por el dron durante su vuelo está
limitado por su modelado. Existe un valor máximo al que saturan las mis-
mas a pesar de la que se indique externamente, en este caso por el algoritmo
implementado. En la definición de los controladores para el modelado del
comportamiento se indica que la velocidad máxima en z es de 5 m/s y 10
m/s en xy. Se han comprobado dicho valores usando el control desarrollado.
Para lo cual se ha llevado al dron a alcanzar velocidades superiores a las
mismas.
Para la velocidad máxima en Z la trayectoria planificada será un único punto,
(0 m ,0 m, 60 m, 10 s). La velocidad esperada será aproximadamente 6 m/s
y sin embargo, como cabe esperar, esta toma un valor de aproximadamente
5 m/s, Fig. 6.9. En cambio, la velocidad en X no satura al valor esperado.
En este caso la simulación se realiza con el punto (150 m, 0 m, 2.0 m, 10 s),
partiendo de la posición (0,0) y una orientación nula en el eje Z. La velocidad
que se espera que tome el dron es igual a 15 m/s pero sin embargo toma un
52 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
valor de aproximadamente 8 m/s, Fig. 6.10, inferior al valor de saturación
esperado.
Figura 6.9: Respuesta del sistema ante vz superior a su valor máximo.
Figura 6.10: Respuesta del sistema ante vx superior a su valor máximo.
Las limitaciones de velocidad máxima lineal en vx y vz, el tiempo de res-
puesta del controlador de orientación ante un giro máximo y el periodo de
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 53
muestreo T condicionan los puntos provenientes de la planificación de tra-
yectorias. Para un correcto funcionamiento del algoritmo se deben tener en
cuenta la siguientes aspectos en la planificación de la trayectoria entrante.
1. El tiempo entre puntos debe ser superior a T al menos 10 veces. De no
ser aśı llegará un nuevo punto antes que las acciones hagan que el dron
haya alcanzado el objetivo anterior.
2. La velocidad máxima entre los puntos no debe superar la ĺımite.
3. La diferencia de orientación entre puntos depende de su separación en
X e Y. Conforme avanza el dron en el plano XY la orientación deseada
cambia y a su vez la actual por la acción del control de esta variable.
Velocidades altas de avance provocan malas respuestas de orientación.
Con el objetivo de comparar los controles básicos de hector quadrotor con
el desarrollado en este proyecto se ha llevado a cabo la misma tarea que
en el caṕıtulo 5: el dibujo de un cuadrado de 3 m de lado volando a una
altura de 2 m. A diferencia del primer caso, el cuadricóptero no detiene
su avance para efectuar el giro. Es por eso que la representación 3D del
dibujo del cuadrado con el nuevo control, Fig. 6.11, no es un poĺıgono tan
regular, Fig. 5.3. Dado que el ángulo a corregir es elevado, π
4
, las respuestas de
los controladores de avance y orientación no consiguen seguir la trayectoria
deseada mientras este no es corregido. Se debe tener en cuenta que esta
trayectoria se ha definido por 6 puntos separados 10 s que se corresponden
con el despegue, las esquinas del cuadrado y el punto de aterrizaje. Una
trayectoria definida por más puntos tendŕıa mejores resultados. Las Fig. 6.12
y Fig. 6.13 recogen los resultados espećıficos de cada una de las coordenadas
y orientaciones. Comparándolos con los obtenidos en el caṕıtulo 5, Fig. 5.4 y
5.5, puede observarse la mejora en el control del movimiento. En la primera
simulación la velocidad del cuadricóptero conmutaba entre 0 y 1 en función
de si se estaba o no en el destino, un simple control ON-OFF. Dicho control
estaba dotado de histéresis, la tolerancia. Aunque era posible cumplir con los
requisitos temporales los movimientos de la aeronave eran más bruscos y con
paradas y arranques en los cambios de orientación. En el nuevo control hace
posible el giro sin necesidad de detener la marcha suavizando aśı el vuelo. El
valor de la velocidad es continuamente calculado por el control y no un valor
constante. Dotando al cuadricóptero de cierta autonomı́a y adaptabilidad
a las condiciones del vuelo frente al caso anterior. Es posible visualizar la
simulación llevada a cabo en el canal de YouTube de este proyecto [23].
54 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
Figura 6.11: Representación en 3D de las coordenadas espaciales. Cuadrado
dibujado con el control desarrollado.
6.2. LÍMITES DE OPERACIÓN Y AJUSTE DEL CONTROL 55
(a) X.
(b) Y.
(c) Z.
Figura 6.12: Coordenadas de posición reales (real) y deseadas (goal). Cua-
drado dibujado con el control desarrollado.
56 CAPÍTULO 6. SEGUIMIENTO DE UNA TRAYECTORIA
(a) Roll.
(b) Pitch.
(c) Yaw.
Figura 6.13: Orientaciones reales (real) y deseadas (goal). Cuadrado dibujado
con el control desarrollado
57
Caṕıtulo 7
Conclusiones y trabajo futuro
7.1. Conclusión
El objetivo de este trabajo es la simulación de un cuadricóptero y el segui-
miento de su trayectoria de manera continua. Previamente, ha sido necesario
un estudio en profundidad del entorno de simulación ROS/Gazebo usado. La
documentación desarrollada en esta parte puede servir como punto de parti-
da para trabajos con cuadricópteros en el mismo entorno. Se ha comprobado
la utilidad de este o cualquier otro simulador cuando se trata de estudiar
el comportamiento de un robot, pudiendo llevar a cabo experimentos más
variados, con menor coste temporal y económico y de manera segura. Gazebo
ofrece múltiples posibilidades en la configuración de las variables relevantes
de un experimento y muchos robots tienen su modelo disponible para usar
en este entorno. El uso tan extendido de Gazebo y ROS hace fácil la resolu-
ción de problemas o dudas que puedan surgir. Está disponible un amplio y
estructurado conjunto de tutoriales y documentación.
Los resultados obtenidos en el control de la trayectoria han resultado sa-
tisfactorios. El cuadricóptero llega a los objetivos fijados en los tiempos es-
perados con movimiento