Equation Chapter 1 Section 1

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías

Industriales

Diseño de interfaces gráficas y de algoritmos de

localización de un quadrotor

Autor: Pablo Lara Peinado

Tutor: Carlos Bordons Alba / Alicia Arce Rubio

Dep. de Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, septiembre de 2015

iii

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías Industriales

Diseño de interfaces gráficas y de algoritmos de

localización de un quadrotor

Autor:

Pablo Lara Peinado

Tutor:

Carlos Bordons Alba

Catedrático

Dep. de Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, septiembre de 2015

v

Proyecto Fin de Carrera: Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Autor: Pablo Lara Peinado

Tutor: Carlos Bordons Alba / Alicia Arce Rubio

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, septiembre de 2015

El Secretario del Tribunal

vii

A mi familia

A mis maestros

ix

Agradecimientos

En primer lugar, quisiera agradecer a mis padres Antonio y Antonia, por haberme dado siempre la mejor

educación posible y haberme obligado a continuar a pesar de las dificultades, y a mi hermano Javier, quien ha

sido siempre un modelo a seguir como estudiante y como persona.

Quisiera mostrar mi gratitud a D. Carlos Bordons Alba, por haber accedido a ser mi tutor del proyecto, cuyos

consejos y directrices han sido claves para la realización del mismo y, sobre todo, por su infinita paciencia y

amabilidad.

Me gustaría mencionar también la ayuda de Alicia Arce y Ricardo Galán, sin cuya ayuda no hubiese sido

posible realizar este proyecto.

Por último, destacar la paciencia y el apoyo de Amparo durante toda la carrera.

Pablo Lara Peinado

Sevilla, septiembre de 2015

xi

Resumen

En este Trabajo Fin de Grado se describe el diseño e implementación de una interfaz gráfica, programada

mediante GUI de Matlab, para controlar y monitorizar el cuadricóptero AR.Drone 2.0.

A su vez, se proponen tres métodos para estimar la posición de dicho quadrotor. El primer método se basa en

la localización mediante visión monocular; el segundo en la integración de la velocidad del dron y el tercero en

un modelo de espacio de estados que relaciona los ángulos medidos por el giróscopo del AR.Drone con la

posición estimada.

Por último, se desarrolla otra interfaz para el seguimiento de trayectorias y se propone un controlador PID

para llevarlo a cabo.

xiii

Índice

Agradecimientos ix

Resumen xi

Índice xiii

Índice de Ilustraciones xv

1 Introducción 1 1.1 Objetivos 1 1.2 Justificación 2

2 Estado del Arte 3 2.1 Interfaces gráficas 4 2.2 Estimación de posición 4 2.3 Seguimiento de trayectorias 4 2.4 Legislación 5

3 Descripción del Equipo 9 3.1 Hardware: AR.Drone 2.0 9

Estructura 9 3.1.1 CPU y comunicación 10 3.1.2 Sensores 10 3.1.3 Motores y alimentación 11 3.1.4 Nociones básicas del AR.Drone 11 3.1.5 Arquitectura de control 12

3.2 Software 13

4 Interfaz Gráfica para el Control y Monitorización 17 4.1 Comunicación con el AR Drone 18 4.2 Problema con el paralelismo 19 4.3 Panel de conexión 20 4.4 Control manual 22 4.5 Panel de misiones 23 4.6 Gráficas y toma de datos 24 4.7 Imágenes y vídeo 25

5 Estimación de la Posición 29 5.1 Estimación por visión monocular 29

5.1.1 Calibración de la cámara 29

5.1.2 Algoritmo 30 5.1.3 Parametrización mediante profundidad inversa 33 5.1.4 Pruebas y resultados 36 5.1.5 Conclusiones 38

5.2 Estimación por integración de la velocidad 39 5.2.1 Pruebas y resultados 39

5.3 Estimación por modelo de espacio de estados 40 5.3.1 Pruebas y resultados 42

6 Seguimiento de Trayectorias 45 6.1 Sistema de control 45 6.2 Identificación del sistema 46 6.3 Interfaz gráfica 47 6.4 Comentarios 49

7 Conclusiones 51 7.1 Conclusiones 51 7.2 Futuras investigaciones 52

Índice de Ecuaciones 53

Bibliografía 55

Lista de Abreviaturas y Acrónimos 59

xv

Índice de Ilustraciones

Figura 1. Ejemplos de UAV de uso recreativo 3

Figura 2. Normativa para el uso recreativo de los UAV [26] 6

Figura 3. AR.Drone 2.0. [28] 9

Figura 4. AR.Drone con los dos tipos de carcasas [29] 10

Figura 5. GPS y grabador de vídeo del AR.Drone 2.0 11

Figura 6. Componentes del AR.Drone 2.0 11

Figura 7. Sistema de coordenadas del AR.Drone 2.0 [32] 12

Figura 8. Captura de la aplicación oficial, AR.FreeFlight 13

Figura 9. Interfaz gráfica de control y monitorización 17

Figura 10. Esquema de los procesos en la interfaz 20

Figura 11. Panel de conexión 21

Figura 12. Guardar o no el último log. 21

Figura 13. Panel de control manual 22

Figura 14. Panel de misiones 24

Figura 15. Panel de gráficas 25

Figura 16. Panel del vídeo 26

Figura 17. Tablero para la calibración de la cámara 29

Figura 18. Detección de puntos 31

Figura 19. Parametrización por profundidad inversa [39] 35

Figura 20. Estimación de posición por visión 36

Figura 21. Estimación de posición por integracióbn de la velocidad 40

Figura 22. Espacio de estados 40

Figura 23. Estimación de posición por espacio de estados 43

Figura 24. Esquema del sistema de control 46

Figura 25. Respuesta del sistema ante referencia, en el eje X 47

Figura 26. Respuesta del sistema ante referencia, en el eje Y 47

Figura 27. Interfaz gráfica para la creación y seguimiento de trayectorias 48

Tabla 1. Errores cometidos por los métodos de estimación de la posición 43

Tabla 2. Sintonización del PID por el método de Ziegler-Nichols 47

1 INTRODUCCIÓN

Este Trabajo Fin de Grado surgió del proyecto realizado en el marco de la estancia en una empresa, Ayesa. En

dicha empresa se decidió llevar a cabo, como proyecto de I+D, el estudio y desarrollo de sistemas de control,

estimadores de posición, seguimiento de trayectorias y sistemas de navegación para UAVs (Unmaned Aerial

Vehicle), con el objetivo de desarrollar vuelos autónomos en interiores.

Por tanto, este trabajo recoge mi contribución al proyecto que está siendo desarrollado en Ayesa.

1.1 Objetivos

La planificación inicial del proyecto fue la siguiente:

Estudiar las ordenes de teleoperación del dron desde una plataforma PC:

Órdenes básicas

Toma de datos desde los sensores

Toma de imágenes y video

Implementar estrategias de control de emergencia

Realización de misiones prueba

Implantar una estrategia de control que sustituya la teleoperación manual desde el PC:

Estimación de la posición mediante integración de velocidad y aceleración

Desarrollo de un modelo de comportamiento del dron

Aplicar estrategias básicas y comparar con otros controladores publicados en la literatura

Realización de misiones de testeo de los controladores

Estudiar incorporación de video para estimar posición e incluir las estrategias de control en el micro

del dron:

Estudiar e implementar estrategias de estimación de la posición mediante video

Implementar las estrategias de control básicas

Implementar la estimación de posición mediante video

Introducción 2

Dichos objetivos son los que se han cumplido y se han documentado en este Trabajo Fin de Grado,

ampliándose hasta la siguiente fase del proyecto, que consiste en diseñar e implementar un sistema de

generación y seguimiento de trayectorias, aunque dicho punto se encuentra todavía en desarrollo.

1.2 Justificación

Actualmente hay un gran avance en las nuevas tecnologías y, más concretamente, en los UAV. En los últimos

tiempos ha habido un auténtico desarrollo en este ámbito, ya que se ha pasado de ser una tecnología empleada

principalmente en el mundo militar o en el de la investigación, a estar al alcance de cualquier persona,

pudiéndose comprar en cualquier tienda de tecnología e, incluso, a ser considerado un juguete. Muchas

empresas se han interesado los drones, por la amplia gama de características que pueden ofrecer, y a bajo

coste. Destacan sus usos en fotografía y grabación de eventos, aplicaciones topográficas, lucha contra

incendios, seguimiento de obras, vigilancia…

Una empresa como Ayesa, cuyo ámbito de trabajo es el sector tecnológico y de la ingeniería, y que dispone de

filiales en diversos lugares del mundo y que cuenta con un gran número de obras y de proyectos, requiere de

los más novedosos avances para ser competitiva. El uso de UAV facilitaría procesos como el seguimiento de

obras y terrenos o aplicaciones topográficas. En relación a este Trabajo Fin de Grado, el uso de drones podría

ser de gran utilidad en inspecciones de obras o conductos de difícil acceso o con condiciones peligrosas (como

un escape de gas), en lugares donde no se pueda usar el GPS (Global Positioning System) por ser interiores.

2 ESTADO DEL ARTE

os UAV han tenido un desarrollo exponencial en los últimos tiempos, habiéndose incrementado hasta en

10 veces su venta a nivel mundial [1] y moviendo millones de dólares en inversiones, tal y como se indica en

[2]. Actualmente tienen una gran variedad de aplicaciones en diversos ámbitos, como por ejemplo en obras e

ingeniería civil [3], agricultura [4], sector audiovisual [5] o seguridad [6]. El sector de los UAV ha crecido

tanto, sobre todo, debido al lanzamiento de numerosos dron de uso recreativo de fácil acceso al público.

Plataformas como SYMA X5C-1, AR.Drone 2, DJI Phantom 2 o Hubsan X4 son muy populares gracias a su

asequible precio y múltiples características, véase [7].

A B

C D

Figura 1. Ejemplos de UAV de uso recreativo: SYMA X5C-1 (A); DJI Phantom 2 (B); Hubsan X4 (C) y

AR.Drone 2.0 (D)

L

Estado del Arte 4

2.1 Interfaces gráficas

Existen numerosas herramientas gráficas y lenguajes de programación que permiten crear interfaces para

controlar un UAV. En [8], Zul Azfar y Hazry describen el proceso para diseñar una GUI (Graphical User

Interface) para controlar de manera remota un UAV, usando SolidWork.

Hanafi et al. [9] desarrollan una interfaz gráfica para controlar un quadrotor FY90 en Visual Basic 2008

Express. El control se realiza mediante un PID y se usa un Arduino Uno para procesar las señales y controlar

los motores del dron.

En el artículo realizado por Berra y Cuautle [10] se presenta el diseño e implementación de un sistema de

control de radio frecuencia para un drone, por medio de una interfaz natural que comprende gestos corporales

detectados con Kinect.

Govindarajan et al. [11] presentan una interfaz, realizada en Labview, para controlar un quadrotor y enviar y

recibir los datos de éste.

En el artículo escrito por Panicker et al. [12], se programa una GUI en Matlab que permita el control remoto y

la realización de tácticas de vuelo avanzadas, que se implementarán en un dron mediante Arduino.

2.2 Estimación de posición

Respecto a la estimación de posición de un UAV, es un tema ampliamente desarrollado e investigado. En el

trabajo presentado por Sturm et al. [13], se plantea una técnica de localización y mapeado simultáneo, o

SLAM (Simultaneous Localization and Mapping), basada en PTAM (Parallel Tracking and Mapping), junto

con un filtro de Kalman extendido.

En la tesis de Engel [14] , se implementa en el AR.Drone un controlador PID para la orientación y posición del

dron y un algoritmo de SLAM monocular para estimar la posición.

En el proyecto de Máster de Strubel [15], se implementa un método de localización basado en cámaras. Para

ello, se marca el UAV con cuatro LED de pulsos distintos y se desarrolla un algoritmo de seguimiento para

estimar la posición, obteniéndose un seguimiento mucho más rápido que usando PTAM en una cámara CMOS

(Complementary metal-oxide-semiconductor) estándar.

Mondragón et al. [16] propusieron una estimación de la posición 3D de un UAV mediante el seguimiento de

un objeto plano. El algoritmo obtiene las componentes métricas y proyectivas de un objeto de referencia

respecto al sistema de coordenadas de la cámara del dron, usando un seguimiento robusto en tiempo real

basado en homografías.

En [17], Grelsson desarrolla tres métodos para el posicionamiento y la estimación de la altitud a partir

imágenes aéreas. El primer método consiste en usar un modelo 3D georreferenciado para estimar los seis

grados de libertad, DoF, del UAV, obteniéndose un mapa de densidad local de alturas usando visión estéreo.

En el segundo se realiza una estimación de los ángulos pitch y roll mediante la detección del horizonte. El

último método es un desarrollo ampliado del segundo.

En la tesis fin de Máster de Dijkshoorn [18], se aplica el SLAM en tiempo real al AR.Drone, a partir de las

imágenes obtenidas por su cámara vertical.

2.3 Seguimiento de trayectorias

Para que el quadrotor desempeñe correctamente cualquier aplicación, es necesario asegurar un

comportamiento estable que permita seguir con precisión las trayectorias indicadas. Se han abordado

numerosas estrategias para el control de UAV en los últimos tiempos.

En [19], Dexin Xu desarrolla un sistema de control de trayectorias para un quadrotor, estableciendo un modelo

del sistema mediante el método de Eyla-Lagrange y, posteriormente, descomponiéndolo en dos subsistemas, el

de posición y el de altitud.

Estellés Martínez y Tomás Rodríguez proponen, en un artículo [20], un algoritmo de control basado en la

metodología PVA (posición-velocidad-aceleración) con la finalidad de obtener un seguimiento de trayectoria

mediante acciones de control suaves.

En un artículo realizado por Vago Santana [21] se implementa un control del AR.Drone basado en dos

estructuras principales, un filtro de Kalman para seguir la posición 3D del vehículo y un controlador no linear

para guiar al dron en las misiones aéreas.

Pomares et al. [22], describe un sistema de control visual diseñado para el seguimiento de trayectorias 3D

realizadas por un objeto en movimiento, utilizando una cámara en el extremo del robot.

En el Proyecto Fin de Carrera de Martínez Criado [23], se estudia el uso de controladores PID y GPC

(Generalized Predictive Control) en cascada para conseguir el seguimiento autónomo del AR.Drone de

trayectorias en el plano horizontal XY.

Casanova de los Santos propone en [24] el desarrollo de un controlador difuso para estabilizar el

funcionamiento de un quadrotor en el seguimiento de trayectorias, tanto en simulación como en la plataforma

real.

2.4 Legislación

Debido al auge y proliferación del uso de RPA (Remotely Piloted Aircrafts), se ha hecho indispensable la

existencia de un régimen jurídico específico en el que se enmarquen estas aeronaves y las actividades aéreas

relacionadas con ellas. Por este motivo, el Consejo de Ministros aprobó el Real Decreto-ley 8/2014 en cuya

sección 6ª se recoge el régimen temporal para las operaciones con aeronaves pilotadas por control remoto,

drones, de peso inferior a los 150 kg al despegue, y se establecen las condiciones de explotación de estas

aeronaves para la realización de trabajos técnicos y científicos.

Posteriormente, dicha normativa ha sido tramitada como ley, proceso que ha culminado con la publicación en

el BOE de la Ley 18/2014, de 15 de octubre [25]. Este reglamento temporal contempla los distintos escenarios

en los que se podrán realizar los distintos trabajos aéreos y en función del peso de la aeronave. Además, las

condiciones ahora aprobadas se completan con el régimen general de la Ley 48/1960, de 21 de julio, sobre

Navegación Aérea, y establecen las condiciones de operación con este tipo de aeronaves, además de otras

obligaciones.

Según la actual regulación, se pueden utilizar UAV para los siguientes fines:

Actividades de investigación y desarrollo;

Tratamientos aéreos, fitosanitarios y otros que supongan esparcir sustancias en el suelo o la atmósfera,

incluyendo actividades de lanzamiento de productos para extinción de incendios;

Levantamientos aéreos;

Observación y vigilancia aérea incluyendo filmación y actividades de vigilancia de incendios

forestales; publicidad aérea, emisiones de radio y TV,

Operaciones de emergencia, búsqueda y salvamento;

Otro tipo de trabajos especiales no incluidos en la lista anterior.

Estado del Arte 6

Siempre teniendo en cuenta que estas operaciones se limitan a zonas no pobladas y al espacio aéreo no

controlado.

Además, hay que tener en cuenta que, para el ejercicio de estas actividades realizadas con UAV de hasta 25

Kg de masa máxima al despegue (MTOM), se deberá presentar ante la Agencia Estatal de Seguridad Aérea

(AESA) una comunicación previa y declaración responsable con una antelación mínima de cinco días al día

del inicio de la operación.

Para conseguir la habilitación como operador de drones para realizar este tipo de trabajos el régimen

establecido es de comunicación previa y declaración responsable, por lo que no es necesario un permiso o

autorización, tan solo un acuse de recibo una vez que presente en el Registro de AESA la declaración

responsable junto con la documentación exigida, cuyo acuse de recibo le habilitará como operador de drones.

Si el uso del dron está encaminado a un hobby o uso recreativo, no se necesita habilitación de AESA, pero hay

que cumplir unas normas de seguridad, que se muestran en la figura 2.

Figura 2. Normativa para el uso recreativo de los UAV [26]

Lo comentado anteriormente corresponde a la regulación temporal vigente en España. En el ámbito de la

Unión Europea, no existe actualmente un marco jurídico, aunque se está trabajando en ello. Hasta el momento,

como se indica en [27], las Autoridades europeas de protección de datos (Grupo de Trabajo del Artículo 29,

del que forma parte la Agencia Española de Protección de Datos) han aprobado el primer Dictamen conjunto

sobre drones, que analiza la incidencia y los riesgos que la utilización de estos vehículos no tripulados plantean

para la privacidad y la protección de datos.

Estado del Arte 8

3 DESCRIPCIÓN DEL EQUIPO

Este capítulo está dedicado a la descripción del equipo, tanto hardware como software, del que se parte para la

realización del proyecto.

3.1 Hardware: AR.Drone 2.0

La plataforma que se utiliza en el proyecto es el UAV AR.Drone 2.0. Este vehículo aéreo no tripulado es un

cuadricóptero comercial, de bajo coste, desarrollado por la empresa Parrot.

Figura 3. AR.Drone 2.0. [28]

Estructura

La estructura del AR.Drone es bastante simple. Una de sus principales ventajas es que es totalmente modular,

permitiendo un fácil recambio de todas sus piezas. Cuenta con un esqueleto de soporte en forma de cruz de

tubos de fibra de carbono sobre la que se montan tanto los motores como la placa madre y la placa de

navegación. El cuerpo del UAV es de espuma de polipropileno, que protege a los componentes electrónicos

frente a los golpes. Además, la espuma de polipropileno es proporciona flotabilidad al equipo, favoreciendo su

recuperación en caso de caída en el agua (aunque la electrónica podría sufrir daños, ya que no está

Descripción del Equipo 10

impermeabilizada).

Finalmente, cuenta con una carcasa o casco de funcionalidad protectora y estética hecha de plástico PA66 de

alta resistencia. Esta carcasa puede ser de dos tipos: para interior o para exterior. Cada una está diseñada para

tener las mejores condiciones aerodinámicas según donde tenga lugar el vuelo.

Figura 4. AR.Drone con los dos tipos de carcasas [29]

3.1.1 CPU y comunicación

El AR.Drone 2.0 posee un sistema empotrado que consiste en una placa base que integra un microcontrolador

AVR de 8 MIPS y un microprocesador ARM Cortex A8 de 32 bits a 1GHz con DSP de video

TMS320DMC64x a 800MHz. El sistema operativo es Linux 2.6.32 con 1Gbit DDR2 de RAM a 200MHz

[30].

La comunicación con el dispositivo de control se realiza por Wi-Fi. Además, posee USB 2.0 para poder

conectar dispositivos externos, como un equipo con GPS y almacenamiento de vídeos.

3.1.2 Sensores

Los sensores de los que dispone el UAV son los siguientes [31]:

Giróscopo de 3 ejes con precisión de 2000°/segundo

Acelerómetro de 3 ejes

Magnetómetro de 3 ejes con precisión de 6°

Sensor de presión con ±10 Pa de precisión

Sensor de ultrasonidos para medir la altitud

Cámara vertical QVGA (320x240 píxeles de resolución), de 60 fps. Con esta cámara, el AR.Drone

2.0 estima la velocidad

Cámara HD frontal, con 720p y a 30fps

El dron no dispone de GPS a bordo. Sin embargo, existe la posibilidad de conectar, mediante USB, un

dispositivo externo con las funciones de grabadora de datos de vuelo y de GPS.

Figura 5. GPS y grabador de vídeo del AR.Drone 2.0

3.1.3 Motores y alimentación

El equipo dispone de 4 motores eléctricos sin escobillas de tipo inrunner, de potencia 14.5W y 28,500 rpm.

La alimentación del sistema se realiza por medio de una batería recargable Li-Po de 3 celdas (3S) 1000 mAh,

con la que se consigue una autonomía de unos 10-15 minutos, aproximadamente.

A B

C D

Figura 6. Componentes del AR.Drone 2.0: Cámara frontal (A); sensor de ultrasonidos y cámara cenital (B);

batería (C) y navigation board (D)

3.1.4 Nociones básicas del AR.Drone

El AR.Drone, como cualquier aeronave, tiene seis grados de libertad, ya que no está restringida ni la posición

ni la orientación. Por tanto, se utilizan como coordenadas en la navegación aérea los tres ejes cartesianos y los

Descripción del Equipo 12

ángulos de Tait-Bryan: alabeo (Pitch), cabeceo (Roll) y guiñada (Yaw). Estos sistemas de coordenadas están

definidos en el UAV tal y como se ilustran en la figura 7.

Figura 7. Sistema de coordenadas del AR.Drone 2.0 [32]

3.1.5 Arquitectura de control

La arquitectura de control consiste en varios bucles en los que el piloto humano se encuentra embebido. El

piloto, mediante un dispositivo, puede enviar órdenes de alto nivel y visualizar la cámara al mismo tiempo.

Figura 8. Arquitectura de control [33]

3.2 Software

El AR.Drone 2.0 está pensado como un UAV de uso recreativo y orientado a dispositivos móviles. Por ello, la

empresa creadora del dron, Parrot SA, desarrolló una aplicación oficial para Android e IOS para pilotar el

dron, grabar vídeos y compartirlos fácilmente,…

Figura 9. Captura de la aplicación oficial, AR.FreeFlight

Sin embargo, el entorno de trabajo iba a ser Windows, sistema operativo en el que no se encontraba disponible

ninguna aplicación ni software oficial. Se decidió usar Matlab para realizar el proyecto, debido a la gran

capacidad computacional que ofrece, y a su sencillo lenguaje de programación y popularidad. Sin embargo, la

elección de Matlab como lenguaje de programación acarreó varios inconvenientes, que se explicarán a fondo

en el siguiente capítulo.

Además, se tenía como base una API (Application Programming Interface) en el intercambio de archivos de

Mathworks, llamada Drone ARDrone_Matlab_V1 [32], que consiste en un kit de desarrollo que permite

realizar tareas básicas con el AR.Drone mediante Matlab. De esta manera, se podían recibir datos

decodificados del UAV y enviar órdenes muy simples de control, como despegar, aterrizar, y mover en alguna

dirección. También permitía recibir la señal de vídeo, pero solo en Mac OS (Operating System). Estas

funciones sirvieron como toma de contacto y fueron modificadas y ampliadas para el proyecto.

También se disponía de un SDK (Software Development Kit) en Simulink, llamado AR Drone Simulink

Development-Kit V1.1. En él había una serie de modelos que permitían el control y el seguimiento de

trayectorias del dron. Estos modelos resultaron útiles para simulación, pero tenían muchos fallos en la

implementación en el dron, así que se creó un SDK propio, aunque algunos modelos sirvieron de base para la

estimación de la posición.

Para la realización de las interfaces se hace uso de la herramienta GUIDE de Matlab. GUIDE (entorno de

desarrollo de GUI) proporciona herramientas para diseñar interfaces de usuario personalizadas. Mediante el

editor de GUIDE, es posible diseñar gráficamente la interfaz de usuario. GUIDE genera entonces de manera

automática el código de MATLAB para construir la interfaz, el cual se puede modificar para programar el

comportamiento de la app.

Descripción del Equipo 14

Figura 10. Cuadro de diálogo de GUIDE

Las GUI (también conocidas como interfaces gráficas de usuario o interfaces de usuario) permiten un control

sencillo (con uso de ratón) de las aplicaciones de software, lo cual elimina la necesidad de aprender un

lenguaje y escribir comandos a fin de ejecutar una aplicación.

Las apps de MATLAB son programas autónomos de MATLAB con un frontal gráfico de usuario GUI que

automatizan una tarea o un cálculo. Por lo general, la GUI incluye controles tales como menús, barras de

herramientas, botones y controles deslizantes.

La parte del código más importante del .m son los llamados Callbacks, que hace referencia a la subrutina que

se ejecutará cuando se realice una determinada acción sobre el elemento en cuestión [35]. Por ejemplo, un

botón activará su callback cuando el usuario haga click sobre él.

Figura 11. Callback de un botón (GUIDE)

Figura 12. Pantalla de creación de interfaz de GUIDE

Una aplicación GUIDE está formado por dos archivos: .m y fig. El primero es el que contiene el código

correspondiente a los elementos de la interfaz, mientras que el segundo almacena los elementos

gráficos

De esta manera, cuando se añade un elemento en GUIDE, automáticamente se genera el código

correspondiente en el .m.

Descripción del Equipo 16

4 INTERFAZ GRÁFICA PARA EL

CONTROL Y MONITORIZACIÓN

La interfaz que se presenta en este capítulo cumple las funciones de monitorizar y controlas, de manera básica,

el UAV. De esta forma, mediante botones y tablas sencillos intuitivos se podrá controlar el dron de manera

manual o automática seleccionando misiones; visualizar las distintas señales que ofrecen los sensores del dron

u observar, en tiempo real, las imágenes captadas por el equipo.

Figura 13. Interfaz gráfica de control y monitorización

Interfaz Gráfica para el Control y Monitorización 18

Hay que mencionar que la idea inicial es que estas tareas se realizaran en paralelo. Esto es, que pudiera

controlarse el dron, a la vez que tiene lugar la recepción y muestreo de datos, se guarden los datos necesarios

en una base de datos y se observe el vídeo en tiempo real. Esta funcionalidad se logró de manera aceptable,

pero fue un proceso muy costoso porque uno de los principales problemas que tiene Matlab es que no se

pueden realizar procesos en paralelo que se comuniquen entre sí.

A continuación se detallan los distintos componentes en los que se divide la interfaz.

4.1 Comunicación con el AR Drone

La comunicación con el dron se realiza mediante AT (Attention) Commands. Este tipo de comandos se envían

al AR.Drone en forma de paquetes UDP (User Datagram Protocol) o TCP (Transmission Control Protocol).

Las cadenas de caracteres son codificadas como caracteres ASCII (American Standard Code for Information

Interchange) de 8 bits. La longitud máxima del comando es 1024 caracteres, y debe de transcurrir un tiempo

de 30 ms entre cada comando. Esta última característica es muy importante, porque si no se tiene en cuenta

puede producir la pérdida de información.

Cada paquete UDP debe contener, al menos, un comando, si no se considerará erróneo. Si un paquete contiene

más de un comando, deberá introducirse una línea especial para separarlos (“\r 0x0A”), tal y como se indica en

[33].

La sintaxis de cada comando tiene la siguiente forma:

AT*[nombre del comando] = [número de secuencia decimal][argumento 1, argumento 2,..] <LF>

Donde:

Número de secuencia: Es un número entero positivo que representa el último comando que se ejecutó.

Cuando se establece una conexión por alguno de los puertos habilitados, el AR.Drone esperará a

algún comando que contenga un número de secuencia mayor, de modo que cada comando deberá

tener un número de secuencia mayor que el anterior para que el dron lo acepte como válido. El primer

comando que reciba el dron deberá tener como número de secuencia el 1.

Argumentos: Puede ser una cadena de caracteres, un valor flotante o un entero con signo.

Nombre del comando: Los más importantes son los siguientes:

AT*REF: Se usa para el despegue aterrizaje, reset o parada de emergencia

AT*PCMD: Para controlar el movimiento del UAV.

AT*FTRIM: Sirve para establecer la referencia con el plano horizontal. Es muy importante

puesto que hay que enviarlo en el inicio de cada vuelo. Si no, el giróscopo puede tener error

acumulado y el vuelo del dron será inestable.

AT*CONFIG: Para configurar el AR.Drone

AT*COMWDG: Se utiliza para reiniciar el watchdog.

En la comunicación se usan los siguientes puertos [35]:

Puerto 5556: Paquetes UDP con comandos normales.

Puerto 5554: Recepción de paquetes UDP del AR.Drone. Estos paquetes se llaman navdata, están

codificados y contienen la información básica del don (velocidad, batería,

Puerto 5555: Se reciben paquetes de video del UAV. El vídeo tiene códec H.264

Puerto 5559: Paquetes TCP con datos críticos que no pueden perderse por el camino. Normalmente

suelen ser relativos a la configuración.

Hay que destacar que el cliente es desconectado automáticamente si transcurre un tiempo de 2 segundos desde

que se envió el último comando. Esto tiene mucha relevancia si se quiere estar recibiendo continuamente datos

del dron.

4.2 Problema con el paralelismo

La idea inicial de la interfaz es que hubiera un hilo o proceso principal que controlara a una serie de hilos

secundarios que se ejecutarían en paralelo y que se encargaran cada uno de las distintas actividades: control

manual, recogida de datos, almacenamiento en base de datos, gráficas,… Sin embargo, esta idea no fue posible

implementarla en Matlab, debido a que no se pueden crear procesos multihilos explícitamente o, por lo menos,

no con la funcionalidad deseada.

Hay varias maneras de implementar procesos paralelos en Matlab, véase [34] :

Usando funciones Java, C/C++ o .Net: Es posible implementar otros lenguajes en Matlab. Por

ejemplo, Java es usado en la programación de GUIs. Si estos lenguajes permiten crear procesos

multihilos, se puede añadir esta funcionalidad. Estos procesos son más efectivos si son totalmente

independientes del hilo principal de Matlab, pero en este caso nos interesa que no sean

independientes, por lo que habría que sincronizarlos, aumentando la complejidad. Java o .Net se

descartaron por la falta de conocimiento sobre la programación de estos lenguajes. En el caso de

C/C++, se pueden compilar en archivos MEX, que pueden ser llamados desde Matlab sin problemas.

Sin embargo, debido a que es necesario un compilador para esto y hubo problemas en la adquisición

y uso de éste, también se descartó esta opción.

Mediante el empleo de temporizadores o timers de Matlab. Estos permiten que el código se ejecute

de manera asíncrona, permitiendo procesos multihilo, ya que cada vez que transcurra el tiempo

impuesto al temporizador, se interrumpe el proceso activo y se ejecuta el callback del temporizador,

con el código que hayamos programado en él. Esto puede ser útil en ciertos casos en los que

sincronicemos el temporizador para que su llamada tenga lugar cuando no se esté ejecutando ningún

otro proceso. Sin embargo, en códigos complejos, como es el caso, esto es muy difícil de cuantificar

y predecir, por lo que no resulta una alternativa viable.

PCT (Parallel Computing Toolbox) [35]: Matlab ofrece un Toolbox en el que se introducen ciertas

funciones que permiten el paralelismo, en casos concretos. Hay que mencionar que es requisito tener

un procesador, clúster o GPU (Graphics Processing Unit) de varios núcleos. De esta manera, se

pueden ejecutar scripts y funciones en los llamados workers, que son motores computaciones de

Matlab. En este toolbox encontramos:

parfor: Bucles for, con la diferencia que las iteraciones se ejecutan en paralelo. El código de

cada iteración debe ser independiente.

spmd: Similar a parfor, solo que se pueden transmitir información entre los workers

asociados a las iteraciones del bucle.

batch: Con este comando se crean workers que realizan tareas, de manera asíncrona, por

separado.

En general, el PCT está orientado a ejecutar códigos con un gran coste numérico y computacional de manera

eficiente. En este sentido, el parfor no nos sirve. El comando spmd, sí que resulta interesante porque permite

realizar procesos en paralelo y es posible la comunicación entre ellos. El principal problema de este comando,

es que el proceso principal se bloquea hasta que acaba el bucle, lo cual impide tener un bucle infinito que esté

Interfaz Gráfica para el Control y Monitorización 20

siempre recogiendo datos del dron, por ejemplo. Además, es necesario el proceso principal, porque es el único

que puede realizar cambios en la interfaz y en las gráficas, los workers no pueden (y si se ejecuta la interfaz en

un worker, ésta no es visible, pues está corriendo en segundo plano). Por último, el comando batch, aunque no

resuelve los problemas, puede resultar útil para resolver ciertas tareas, ya que no bloquea el proceso principal.

De este modo, el problema del paralelismo se resolvió haciendo uso del comando batch, haciendo que haya

workers que realicen ciertas tareas en paralelo. Tiene el inconveniente de que los workers no pueden

comunicarse directamente entre sí, pero esto se soluciona creando un sistema de ficheros en los que se

almacena y se lee la información entre trabajadores. No es una solución óptima, pero permite en gran medida

la ejecución de procesos en paralelo. La mayoría de los procesos se realizarán en un worker de manera

paralela, salvo el control manual, el sistema de emergencia y la actualización de las gráficas y el vídeo.

En la figura 14 se observa la estructura de los procesos o hilos. Hay un hilo principal, en el que se pueden

realizar distintas tareas, y tres hilos secundarios, algunos de los cuales tienen que comunicarse con el principal.

Figura 14. Esquema de los procesos en la interfaz

4.3 Panel de conexión

En este panel se realiza la conexión con el AR Drone. Como se ha comentado en apartados anteriores, el dron

se conectará, en este caso con el ordenador, mediante Wi-Fi. Para establecer la conexión, hay que abrir, desde

Matlab, los canales UDP y TCP necesarios y conectarlos a los puertos correspondientes. Posteriormente, se

pedirá un ACK (acknowledgement) para comprobar la recepción y el envío de datos. Si la conexión se

establece correctamente, nos informará de ello en el cuadro de información y se abrirá la pantalla principal de

la interfaz.

Figura 15. Panel de conexión

Por otro lado, cuando se establece la conexión se inician los hilos de toma de datos y de recepción del vídeo.

El funcionamiento de estos hilos se explicará más adelante. Cuando se cierre la conexión, se cerrarán los

workers que estén trabajando con estos hilos, aspecto muy importante, porque si no se cierran, se quedan en

segundo plano consumiendo recursos sin que el usuario se dé cuenta.

En este panel también se podrá cerrar la conexión con el dron. Para ello, se cerrarán los canales abiertos

anteriormente y la interfaz. Además, se abrirán dos GUI en las que se preguntará si el usuario desea almacenar

los datos del log del vuelo y el vídeo completo del vuelo. Si se aceptan, se guardarán en sus carpetas

correspondientes, si no, se borrarán.

Figura 16. Guardar o no el último log.

Figura 17. Almacenar vídeo del vuelo o no

Interfaz Gráfica para el Control y Monitorización 22

Además, en este panel se podrá realizar la calibración del dron. Esto consiste en inicializar los valores del

giróscopo. Esto hay que realizarlo cada vez que el dron despega, pues, en caso de que no se haga, se acumulan

errores en el giróscopo, provocando que el dron tenga un vuelo más inestable y menos preciso, ya que esl

controlador incorporado en el UAV hace uso de los valores del giróscopo. Por ejemplo, el no calibrar puede

inducir que el AR.Drone se tambalee de un lado a otro cuando debería estar en una posición estable, en modo

hover.

4.4 Control manual

En este panel enviaremos órdenes básicas al dron, tales como despegar, aterrizar, o moverse en alguna

dirección. Estas acciones están asociadas a unas determinadas teclas del teclado, aunque se permite

modificarlas dentro de la propia interfaz. De este modo, cuando pulsemos en alguna de esas teclas con el

control manual activado, se realizará la acción correspondiente.

Para garantizar la seguridad, se ha diseñado de tal forma que, si el dron está realizando una misión y se

presiona el control manual, el UAV detiene la acción que estaba llevando a cabo y se queda en modo hover, es

decir, estabilizado a una determinada altura del suelo. De este modo, siempre podremos tomar el control

manual del dron si observamos algún peligro u obstáculo cercano o cualquier otro problema que pueda surgir.

Además, en este panel se encuentra el botón de emergencia. Este botón, cuando se presiona, detiene cualquier

acción que el dron esté llevando a cabo, como el control manual, sólo que además ordena al dron a aterrizar.

Para que no tenga problemas de funcionamiento, el sistema de emergencia cierra los canales de comunicación

abiertos y crea los suyos propios, desconectándolos al aterrizar. El sistema de emergencia se activará también

si se pulsa el botón de detener la conexión.

Por tanto, la diferencia entre ambos sistemas de seguridad es que en el de emergencia el dron se detiene

completamente y aterriza, mientras que el de control manual es menos directo, pues se toma el control del dron

sin desconectarlo.

Cabe destacar hay que tener cuidado con pulsar varias veces o demasiado tiempo una tecla, pues las acciones

se pueden acumular en la cola, siendo el movimiento resultante distinto al deseado.

Figura 18. Panel de control manual

Además, las teclas asociadas al movimiento del dron no son fijas, ya que si se pulsa en Change Keys con una

acción del panel seleccionada, se abrirá una ventana y se preguntará a qué nueva tecla quiere asociarse el

movimiento. Se podrá elegir cualquier tecla que no haya no esté repetida con otra y sea una tecla válida

(cualquier letra o número, las flechas, enter, alt, control, shift).

Figura 19. Cambio de tecla

4.5 Panel de misiones

En este elemento de la interfaz se gestionan las misiones. Estas misiones han debido ser previamente

progamadas en Matlab, bien por el usuario o bien porque vienen por defecto. En este panel podremos

seleccionarlas e importarlas, así como empezarlas, pausarlaz, detenerlas o cambiar su descripción.

Los botones de “Stop” y “Pause” estarán deshabilitados, hasta que haya una misión activa. Al presionar

“Stop” se aborta la misión y hace que el drone aterrice. Por otro lado, si es el botón de pausa el que se

presiona, se deja la misión pausada, manteniendo el drone en el aire. Presionando el botón de “Play” se

volverá a la ejecución de la misión por el lugar al que estaba.

Esta pausa y ejecución no es tarea sencilla, ya que en Matlab no se puede detener un código en ejecución y

continuarlo por donde estaba. Para realizar esto, se aprovecha el hecho de que las misiones se ejecutarán en

paralelo mediante el comando batch. Al ejecutar una misión, se usan una serie de funciones de movimiento

básicas, que se encuentran en la API. Estas funciones se modifican para que pregunten siempre si está a 1 una

variable binaria que se crea al ejecutar cada misión, y se almacena en un fichero .txt al que tienen acceso tanto

el hilo principal como el worker encargado de la misión. Así, realmente no se pausa la misión, si no que se

mantiene en un bucle indefinidamente hasta que al pulsar el botón de reanudar se cambia el valor de la

variable en el fichero. Sin embargo, esto tiene una gran desventaja, y es que hay que tener en cuenta que no se

podrán pausar las misiones dependientes del tiempo.

Interfaz Gráfica para el Control y Monitorización 24

Figura 20. Panel de misiones

4.6 Gráficas y toma de datos

Se muestran los siguientes datos de vuelo en tiempo real: la posición, la velocidad, la aceleración y el nivel de

la batería.

Estos valores se leen continuamente, mediante un hilo que está continuamente preguntando al AR.Drone por

ellos. Posteriormente, el hilo los almacena en un fichero de texto. La idea inicial es que se guardaran en una

base de datos, pero el proceso era algo más lento, aunque se estudiará su implementación en el futuro. Este

fichero podrá ser borrado al finalizar el vuelo, tal y como se indicó en el apartado de conexión.

La representación de los datos, por el contrario, no puede realizarse en un hilo paralelo, pues tiene que hacerse

dentro del mismo hilo principal de la interfaz para que los cambios en las figuras tengan efecto. Esto acarrea

un problema, pues las gráficas deberían actualizarse continuamente y esto afectaría al control manual y al

sistema de seguridad. Para solucionarlo, las gráficas se actualizan con un temporizador, con un tiempo de

disparo de 500ms, más que suficiente para apreciar los cambios en las gráficas y, además, permitiendo el uso

del resto de funciones de la interfaz. Así, al pausar las gráficas se pausa el timer, y al reanudarlas vuelve a

ponerse en marcha. Los datos que se representan en las gráficas en cada muestreo son los últimos que han sido

almacenados en el último fichero del vuelo actual.

Figura 21. Panel de gráficas

La velocidad, aceleración y batería se toman directamente del dron, mientras que la posición hay que estimarla

mediante alguno de los métodos descritos en el capítulo 5.

Hay que comentar que el fichero en el que se almacena el log del vuelo se guarda en una carpeta con la fecha

del vuelo y un número indicador del vuelo. Habrá un número de vuelo por cada conexión realizada cada día.

Además, para que no se cree un único fichero demasiado grande, se impone un número máximo de 200 líneas,

creándose varios ficheros por cada vuelo. El fichero tendrá la siguiente estructura:

“Log__FlightNumber_X__Part__Y.txt”, donde “X” es el número de vuelo actual e “Y” es la parte del fichero

correspondiente.

4.7 Imágenes y vídeo

En este panel se podrá ver el vídeo en vivo que recibe la cámara del drone. En la parte de abajo, podrá

procesarse las imágenes según los filtros que se ven a la derecha. También existe la opción de realizar una

fotografía, cambiar entre la cámara frontal y vertical del AR.Drone o comenzar a grabar y detener la

grabación.

Interfaz Gráfica para el Control y Monitorización 26

Figura 22. Panel del vídeo

La visualización del stream de vídeo en Matlab no es inmediata, debido a que Matlab no puede reproducir el

códec H.264 con el que el AR.Drone realiza la transmisión del vídeo. Por tanto, se ha tenido que hacer uso de

un programa externo, FFmpeg [37], que es una colección de software libre para la grabación y conversión de

audio y vídeo. Este programa sí permite la decodificación del vídeo del UAV.

El primer acercamiento fue intentar reproducir el stream a través de ffplay, un reproductor multimedia que

contiene el programa. El resultado fue que se obtenían las imágenes, pero con un retraso de, aproximadamente,

5 segundos, un tiempo demasiado grande si se quieren realizar aplicaciones en tiempo real o si se está

visualizando y se quiere esquivar un obstáculo. Tras esto, se probó con convertir el vídeo a un formato

soportado por Matlab, como por ejemplo el mjpeg, pero también transcurría demasiado tiempo durante la

conversión y posterior visualización en la interfaz, además de que en Matlab hay que tratar con objetos de

vídeo terminados, no se puede visualizar un streaming.

Al final, la estrategia que se siguió fue convertir el vídeo en imágenes jpeg, que se almacenan en una carpeta a

la que Matlab tiene acceso. Las imágenes se obtienen con un frame rate de 10 FPS o, lo que es lo mismo, se

captura una imagen cada 0.1 segundos.

Posteriormente, cuando se pulsa el botón de reproducir en la interfaz, se muestra continuamente la última

imagen disponible en la carpeta, obteniéndose al reproducirse a gran velocidad el vídeo en tiempo real. El

comando necesario para que se ejecute el ffmpeg y se comiencen a guardar las imágenes es el siguiente:

ffmpeg -i tcp://192.168.1.1:5555 -r 10 -s hd720 -f image2',{' '},images_name,'_%5d.jpeg

El cual debe ser ejecutado dessde el símbolo del sistema o desde Matlab mediante la función system. El

argumento images_name, es el nombre con el que se guardarán las imágenes en el ordenador, -r hace

referencia al ratio de captura de imágenes, -s indica el tamaño de la imagen y -f expresa el formato de salida.

Si se pulsal el botón de parar la grabación, se detiene la conexión con el dron, o se cierra la interfaz principal o

la de vídeo, se eliminarán todas las imágenes capturadas por ffmpeg, se detendrá el hilo de captura de estas

imágenes y se podrá almacenar el vídeo en formato avi. En el primer caso se almacenará obligatoriamente,

mientras que en los otros se nos dará la opción de guardar el vídeo o no. El vídeo se generará con la función

VideoWriter de Matlab,

Este vídeo se almacenará en formato “.avi” con el nombre “FlightNumber_X__Video_recorded_Y.avi”. Al

igual que los datos almacenados en los ficheros “.txt”, “X” es el número de vuelo actual, mientras que “Y”

indica el número del vídeo de cuantos se han almacenado durante ese mismo vuelo.

También es posible tomar fotografías guardándose la imagen que se está mostrando en la pantalla superior.

Esta imagen se guarda en formato .jpeg con el nombre “FlightNumber_X__Photo_Y.avi”.

Interfaz Gráfica para el Control y Monitorización 28

5 ESTIMACIÓN DE LA POSICIÓN

5.1 Estimación por visión monocular

5.1.1 Calibración de la cámara

Es necesario calibrar la cámara para así obtener los parámetros intrínsecos y los coeficientes de distorsión, que

serán necesarios para poder estimar la posición.

Existen diversos programas y lenguajes que te permiten calibrar la cámara (ROS, opencv, algún toolbox de

Matlab,….). En este caso se usará opencv.

Para realizar la calibración, hay que tomar una serie de fotos de un tablero estilo ajedrez, es decir, un papel,

cartón, etc dividido en cuadrículas blancas y negras. Esto se hace así porque los algoritmos que sirven para

calibrar detectan las esquinas, basándose en los gradientes, y es más fácil si es en blanco y negro, pues el

gradiente es máximo al pasar de una cuadrícula blanca a una negra y viceversa.

Hay que medir la longitud y la altura de una cuadrícula porque el programa requiere de esa información para la

calibración. En la siguiente imagen se muestra una foto de ejemplo que se pasaría al programa:

Figura 23. Tablero para la calibración de la cámara

Estimación de la Posición

30

Una vez se le pasan estos datos al programa, éste devuelve los siguientes parámetros:

Distancia focal: fx, fy

Coordenadas del punto principal: cx, cy

Coeficientes de distorsión: k1, k2, p1, p2 , r

La distancia focal es la distancia desde el centro óptico del lente hasta el sensor cuando la lente está enfocada

al infinito.

Por otro lado, el punto principal es el punto determinado por la proyección ortogonal del centro de proyección

sobre el plano de la imagen. Idealmente debería estar en el centro de ésta pero, debido a la distorsión, no es así.

Las coordenadas del punto principal y la distancia focal dan lugar a la matriz intrínseca de la cámara, que,

combinada con la matriz extrínseca, relaciona las coordenadas, en píxeles, de los puntos en el plano de la

imagen, con las coordenadas 3D:

Ecuación 1

De esta manera, realizando la calibración de la cámara frontal del AR Drone Parrot obtenemos:

Cx = 307.433982

Cy = 190.144373

k1= -0.507580

k2= 0.249110

f = 561.8909

Donde los coeficientes están expresados en mm.

5.1.2 Algoritmo

El algoritmo tiene la siguiente estructura:

Operaciones de inicialización: Gráficas, variables, filtro de Kalman, definición del número inicial y

final de las imágenes que le vamos a pasar.

Bucle principal: Se recorre una y otra vez hasta que se leen todas las imágenes:

Detección de puntos: Fast Corner Detection

Fase de predicción del EKF (Extended Kalman Filter): x k-1|k-1, Pk-1|k-1 → x k|k-1, Pk|k-1

Predicción de medida: x k|k-1, Pk|k-1 → h k|k-1, Sk|k-1

Lectura de la siguiente imagen

Búsqueda de puntos individualmente compatibles: h k|k-1, Sk|k-1 → zIC

Hipótesis RANSAC (Random sample consensus) con 1 punto.

Fase de corrección parcial del Filtro de Kalman Extendido: x k-1|k-1, Pk-1|k-1, zli_inliers → x k|k, Pk|k

Obtención de inliers de alta innovación

2ª corrección parcial del EKF: x k-1|k-1, Pk-1|k-1, zhi_inliers

→ x k|k, Pk|k

31 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Representación de imágenes por pantalla

A continuación, se explicará en detalle cada apartado del algoritmo.

5.1.2.1 Detección de puntos

Para hallar los puntos que se usarán para estimar la posición, se usa el algoritmo llamado fast corner detection.

Este método detecta las esquinas en una imagen. Para ello, hace uso de los gradientes (indica el mayor cambio

posible en la intensidad para cada punto de la imagen).

De esta forma, al algoritmo se le pasa una imagen en tonos de gris y un determinado valor de umbral, y

devuelve las esquinas halladas. Cuanto mayor sea el umbral habrá menos errores de puntos que no sean

esquinas, pero también se reduce el número de puntos detectados.

Para hallar el gradiente de manera rápida, se compara la intensidad de un punto, sumada al valor del umbral,

con el de sus vecinos. Si este valor es mayor o menor que el resto, se considera una esquina. Posteriormente, se

hace una segunda pasada, más restrictiva, para quedarnos solo con las esquinas que sean máximas.

Figura 24. Detección de puntos

En la figura, se puede observar como los puntos rojos serían las esquinas finalmente detectadas, mientras que

los verdes son puntos desechados en la segunda iteración del algoritmo.

Los puntos detectados como esquinas se añaden al vector de estados x k-1|k-1.

5.1.2.2 Fase de predicción del EKF y búsqueda de puntos compatibles

Se realiza la fase de predicción del Filtro de Kalman Extendido, tal y como se muestra en la ecuación. Se

estima el vector de estados, xk-1|k-1, en el instante k-1.

Ecuación 2

Estimación de la Posición

32

En la ecuación anterior, uk representa la se, Fk es el jacobiano de la función fk con respecto al vector de estados

en el instante k; Qk hace referencia a la matriz de covarianza del proceso y Gk es el jacobiano del ruido

respecto al vector de estado

Tras esto, se realiza la fase de predicción del del modelo de observación o medida, hi:

Ecuación 3

Hi es el jacobiano de la función de medida, h i. Para hallarla, se parte de que la cámara se modela como una

cámara estenopeica (pinhole), en el que se tiene en cuenta la distorsión, como se desarrollará más adelante. Ri

es la covarianza del ruido gaussiano de la medida.

Una vez hecho esto, se buscan los puntos de las dos imágenes que sean compatibles. Para ello, la medida zi se

busca en la región de probabilidad del 99% definida por la gaussiana N (h i, Si, ). Además, se asegura que sean

compatibles geométricamente para que no haya errores.

5.1.2.3 RANSAC de 1 punto

RANSAC es un método iterativo para calcular los parámetros de un modelo matemático de un conjunto de

datos observados que contiene valores atípicos. Normalmente, el algoritmo RANSAC, dado un conjunto de

datos y un modelo (además de otros parámetros como el número mínimo de valores necesarios, el umbral para

que un punto se considere parte del modelo o el máximo número de iteraciones), te devuelve el mejor modelo

que se adapta a los datos y los inliers para ese modelo.

Esta variación del algoritmo difiere en que también se envía como dato el vector de estados y, gracias a esto, se

puede reducir el número de hipótesis y el tiempo de cálculo, pues se disminuye a un punto el tamaño mínimo

del conjunto de datos necesarios para el modelo.

El algoritmo tendrá la siguiente estructura:

Como se puede observar, se parte de un número inicial de hipótesis. Se selecciona un valor de medida,

Con este valor se realiza la corrección del EKF parcial. Hay que destacar que solo se corrige el vector de

33 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

estados, y no la matriz de varianza, P, con lo que se consigue simplificar y reducir el tiempo de cálculo, al

ahorrarse el cálculo y la multiplicación de matrices de gran tamaño en cada iteración.

Posteriormente, con el valor del umbral, se estiman los inliers para el modelo y el punto con el valor de

escogido.

Al final de cada iteración, se almacena el valor de los inliers siempre que se obtenga el número máximo de

inliers hasta el momento de la iteración. Con esto se consigue que, una vez recorridos todas las hipótesis

posibles, nos quedemos con la que mayor número de inliers produce.

El número de hipótesis se recalcula al final de cada iteración.

Al final del algoritmo tenemos un conjunto de inliers, llamados inliers de baja innovación.

5.1.2.4 Fase de corrección del EKF con inliers de baja innovación

Se realiza la fase de corrección del Filtro de Kalman Extendido, con los inliers de baja innovación, zli_inliers

:

Estos hacen referencia a los puntos que concuerdan con la hipótesis más respaldada. De esta forma, se asume

que son producidos por el modelo real, pues se encuentran a una distancia pequeña de la hipótesis con mayor

similitud con los datos. Esto no significa que el resto de puntos sean outliers, ya que pueden ser inliers, solo

que se encuentran más lejos de la hipótesis seleccionada.

Estos puntos que no son reconocidos como inliers son muy importantes, ya que suelen corresponder a puntos

distantes en la imagen que son los más útiles para estimar la rotación de la cámara. Por ello, habrá que tenerlos

en cuenta.

Primero se realiza la fase de corrección del EKF sobre los inliers y la matriz de covarianza.

Ecuación 4

Kk es la ganancia de Kalman en el instante k.

5.1.2.5 Fase de corrección del EKF con inliers de alta innovación

Tras la corrección del EKF de los inliers de baja innovación, el error en la predicción del filtro de Kalman se

habrá corregido en gran medida, así como la covarianza habrá disminuido.

Así, se podrán recuperar inliers que se consideraron outliers en una primera aproximación. A estos inliers se

les llama de alta innovación. Para ello, se considerarán inliers de alta innovación si se encuentran en la región

de probabilidad del 99% para la Gaussiana de la nueva medida predicha, hj ~ N (h

j, S

j).

Con estos nuevos inliers, se realiza la segunda parte de la fase de corrección del Filtro de Kalman Extendido.

Hay que decir que el dividir la fase de corrección del EKF en dos no supone un aumento del coste

computacional.

5.1.3 Parametrización mediante profundidad inversa

Tras explicar el funcionamiento general del algoritmo, se explicará en este subapartado la aplicación del

mismo a la cámara monocular del AR.Dronde 2.0.

Estimación de la Posición

34

5.1.3.1 Definición del vector de estados y del modelo dinámico de la cámara

El vector de estados contendrá parámetros de la cámara., xC, y del mapa, y. Al disponer únicamente de

información visual de una secuencia monocular, se usará el modelo de velocidad constante, tanto linear como

angular, tal y como se indica Castellanos [39].

El vector de estados de la cámara estará formado por la posición, rCk, la orientación, qck, la velocidad linear, v,

y la angular, ω. Estos parámetros están referidos a un sistema de referencia estático, W.

Ecuación 5

El modelo de la velocidad constante es el siguiente:

Ecuación 6

Donde VW

y ΩW

son distribuciones gaussianas producidas por la aceleración:

Ecuación 7

Respecto a los parámetros del mapa, se usarán dos parametrizaciones diferentes, la euclídea XYZ y la de la

profundidad inversa.

En la parametrización por profundidad inversa, un punto 3D de la escena se define con un vector de 6

parámetros:

Ecuación 8

Expresado en coordenadas cartesianas:

Ecuación 9

El vector yi simboliza el rayo desde la primera posición de la cámara desde donde el punto fue observado por

el centro óptico de la cámara, xi, yi, zi y los ángulos azimut y elevación, θi, ϕi. La profundidad del punto, di, se

expresa como su inversa, 1/di.

35 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Figura 25. Parametrización por profundidad inversa [39]

Si la ecuación de proyección es suficientemente linear, las coordenadas se convierten a la parametrización

euclídea (XiW

, YiW

, ZiW

).

5.1.3.2 Modelo de medición

Se parte de que la cámara se modela como una cámara estenopeica (pinhole), en el que se tiene en cuenta la

distorsión radial. Primero, los puntos se transforman al sistema de referencia de la cámara:

Ecuación 10

Donde

representa la matriz de rotación.

Ahora se proyectan los puntos usando el modelo pinhole de la cámara, y se aplica el modelo de distorsión,

resultando:

Ecuación 11

Donde u0 e v0 representan las coordenadas del centro de la imagen, mientras que k1, k2 y r son coeficientes de

distorsión hallados en la calibración de la cámara.

Estimación de la Posición

36

5.1.4 Pruebas y resultados

Se han realizado algunas pruebas para testear el algoritmo, aunque habría que realizar bastantes más.

Al ejecutar el script principal, se obtendrían una sería de imágenes como las que se muestran en la figura 26,

en la que se realiza una prueba haciendo volar al dron aproximadamente 0.8 m hacia delante y hacia atrás.

Figura 26. Estimación de posición por visión

En la parte izquierda se muestra las imágenes tomadas por la cámara, con los puntos característicos o features

representados, con un color distinto según el caso. Así:

Rojo delgado: Inliers de baja innovación

Rojo grueso: Inliers de alta innovación

Magenta: Puntos rechazados por RANSAC

Azul: Puntos característicos a los que no se les ha encontrado su punto compatible en la imagen

anterior.

En la parte derecha, por otro lado, se representa la trayectoria (en metros) seguida por la cámara, vista desde

arriba, en el plano XY. Así podemos hacernos una idea de si la posición está siendo bien estimada o no.

En las diversas pruebas realizadas, se ha llegado a conseguir un tiempo de ejecución del algoritmo de,

aproximadamente, 0.1 segundos. Este tiempo es demasiado alto como para aplicar el programa en tiempo real,

pero se acerca bastante. Hay que decir que se pueden realizar mejoras para reducir este tiempo.

Por otro lado, se han intentado medir los errores cometidos en la estimación de la posición. Sin embargo, esta

medición es complicada puesto que no se conocen los datos reales de la posición del drone a lo largo del

tiempo, ya que, al estar en interiores, no se pueden obtener con GPS. Aun así, se puede indicar un orden

aproximado del error en la estimación del 8%.

37 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Este valor de error puede parecer muy elevado, aunque realmente se trate de 0.1 metros.

Los valores de tiempo de ejecución y error son muy variables y, normalmente, opuestos. Por eso hay que

intentar buscar una solución de compromiso entre ambos.

En esta otra prueba se hace rotar al drone y mover en una trayectoria curva. Se observa cómo empieza

estimando varios puntos y acaba con solo un par de puntos válidos, debido a las condiciones del entorno.

Además, si se sigue avanzando en la prueba, el algoritmo acaba dando error, pues se encuentra con una pared

blanca y es incapaz de encontrar puntos característicos.

Figura 27. Prueba de la estimación por visión

Se realiza una última prueba con objetos muy cercanos. Esto provoca una mala estimación pues el algoritmo

funciona mejor si se obtienen puntos lejanos para estimar la rotación y puntos cercanos para estimar la

traslación.

Estimación de la Posición

38

5.1.5 Conclusiones

Se ha comprobado que el método no se puede aplicar al tiempo real, aunque se queda bastante cerca y, si se

mejora, se puede usar perfectamente. Lo mismo se puede decir de los errores, tienen un valor alto, pero hay

margen de mejora.

El tiempo de respuestase puede reducir, tal y como se expone Civera en [39], donde se logra un tiempo de

ejecución de 20ms. Para ello, y además disminuir el error cometido, se puede combinar el algoritmo con datos

del dron. Por ejemplo, el AR Drone 2.0 ofrece datos de la velocidad del drone en tiempo real. Este valor se

puede añadir al algoritmo (quitando así la suposición de modelo de velocidad constante de la cámara que se

usa), y se mejorarían ostensiblemente los resultados.

En las pruebas realizadas, se observa que el entorno es un factor primordial. Para empezar, como es lógico, se

supone que en las imágenes no hay objetos en movimiento (si los hubiera se descuadraría todo, ya que podría

hacer el tracking a esos puntos y la estimación sería errónea). Además, si en las imágenes aparecen pocos

objetos distintos (por ejemplo, imágenes de una pared), no se pueden reconocer la cantidad de puntos

necesarios y el algoritmo falla. También hay que destacar que se usa el canal rojo para la detección de

esquinas, y quizás, dependiendo del entorno, esto no sea lo más conveniente.

Por este motivo, hay que ajustar algunos factores del algoritmo para conseguir una buena estimación. En

concreto, el umbral para detectar las esquinas y el umbral de incertidumbre para establecer si los puntos son

compatibles o no. Según como se escojan estos valores, el algoritmo se ejecuta de manera muy distinta. Si el

primer umbral es pequeño y el segundo grande, se detectan muchas esquinas y puntos compatibles, por lo que

el tiempo de ejecución aumenta en gran medida, aunque también el error disminuye, y, si los valores son

estrechos, puede ocurrir que no se lleguen a detectar puntos y el algoritmo devuelva error al no poder estimar

la posición, o se detectan pocos puntos, los suficientes como para estimar la posición de una manera rápida,

aunque también algo imprecisa. Por tanto, hay que buscar una solución de compromiso para que el resultado

sea aceptable, tanto en eficacia como en tiempo de ejecución.

39 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Se pueden mejorar la rapidez del algoritmo implementando funciones en c que realizan algunas funciones más

rápidamente que Matlab. Esto no se ha podido implementar porque no se disponía de licencia para el

compilador de Matlab.

Por último, hay que decir que, aunque el algoritmo no dé grandes resultados, se trata de una primera

aproximación.

5.2 Estimación por integración de la velocidad

El AR.Drone realiza una estimación de la velocidad a través de la cámara situada en su base. Se pueden

aprovechar estos valores para estimar la posición.

Así, almacenando los tiempos en los que se reciben los datos, se puede realizar una integral simple:

Ecuación 12

En donde posf indica la posición actual estimada, posi hace referencia a la posición previamente calculada, v es

la velocidad que es proporcionada por el dron y dt es la diferencia de tiempos entre los dos instantes en los que

se ha producido la estimación.

5.2.1 Pruebas y resultados

Este método es fácilmente implementable en un script de Matlab. Se realizan varias pruebas experimentales

para comprobar la eficacia del estimador. Hay que tener en cuenta que las pruebas han sido de escasa duración

y recorrido debido a la falta de espacio de trabajo.

Estimación de la Posición

40

Figura 28. Estimación de posición por integración de la velocidad

Se observa que la estimación es aceptable, aunque hay ocasiones en las que la estimación se muestra errática.

Esto puede deberse a que el AR.Drone usa la cámara cenital para estimar la velocidad. Esto acarrea los

mismos problemas que la estimación por visón planteada en el apartado anterior, es decir, es necesario tener

una ambiente suficientemente iluminado para tener buenas referencias.

5.3 Estimación por modelo de espacio de estados

Una representación de espacios de estados es un modelo matemático de un sistema físico descrito mediante un

conjunto de entradas, salidas y variables de estado relacionadas por ecuaciones diferenciales de primer orden

que forman una ecuación diferencial matricial de primer orden, tal y como se observa en la figura 29.

Figura 29. Espacio de estados

Donde x representa el vector de estados, y es el vector de salida, u se corresponde con el vector de entradas (o

control), A es la matriz de estados, B es la matriz de entrada, C es la matriz de salida, y D es la matriz de

transmisión directa

Para realizar esta estimación, se parte del SDK AR Drone Simulink Development-Kit V1.1, en el que hay

identificado un modelo en espacio de estados que relaciona la velocidad del dron con las variaciones en los

ángulos pitch y roll. Este modelo mencionado es el siguiente:

41 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Ecuación 13

Ecuación 14

En la ecuación 5, u representa el ángulo pitch y la variable y se corresponde con la velocidad en el eje x,

mientras que en la ecuación 6, estas variables hacen referancia al ángulo roll y a la velocidad del dron en el eje

y, respectivamente.

A partir de estas ecuaciones, pasando al dominio de Laplace, se pueden obtener las funciones de transferencia

que relacionan la velocidad con el cabeceo y el alabeo. Una vez obtenidas éstas, pueden integrarse para

obtener la relación respecto a la posición. El resultado se observa a continuación:

Ecuación 15

Ecuación 16

Ahora se puede obtener un nuevo espacio de estados con los ángulos como variables de entrada y la posición

como las variables de salida, como se muestra en las ecuaciones 9 y 10.

Ecuación 17

Ecuación 18

Además, podemos convertir estas funciones de transferencia al dominio discreto, ya que la implementación

será más sencilla que el espacio de estados. Así usando la transformación bilineal o método de Tustin (veáse la

ecuación ):

Ecuación 19. Método de Tustin

Estimación de la Posición

42

Ecuación 20

5.3.1 Pruebas y resultados

Se realizan las mismas pruebas realizadas con el estimador por integración de velocidad para poder comparar

los resultados

43 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Figura 30. Estimación de posición por espacio de estados

A la vista de los resultados, este método produce una estimación algo más eficaz y menos fluctuante. Para

corrobarlo, se cuantifica el error cometido en ambos métodos:

Error absoluto medio Error relativo medio Error máximo

Integración Espacio de estados Integración Espacio de estados Integración Espacio de estados

Prueba 1 0.033 m 0.02 m 7.2% 3.5% 0.05 m 0.03 m

Prueba 2 0.16 m 0.24 m 6% 11% 0.4 m 0.6 m

Prueba 3 0.23 m 0.15 m 18% 12.5% 0.2 m 0.3 m

Tabla 1. Errores cometidos por los métodos de estimación de la posición

Estimación de la Posición

44

45 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

6 SEGUIMIENTO DE TRAYECTORIAS

6.1 Sistema de control

Con el objetivo de controlar la trayectoria del dron, es necesario diseñar una serie de controladores que se

encarguen de esa tarea. Hay que controlar 4 parámetros: la posición en XYZ y el ángulo de orientación o yaw.

Con estas variables se puede controlar inequívocamente la trayectoria del UAV en cuestión.

Se podría controlar la velocidad en vez de la posición, pues ambos están relacionados directamente y

obteniendo directamente del dron los valores de velocidad en cada instante. Sin embargo, es más intuitivo

controlar la posición. Por tanto, habrá que incluir la estimación de la posición en el algoritmo.

Para controlar la posición se escoge un controlador PID, mientras que para el ángulo de orientación se decide

usar un controlador proporcional, debido a su sencillez. Estos controladores son los más sencillos y los más

usados, debido a su fiabilidad.

De esta manera, los esquemas de control tendrán la estructura presente en la figura 31.

Hay que tener en cuenta que en el control de la posición en el plano XY, el error en la posición no es la entrada

al controlador, pues al estar controlando el ángulo de orientación simultáneamente, hay que incluir una matriz

de transformación para compensar el hecho de que el dron gira a la vez que se mueve:

Ecuación 21

Donde la matriz de transformación está formada por senos y cosenos dependientes del ángulo de orientación

(γ), y ef es el error que servirá como entrada para calcular la acción de control.

Seguimiento de Trayectorias

46

Figura 31. Esquema del sistema de control

6.2 Identificación del sistema

Para poder realizar el control sobre el AR.Drone, hay que identificar el sistema para poder sintonizar los

controladores necesarios. Para ello, se introducen escalones en las referencias y se observa cómo responde el

dron, tanto en el eje X como en el Y. Hay que destacar que las referencias para el movimiento del UAV están

limitadas entre [-1, 1].

Por tanto, se realizan las pruebas para diferentes escalones, y se recogen los datos de las velocidades del

AR.Drone.

47 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Figura 32. Respuesta del sistema ante referencia, en el eje X

Figura 33. Respuesta del sistema ante referencia, en el eje Y

En una primera aproximación, se identifican los parámetros del controlador mediante el método de Ziegler-

Nichols:

X Y

KP 1.4 12

TI 0.2 0.1

TD 0.05 0.025

Tabla 2. Sintonización del PID por el método de Ziegler-Nichols

Este método es simple y poco eficaz, pero sirve como toma de contacto para la sintonización del controlador.

6.3 Interfaz gráfica

Mediante esta interfaz se generan los puntos o waypoints que el dron debe recorrer para realizar la trayectoria

deseada, se enviarán al AR.Drone y se hará un seguimiento de la posición del UAV.

Para ello, el primer paso es elegir la trayectoria deseada. Se puede elegir entre seleccionar los waypoints

Seguimiento de Trayectorias

48

manualmente o generar una trayectoria geométrica de manera automática. Si se escoge la primera opción, hay

que añadir las coordenadas cartesianas de los puntos del recorrido, teniendo en cuenta que el origen de

coordenadas corresponde a la posición inicial en el suelo del AR.Drone. Estos waypoints se añadirán a una

tabla en la esquina inferior izquierda, y siempre se podrán eliminar, añadir o modificar si fuera conveniente.

Por otro lado, se puede elegir una trayectoria con forma de figura geométrica sencilla. Se puede elegir entre un

cuadrado, rectángulo, círculo, pentágono, hexágono, elipse o triángulo. Una vez elegida la figura, hay que

indicar los parámetros básicos pare definirla, como el lado, el radio o las distancias focales, en metros.

Posteriormente, se seleccionan el número de puntos en los que se quiere dividir la trayectoria, y estarán

equidistantemente separados. Una vez generados los waypoints, se generará la trayectoria en la gráfica 3D. Se

podrá rotar o hacer zoom sobre ella.

Los waypoints contendrán la información de la posición en x, y, z, y el ángulo yaw necesarios para realizar la

trayectoria seleccionada.

Cuando se pulse el botón de empezar el seguimiento de la trayectoria, se ejecutará una función a la que se le

pasan los waypoints como argumento, en forma de matriz. Esta función se encargará de controlar al dron para

que recorra la trayectoria deseada, aplicando los esquemas de control definidos anteriormente.

Se considera que el dron alcanza el waypoint objetivo cuando se encuentre en un radio de 30 cm o menos. Se

limitará la velocidad del dron para conseguir mayor precisión, a costa de que el tiempo de ejecución será

mayor. Así se consigue limitar el efecto arco.

Para evitar que al acercarse a los waypoints el drone vaya reduciendo la velocidad hasta pararse, se establece

que siempre haya un mínimo de velocidad para que esto no ocurra.

Figura 34. Interfaz gráfica para la creación y seguimiento de trayectorias

49 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Los datos de la posición del dron se recogerán y se representarán en la gráfica para observar la diferencia entre

la posición real y la deseada.

6.4 Comentarios

Como se puede observar, el seguimiento de trayectorias está incompleto. No se han realizado pruebas para

comprobar la eficacia del controlador seleccionado.

Además, para la sintonización del controlador PID se ha usado el método de Ziegler-Nichols en primera

instancia, pero existen métodos de sintonización mucho más avanzados. Así mismo, se pueden plantear otro

tipo de controladores distintos a los PIDs clásicos.

Por tanto, la interfaz y el algoritmo para el seguimiento de trayectorias tienen mucho campo por delante para

ser desarrollados.

Seguimiento de Trayectorias

50

51 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

7 CONCLUSIONES

7.1 Conclusiones

En este Trabajo Fin de Grado se han propuesto interfaces gráficas, mediante la herramienta GUI de Matlab,

para la monitorización y control del AR.Drone 2.0, así como algoritmos para la estimación de su posición.

La primera interfaz desarrollada sirve para realizar un control básico del UAV. Permite un control manual del

mismo, así como la posibilidad de implementar misiones previamente diseñadas. Además, recoge los datos

más relevantes que el dron proporciona durante el vuelo, almacenándose en ficheros de texto para que puedan

ser consultados en cualquier momento, y representa gráficamente la posición, velocidad, aceleración y nivel de

batería del equipo. También ofrece la posibilidad de ver el vídeo en tiempo real que muestran las cámaras del

AR.Drone, tanto la vertical como la horizontal, y se podrán almacenar las imágenes, tanto individualmente en

formato jpg como en vídeo en formato avi, ya sea el vídeo del vuelo completo o una parte. A su vez, se ha

implementado un sistema de emergencia que detendrá cualquier actividad que esté realizando el dron y le

ordenará aterrizar.

La gran mayoría de las funciones mencionadas que ofrece la interfaz se realizan en paralelo. Esto resultó una

tarea muy compleja, ya que Matlab no permite la implementación de hilos paralelos como tal, ya que, aunque

es posible crear varios hilos, no se pueden comunicar entre sí. Aun así, gracias al Parallel Computing Toolbox

y al uso de ficheros de texto, se solventó el problema.

En relación a la estimación de la posición, se han propuesto dos métodos. El primero consiste en realizar una

estimación mediante las imágenes obtenidas por la cámara del dron, es decir, a través de la visión monocular.

Para ello, se ha implementado un algoritmo que detecta ciertos puntos singulares, normalmente esquinas, y

realiza un seguimiento de dichos puntos en las imágenes sucesivas, calculando la rotación y traslación que

sufren y, a partir de eso, se estima cúanto se ha movido el UAV. El otro método consiste en usar los datos que

proporciona el dron, en este caso la velocidad y los datos del giróscopo. De esta forma, a partir de un modelo

que relaciona el cambio en los ángulos con la velocidad, se integra para obtener la relación respecto a la

posición.

Se han realizado pruebas para comprobar la eficacia de los modelos. Sin embargo, estas pruebas no resultan

concluyentes, ya que han sido escasas y en un entorno poco variable. Además, al no poder hacer uso del GPS,

no se ha podido comparar con total exactitud las medidas estimadas de posición con las reales, aunque sí se ha

obtenido un resultado orientativo.

La estimación de la posición por visión ha resultado ser muy dependiente del entorno. Factores como la

iluminación, el número, forma y color de los objetos en los alrededores, la presencia de formas en movimiento,

Conclusiones

52

influyen en gran medida en los resultados. Además, el tiempo de ejecución es demasiado elevado como para

implementarlo en sistemas de tiempo real. Por tanto, se considera que el algoritmo debe mejorar, y que hay

margen de mejora para ello.

Por último, se ha desarrollado una interfaz para generar trayectorias, y se ha propuesto un método para el

control del seguimiento de dichas trayectorias. Para ello, se ha realizado una identificación del sistema y se ha

hecho una primera elección de los controladores, aunque no se han realizado pruebas. La interfaz está

programada para que genere las trayectorias, se las envíe al dron, y ejecute el control de éste, monitorizando en

todo momento su posición.

Para finalizar, hay que mencionar que este Trabajo Fin de Grado refleja la aportación a un proyecto en curso y

con un alcance mucho mayor, de ahí que se considere que el trabajo desarrollado puede ser revisado, mejorado

y ampliado en un futuro.

7.2 Futuras investigaciones

Como se ha comentado previamente, este trabajo forma parte de un proyecto de mayor entidad, por lo que los

algoritmos y las interfaces propuestas serán revisados y posiblemente modificados.

A la vista de los resultados obtenidos, existen multitud de aspectos que se pueden mejorar y en los que se

pueden profundizar de forma más exhaustiva.

Para aumentar la eficacia del algoritmo de estimación de la posición por visión, se puede combinar el

algoritmo con datos del dron, como la velocidad, quitando así la suposición de modelo de velocidad constante

de la cámara que se usa y mejorando el modelo. Así mismo, en pro de disminuir el tiempo de ejecución del

código, se puede hacer uso de funciones MEX, ya que hay ciertas partes del algoritmo que consumen una gran

cantidad de tiempo, y si se implementaran en C/C++ podrían obtenerse mejores resultados, tal y como se

indica en [41].

Además, se puede seguir investigando en la línea de la visión monocular. Partiendo del algoritmo

implementado, se puede seguir desarrollando con vistas a la detección y reconocimiento de obstáculos, y

estudiar las estrategias para evitarlos. También sería interesante investigar el reconocimiento y seguimiento de

objetos móviles, ya que tiene muchas posibles aplicaciones.

En relación al seguimiento de trayectorias, el trabajo a seguir consistiría en realizar las pruebas para comprobar

la eficacia de los controladores, sintonizarlos de nuevo si fuera necesario, y estudiar la implementación de

controladores más complejos.

53 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Índice de Ecuaciones

Ecuación 1 30

Ecuación 2 31

Ecuación 3 32

Ecuación 4 33

Ecuación 5 34

Ecuación 6 34

Ecuación 7 34

Ecuación 8 34

Ecuación 9 34

Ecuación 10 35

Ecuación 11 35

Ecuación 12 39

Ecuación 13 41

Ecuación 14 41

Ecuación 15 41

Ecuación 16 41

Ecuación 17 41

Ecuación 18 41

Ecuación 19 41

Ecuación 20 42

Ecuación 21 45

Índice de Ecuaciones

54

BIBLIOGRAFÍA

[1] V. Arenas, «El Informador,» 17 febrero 2015. [En línea]. Available:

http://www.informador.com.mx/tecnologia/2014/513403/6/la-venta-de-drones-crece-siete-veces.htm.

[Último acceso: septiembre 2015].

[2] M. Gabriela Serra, «El País: Blogs Planeta Futuro,» 5 marzo 2014. [En línea]. Available:

http://blogs.elpais.com/paz-en-construccion/2014/03/drones-un-mercado-con-un-prometedor-futuro.html.

[Último acceso: septiembre 2015].

[3] C. d. Madrid, «Los Drones y sus aplicaciones a la ingeniería civil,» 2015.

[4] Hemav, «Drones para Agricultura,» 22 mayo 2015. [En línea]. Available: http://blog.hemav.com/drones-

para-agricultura-teledeteccion-agricola/. [Último acceso: septiembre 2015].

[5] J. A. Giménez Blesa, «Drones: Aplicaciones en el Sector Audiovisual».

[6] M. Oñate, «Aplicación de drones a la seguridad».

[7] L. Edwards, «8 best drone quadcopters to buy now,» 19 mayo 2015. [En línea]. Available:

http://www.pocket-lint.com/news/130265-8-best-drone-quadcopters-to-buy-now-parrot-dji-hubsan-and-

more. [Último acceso: septiembre 2015].

[8] A. Zul Azfaar y D. Hazry, «Simple GUI Design for Monitoring of a Remotely Operated Quadrotor

Unmanned Aerial Vehicle,» de Signal Processing and its Applications, 2011.

[9] D. Hanafi et al., «Simple GUI Wireless Controller of Quadcopter,» International Journal of

Communications, Network and System Sciences, vol. 6, nº 1, 2013.

[10] E. Berra y J. Rodrigo Cuautle, «Interfaz Natural para el Control de Drone Mediante Kinect,» Journal de

Ciencia e Ingenier´ıa, vol. 5, nº 1, pp. 53-65, 2013.

[11] S. Govindarajan et al., «Design of Multicopter Test Bench,» International Journal of Modeling and

Optimization, vol. 3, nº 3, 2013.

[12] K. Panicker et al., «GUI Controlled Aerial Drone,» International Journal of Engineering and Technical

Research, vol. 3, 2015.

[13] J. Engel, J. Sturm y D. Cremers, «Accurate Figure Flying with a Quadrocopter Using Onboard Visual and

Inertial Sensing».

[14] J. Engel, «Autonomous Camera-Based Navigation of a Qadrocopter».

[15] J. Strubel, «Quadrotor tracking and pose estimation using a dynamic vision sensor».

[16] I. F. Mondragón et al., «3D pose estimation based on planar object tracking for UAV control,» de IEEE

International Conference on Robotics and Automation, Anchorage, Alaska, USA, 2010.

Bibliografía

56

56

[17] B. Grelsson, «Global Pose Estimation froma Aerial Images,» 2014.

[18] N. Dijkshoorn, «Simultaneous localization and mapping with the AR.Drone,» 2012.

[19] L. X. Dexin Xu, «Modeling and Trajectory Tracking Control of a Quad-rotor UAV,» de International

Conference on Computer Applications and System Modeling, 2013.

[20] S. Estellés Martínez y M. Tomás Rodríguez, «Seguimiento de trayectorias tridimensionales de un

quadrotor mediante control PVA,» Revista Iberoamericana de Automática e Informática Industrial, vol.

11, pp. 54-67, 2015.

[21] L. Vago Santana, «A trajectory trackin and 3D positioning controller for the AR.Drone quadrotor,» de

International Conference on Unmanned Aircraft Systems, Orlando, FL, 2014.

[22] J. Pomares et al., «Seguimiento de Trayectorias 3D mediante Control Visual basado en Imagen».

[23] R. M. Criado, «Diseño de estrategias de control para el seguimiento de trayectorias de un cuadricóptero

comercial,» 2014.

[24] A. A. C. d. l. Santos, «Control difuso del quadrotor AR.Drone 2.0 para el seguimiento autónomo de

trayectorias,» 2015.

[25] España, «Ley 18/2014,» BOE, nº 252, pp. 83976-83982, 15 octubre 2014.

[26] AESA, «¿Qué puedo hacer con mi dron?,» [En línea]. Available:

http://www.seguridadaerea.gob.es/media/4427085/recomendaciones_uso_drones.pdf. [Último acceso:

agosto 2015].

[27] «El uso de drones en un entorno estrictamente personal es lícito,» Público, 26 junio 2015.

[28] Parrot, «AR.Drone 2.0,» [En línea]. Available: http://ardrone2.parrot.com/. [Último acceso: marzo 2015].

[29] G. Alsina, «Alexistechblog,» 15 mayo 2014. [En línea]. Available:

http://alexistechblog.com/2014/05/15/probamos-el-parrot-ar-drone-2-0/. [Último acceso: semptiebre

2015].

[30] C. Anderson, «Parrot AR.Drones specs,» [En línea]. Available:

http://diydrones.com/profiles/blogs/parrot-ardrones-specs-arm9. [Último acceso: marzo 2015].

[31] P. UAV, «AR Drone 2.0,» [En línea]. Available: http://wiki.paparazziuav.org/wiki/AR_Drone_2. [Último

acceso: septiembre 2015].

[32] J. Hansen et al., «The use of gaze to control drones,» ETRA, nº New York, pp. 27-34, 2014.

[33] P.-J. Bristeau et al., «The Navigation and Control technology inside the AR.Drone micro UAV,» de IFAC

World Congress, Milán, 2011.

[34] K. Zhang y J. Mosterman, «Drone ARDrone_Matlab_V1,» [En línea]. Available:

http://www.mathworks.com/matlabcentral/fileexchange/43816-ar-drone-ardrone-matlab-v1.

[35] D. Orlando Barragán Guerrero, «Manual de Interfaz Gráfica de Usuario en Matlab,» 2008.

57 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

[36] A. Sandler, «How to program AR.Drone remotely over Wi-Fi,» [En línea]. Available:

http://www.robotappstore.com/Knowledge-Base/How-to-Program-ARDrone-Remotely-Over-

WIFI/96.html.

[37] S. Piskorski, AR.Drone Developer Guide, 2012.

[38] Y. Altman, «Explicit multi-threading in Matlab,» febrero 2014. [En línea]. Available:

http://undocumentedmatlab.com/blog/explicit-multi-threading-in-matlab-part3.

[39] D. D. Wartner, «Introduction to Parallel Matlab,» 31 mayo 2014. [En línea]. Available:

http://shodor.org/media/content//petascale/materials/Tools/Parallel_MatLab/Parallel_MatLab_Demo.pdf.

[40] FFmpeg, «ffmpeg Documentation,» [En línea]. Available: https://www.ffmpeg.org/ffmpeg.html.

[41] J. Castellanos et al., «Robocentric map joining: Improving the consistency,» Robotics and Autonomous

Systems, vol. 55, nº 1, pp. 21-29, 2007.

[42] J. Civera, «1-Point RANSAC for EKF Filtering. Application to Real-Time Structure from Motion and

Visual Odometry».

[43] J. Tursa, «MTIMESX - Fast Matrix Multiply with Multi-Dimensional Support,» 2009. [En línea].

Available: http://www.mathworks.com/matlabcentral/fileexchange/25977-mtimesx-fast-matrix-multiply-

with-multi-dimensional-support.

Bibliografía

58

58

59 Diseño de interfaces gráficas y de algoritmos de localización de un quadrotor

Lista de Abreviaturas y Acrónimos

ACK: Acknowledgement 20

AESA: Agencia Estatal de Seguridad Aérea 6

API: Application Programming Interface 13

AT Command: Attention Command 18

DoF: Degrees of Freedom 4

EKF: Extended Kalman Filter 30

GPC: Generalized Predictive Contro 5

GPS : Global Positioning System 2

GPU: Graphics Processing Unit 19

GUI: Graphical User Interface 4

MTOM: Maximum Takeoff Mass 6

PCT: Parallel Computing Toolbox 19

PID: proportional-integral-derivative 4

PTAM: Parallel Tracking and Mapping 4

PVA: posición-velocidad-aceleración 5

RANSAC: Random sample consensus 30

ROS: Robot Operating System 29

RPA: Remotely Piloted Aircraft 5

SDK: Software Development Kit 13

SLAM: Simultaneous Localization and Mapping 4

TCP: Transmission Control Protocol 18

UAV: Unmaned Aerial Vehicle 1

UDP: User Datagram Protocol 18