Detección e identificación de formas utilizando imágenes...

a

Equation Chapter 1 Section 1

Trabajo Fin de Grado en Ingeniería de las

Tecnologías Industriales

Detección e identificación de formas utilizando

imágenes tomadas de un UAV

Dep. Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Autor: Alejandro Ernesto Gómez Tamm

Tutor: Begoña C. Arrue Ulles

Sevilla, 2017

c

c

Detección e identificación de formas utilizando imágenes tomadas de un UAV

Trabajo Fin de Grado

en Ingeniería de las Tecnologías Industriales

Detección e identificación de formas utilizando

imágenes tomadas de un UAV

Autor:

Alejandro Ernesto Gómez Tamm

Tutor:

Begoña C. Arrue Ulles

Dep. Ingeniería de Sistemas y Automática

Escuela Técnica Superior de Ingeniería Universidad de Sevilla

Sevilla, 2017

e

e


Trabajo Fin de Grado: Detección e identificación de formas utilizando imágenes tomadas de un UAV

Autor: Alejandro Ernesto Gómez Tamm

Tutor: Begoña C. Arrue Ulles

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

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

El Secretario del Tribunal

g

g


A mi familia, por ser ese apoyo

en los momentos más negros

A mis maestros, por enseñarme

a superarme

A mis amigos, pasados y

presentes, por hacerme ser quien

soy

i

i


Agradecimientos

Es difícil llegados a este punto no olvidarse de ninguna de las personas que han hecho que hoy pueda estar

redactando estas breves líneas, me gustaría agradecer a todos los que han conformado mi vida hasta hoy, ya

que con buenas o malas experiencias me han hecho ser quien soy.

Gracias a mi madre Edeltraud por enseñarme que la bondad todavía existe en este mundo, por ser un apoyo

inquebrantable y ser una mujer inteligente y admirable. Gracias a mi padre Ernesto por motivarme para querer

saber siempre más, por ser una fuente de información y conocimiento inagotable y por ser una persona que

quiere a su familia como el único tesoro verdadero e inculcarme sus valores. Por último, dar las gracias a mi

hermano Ernesto por ser lo que un hermano debe ser, un amigo que va mucho más allá de esa palabra, que te

conoce como ni tú mismo y que jamás podría traicionarte, su talento y constancia le harán llegar tan lejos

como quiera.

Agradecer también a todos mis amigos tanto de dentro como de fuera de la escuela, tanto los que siguen a mi

lado como los que se fueron, ya que todos me han hecho evolucionar como persona y ser mejor. Especial

mención a Javier García Rubiales, por ser mi compañero de batallas durante todos estos años en la escuela,

luchando codo con codo por el objetivo de convertirnos en ingenieros.

Para terminar, agradecer a todos mis profesores, que me han ayudado a ampliar mis horizontes y desarrollar mi

intelecto, tanto buenos como malos todos tienen una lección que enseñar al alumno, sea cual sea. En especial

quiero agradecer a Begoña Arrue Ulles por darme la idea para este trabajo, por aconsejarme y por el trato

increíble que siempre me ha profesado cuando he acudido en busca de consejo y ayuda.

Alejandro Ernesto Gómez Tamm

Alumno de la Escuela Técnica Superior de Ingeniería de Sevilla

Sevilla, 2017

iii

iii


Resumen

La utilización de UAS o RPAS para todo tipo de aplicaciones es un hecho cada vez más corriente en nuestra

sociedad. Sin embargo, a día de hoy, la regulación impide que este sector progrese a la velocidad que la

tecnología podría permitírselo. Pese a esto cada vez está más claro que el futuro de estos sistemas está

asegurado y son muchos los que intentan encontrar aplicaciones que en un futuro podrían ser de uso cotidiano.

Este trabajo plantea la utilización de un quadrotor con una cámara integrada para el reconocimiento de formas

a través de las imágenes captadas. La idea tras esto es que una vez reconocido el patrón buscado el quadrotor

realice un análisis de la posición del objeto, lo marque en la pantalla y aproxime su distancia. Este concepto

puede tener múltiples aplicaciones en distintos ámbitos si utilizamos como objetivo la detección de un ser

humano, por ejemplo.

En este proyecto se realizará una simulación en ROS/GAZEBO para la detección de formas simples como

esferas o cubos, lo cual es fácilmente extrapolable a la detección de cualquier otro elemento modificando el

algoritmo de análisis y procesamiento de imágenes. Se utilizará OpenCV para analizar las imágenes y RViz

para la simulación de los sensores necesarios. Con estas herramientas seremos capaces de simular un entorno

real con sus restricciones y mostrar la potencialidad de los UAV en este ámbito para demostrar que ya son

funcionales a día de hoy.

v

v


Abstract

The use of UAS and RPAS for a lot of applications is a fact that we can currently see in our society. But,

nowadays the regulation does not permit the growing up of the sector at the speed that the technology could let

them. Despite this, the future of this systems is guaranteed and they are a lot of people that look for

applications that would be of everyday use in the future.

This project proposes the use of a quadrotor with a camera as a payload for form recognition using the images

filmed by the camera. The idea behind it is that after recognising the pattern searched for, the quadrotor will do

an analysis of the position of the object, marking it in the video and approaching his distance. This concept can

have multiple applications in different areas, if we use a human as goal to be detected.

In this project ROS and Gazebo will be used for detecting simple forms like spheres and cubes. This can be

easily extrapolated to the detection of any other element, modifying the algorithm of image analysis and

processing. OpenCV will be used for analysing the images and RViz for simulating the necessary sensors.

With these tools, we will be able to simulate a real environment without restrictions and show the potential of

the UAV in this ambit, so that it can be see that his functionality is a reality today.

vii

vii


Índice

Agradecimientos i

Resumen iii

Abstract v

Índice vii

Índice de Figuras y Tablas ix

1 Introducción 1 1.1. Motivación y objetivo 1 1.1. Estructura del trabajo 1

2 Estado del arte 3 2.1. Orígenes 3

2.1.1. Introducción 4 2.1.2. Desarrollo posterior hasta la actualidad 6

2.2. Situación actual de los UAS 7 2.2.1. Legislación 7 2.2.2. Ámbito militar 7

2.3. Aclaración de términos 8 2.4. Tipos de RPAS y elección 8

2.4.1. Tipos de RPAS considerados 9 2.4.2. Elección del multirotor 10 2.4.3. Quadcopter u quadrotor 10

2.5. Visión, tipos de sensores 11 2.5.1. Ultrasónicos 11 2.5.2. Sensores visuales 11 2.5.3. Sensores láser y lidar 12

3 Software 13 3.1. ROS 13

3.1.1. Ventajas de ROS 14 3.1.2. Tipos de conceptos y elementos principales 14 3.1.3. Conclusión 15

3.2. RViz 16 3.3. Gazebo 17 3.4. OpenCV 18

4 Métodos implementados 19 4.1. Elección del UAS 19 4.2. Control del UAS 20 4.3. Entorno de simulación 21 4.4. Análisis de imagen 22

4.4.1. Algoritmo de Canny 22 4.4.2. Transformada de Hough 23

5 Resultados 25

viii

5.1. Primeros Pasos 25 5.2. Vuelo del quadrotor 26

5.2.1. cmd_vel 27 5.2.2. Nodo flying 28 5.2.3. Control manual 28

5.3. Análisis de imagen 29 5.2.1. Rqt_image_view 29 5.2.2. Cálculo de distancia 29

5.4. Entorno 29 5.5. Pruebas 30

5.5.1. Pruebas de vuelo 30 5.5.2. Detección de círculos 32 5.5.3. Detección de lineas 32 5.5.4. Detección simutanea 34

6 Conclusiones y trabajo futuro 35 6.1. Posibles mejoras 35

6.1.1. GPS 35 6.1.2. Detección de formas complejas 36 6.1.3. Evitación de obstáculos y seguimiento de objetivos 37

6.2. Aplicaciones 37 6.2.1. Tareas de grabación 37 6.2.2. Labores de vigilancia y patrulla 38

6.2. Reflexión final 39

Referencias 39

Glosario 43

ix

ix


ÍNDICE DE FIGURAS Y TABLAS

Figura 2-1. Tornillo aéreo (precursor del helicóptero) 3

Figura 2-2. Flyer I 4

Figura 2-3 Kettering Bug, considerado el primer UAV 4

Figura 2-4 Wernher von Braun 5

Figura 2-5 Misil V2 despegando 5

Figura 2-6 Falconer 6

Figura 2-7 Ryan 147 en vuelo, primer UAV a reacción 6

Figura 2-8 Pioneer, desarrollado en los 80, UAV moderno 6

Figura 2-9 Global Hawk 7

Figura 2-10. Logotipo de EASA 8

Figura 2-11. Phantom 2, ejemplo de quadrotor comercial 9

Tabla 2-1. Configuraciones típicas de multirotores 10

Figura 2-12. Sentido de giro de las helices de un quadrotor 10

Figura 2-13. Sensor ultrasónico HC-SR04 11

Figura 2-14. Cámara monocular 12

Figura 2-15. Cámara ZED, tipo de cámara estéreo 12

Figura 2-16. Kinetic, ejemplo de cámara RGB-D 12

Figura 2-17. Velodyne, ejemplo de sensor lidar 12

Figura 3-1. Logotipo de ROS 13

Figura 3-2. ROS Kinetic 14

Figura 3-3. Estructura de funcionamiento de ROS 15

Figura 3-4. Diagrama de elementos que interactúan con ROS 16

Figura 3-5. Logotipo de RViz 16

Figura 3-6. Ejemplo de simulación en RViz 16

Figura 3-7. Logotipo de Gazebo 17

Figura 3-8. Ejemplo de simulación con Gazebo 17

Figura 3-9. Logotipo de OpenCV 18

Figura 4-1. Simulación en Gazebo del hector quadrotor 19

Figura 4-2. Numerosos quadrotors simulados en gazebo en un entorno prediseñado. 20

Figura 4-3. Interfáz del Mission Planner, mostrando un recorrido por Waypoints en un entorno real. 21

Figura 4-4. Ejemplo de entorno predeterminado, con montañas. 21

Figura 4-5. Ejemplo de un filtro gaussiano de orden 5. 22

Figura 4-6. Cálculo del gradiente de borde y dirección. 22

Figura 4-7. Tres curvas de diferentes puntos intersectando, forman parte de una sola linea. 23

x

Figura 5-1. Workspace del proyecto. 25

Figura 5-2. Primer ensayo de hector_quadrotor. 26

Figura 5-3. Ejemplo de terminales utilizados simultáneamente. 26

Figura 5-4. Quadrotor despegando ante una orden dada. 27

Figura 5-5. Quadrotor realizando un vuelo circular utiliazando el nodo flying para esto. 28

Figura 5-6. Entorno en Gazebo con cielo con nubes y objetos y suelo de distintos colores. 29

Figura 5-7. Detección de objetos con errores no deseados. 30

Figura 5-8. UAV volando autónomamente en Gazebo. 31

Figura 5-9. Vuelo autónomo en RViz. 31

Figura 5-10. Detección de una esfera. 32

Figura 5-11. Detección de cubo frontalmente. 33

Figura 5-11. Cubo detectado tras aproximación oblicua. 33

Figura 5-12. Detección de dos figuras simultáneamente. 34

Figura 6-1 Vuelo en Mission Planner en un entorno real con GPS 35

Figura 6-2. Reconocimiento facial con cascade clasiffier. 36

Figura 6-3. Aplicación del find_object_2D. 37

Figura 6-4. Ejemplo de filmación de un coche. 38

Figura 6-5. Drone persiguiendo a un ciclista, posible seguimiento e identificación. 38

xi

xi


1

1


1 INTRODUCCIÓN

a invención de los vehículos aéreos planteó, al poco tiempo, la eliminación del componente humano

dado que se trata del principal causante de fallos en el sistema. Una vez planteada esta idea el

surgimiento de soluciones para el problema fue progresivo pero incesante hasta nuestros días. Una vez

creados, el siguiente paso natural es la búsqueda de aplicaciones específicas para ellos, lo cual nos lleva al

objetivo de este trabajo.

1.1 Motivación y objetivo

El presente trabajo parte de la necesidad de desarrollar aplicaciones en el presente para un uso futuro cuando el

entorno sociopolítico permita una correcta integración de los UAS en nuestras vidas en todo su potencial.

El objetivo será, en primer lugar, realizar un análisis exhaustivo de los beneficios de las RPAS frente a otras

soluciones para una aplicación concreta, como es el reconocimiento de formas utilizando una cámara

embarcada y un posterior análisis de imagen y aproximación de la distancia al objetivo. Una vez analizado el

hecho de porqué elegir un UAV frente a otras posibles soluciones, tanto autónomas como operadas por

personas, se dispondrá de la base para describir el resto de elementos utilizados en este trabajo.

A continuación, se describirán los elementos de simulación utilizados como son ROS, Gazebo, RViz y

OpenCV que son programas ampliamente conocidos en el sector de la robótica dada sus casi infinitas

posibilidades.

Más adelante se estudiará la simulación realizada, que consistirá en el vuelo de un quadrotor autónomo con

una cámara embarcada como carga de pago que le permitirá detectar los elementos que se le ordene y procesar

las imágenes para obtener la información deseada.

Por último, se discutirá en las conclusiones tanto el posible potencial futuro de esta aplicación, como las

mejoras implementables para hacerlo un sistema más útil para una labor real en campo.

1.2 Estructura del trabajo

El trabajo estará dividido en 6 capítulos bien diferenciados que desarrollarán los temas anteriormente

planteados.

En primer lugar, estará la introducción, donde se darán unas breves pinceladas del objetivo y la razón de ser

del trabajo como de la estructura del mismo.

En segundo lugar, se encontrará el estado del arte que describirá tanto la historia y el desarrollo de los UAS

hasta nuestros días, como la descripción de los elementos de la robótica móvil y la programación que se utiliza

y que permiten entender el avance del desarrollo actual de las tecnologías en este campo.

En tercer lugar, se hablará de los programas utilizados para la simulación, que serán ROS, Gazebo, RViz y

OpenCV, ahondando en su origen, sus ventajas frente a otras posibles opciones y la calidad y utilidad que

ofrecen para realizar un proyecto de este tipo.

L

Caminante no hay camino, se hace camino al andar.

- Antonio Machado -

Introducción

2

2

En cuarto lugar, se tratarán los métodos implementados para desarrollar los experimentos, tratando todos los

paquetes y funciones utilizadas para poder llevarlos a cabo, tanto los adaptados a partir de módulos ya

existentes como los desarrollados desde cero.

En quinto lugar, se describirá el experimento realizado con las dificultades aparecidas y las soluciones

adoptadas realizando un análisis exhaustivo de los resultados. Se hará hincapié en las posibilidades reales que

estos sistemas combinados de cámara y UAV pueden ofrecer en la práctica utilizando el modelo como

referencia visual para el lector.

Por último, se expondrán las conclusiones extraídas de este trabajo y las posibles ampliaciones de este tanto

para su mejora como para la extensión de su campo de aplicación. Se analizará tanto la combinación con otros

elementos para conseguir un sistema más robusto como su integración en proyectos de mayor envergadura

como elemento auxiliar para realizar distintas acciones autónomas.

3

3


2 ESTADO DEL ARTE

No saber lo que ha sucedido antes de nosotros es como ser incesantemente niños.

- Cicerón -

a historia de los UAS es inherente a la de los vehículos aéreos convencionales y a la evolución de la

robótica, la electrónica y la programación. Afirmar categóricamente cual fue el primer sistema aéreo no

tripulado que pueda considerarse como tal es una tarea ardua nunca exenta de controversia y no se

encuentra entre los objetivos de este trabajo. Pese a esto es necesario recorrer de alguna manera la historia de

estos aparatos destacando los mayores hitos conseguidos hasta nuestros días. Esto dará pie a poder tratar sobre

los quadrotors como el utilizado en este trabajo, profundizando en sus ventajas e inconvenientes y en el porqué

de su elección.

Una vez tratados tanto los elementos históricos como técnicos de los RPAS se tratará la situación legal pasada,

actual y futura para terminar de entender la evolución de estos sistemas y todas las dificultades a las que se

enfrentan para convertirse en una herramienta habitual en nuestra sociedad.

2.1 Orígenes

Situar en un punto exacto al primer UAS es, como dicho anteriormente, algo que no tiene una respuesta única

dada la diferente interpretación que cada persona puede tener del término. Sin embargo, se puede afirmar que

ya en la antigua Grecia y la China clásica hace 2500 años se crearon distintos objetos cuyo fin era el vuelo

autónomo no tripulado, máquinas rudimentarias con un objetivo probablemente lúdico que podrían

considerarse los más lejanos antecesores de los sistemas modernos. Junto a esto se tienen también las

investigaciones llevadas a cabo por distintos estudiosos de la época como el genio Leonardo da Vinci que

realizó múltiples estudios sobre objetos voladores. [1]

Figura 2-1. Tornillo aéreo (precursor del helicóptero)

L

Estado del arte

4

4

2.1.1 Introducción

Tratando el trabajo sobre vehículos aéreos no puedo evitar hacer una mención, aunque sea breve, al primer

vuelo tripulado de la historia llevado a cabo por los hermanos Wright el 17 de diciembre de 1903 en Kitty

Hawk (Carolina del norte, USA) con el Flyer I. Este hito demostró que el ser humano era capaz de crear

máquinas capaces de volar y ser controladas y sentó las bases de todos los desarrollos posteriores hasta la

actualidad. [2]

Figura 2-2. Flyer I

Aunque hasta este momento se ha tratado de referirse a los sistemas aéreos no tripulados con términos más

técnicos y correctos, el más extendido es el de drone. Palabra proveniente del inglés que significa literalmente

zángano o hace referencia al zumbido que este emite. [3]

En un primer momento este término hacía referencia a vehículos similares a aviones en miniatura de uso

militar que eran utilizados para entrenar a artilleros antiaéreos utilizándolos como objetivos móviles. El sonido

que emitían al volar podría ser el origen etimológico del término.

Es momento ahora de hablar de las evoluciones más importantes en este campo. Por desgracia, una de las

mayores causas de desarrollo tecnológico, a todos los niveles son los conflictos bélicos, y en el caso de los

UAS no es diferente.

Durante la primera guerra mundial se crea el que para muchos es el primer UAV moderno, el Kettering Bug,

cuyo objetivo era servir de torpedo aéreo para las fuerzas armadas. [4]

Figura 2-3 Kettering Bug, considerado el primer UAV

5

5


Tras este primer conflicto a escala mundial no pasaron muchos años antes de que estallase el mayor conflicto

bélico de la historia. El 1 de septiembre de 1939 comienza la segunda guerra mundial con la invasión de

Polonia por parte de la Alemania nazi. Los alemanes se embarcan en una infinidad de proyectos militares para

demostrar su supremacía y uno de sus científicos destaca entre la mayoría. Wernher von Braun con su

proyecto de misiles balísticos V1 y V2 crea los primeros misiles de largo alcance que actúan de forma

autónoma tras el lanzamiento y que pueden considerarse UAV superiores a lo visto hasta el momento. [5]

Figura 2-4 Wernher von Braun

Figura 2-5 Misil V2 despegando

Tras el fin de la segunda guerra mundial, von Braun fue reclutado por USA a través de la operación paperclip

y fue uno de los máximos responsables de los éxitos del programa espacial de la NASA. [6]

Estado del arte

6

6

2.1.2 Desarrollo posterior hasta la actualidad

Tras la finalización de este último conflicto el desarrollo, de UAS continuó gracias a los continuos avances

tecnológicos. En los años 50, ya pueden encontrarse algunos sistemas de ala fija con cámaras integradas y una

autonomía de unos 30 minutos.

Figura 2-6 Falconer

En los años 60 y 70, países como USA o la URSS, embarcados en la conocida como guerra fría [7],

desarrollan sistemas más sofisticados para labores de reconocimiento, cuyo huso pronto se expande a otros

países tales como Canadá, Alemania o Israel.

Figura 2-7 Ryan 147 en vuelo, primer UAV a reacción

Es este último país uno de los considerados pioneros en la tecnología de vehículos aéreos no tripulados y uno

de los principales actores en el desarrollo de los primeros UAS modernos en la década de los 80, que ya no

solo se utilizan en tareas de reconocimiento sino también para abatir objetivos. Es en estas fechas donde

podemos situarnos ya en la actualidad y ver como se están desarrollando estas tecnologías en nuestros días. [8]

Figura 2-8 Pioneer, desarrollado en los 80, UAV moderno

7

7


2.2 Situación actual de los UAS

El desarrollo de los sistemas aéreos no tripulados ha experimentado tal avance que su campo de aplicación ya

no se encuentra únicamente en el ámbito militar si no que ha dado el salto al civil.

Tanto es así que, en la actualidad, se aprecia que una gran parte de la sociedad conoce la existencia de estos

aparatos por su uso lúdico o de entretenimiento. El término también ha ampliado su significado dado los

nuevos sistemas aéreos que han aparecido y que ofrecen diferentes ventajas e inconvenientes respecto al

clásico ala fija. Los principales son los multirotores, donde se incluye el quadrotor que usaremos en este

trabajo, pero también existen dirigibles y helicópteros autónomos o sistemas híbridos.

2.2.1 Legislación

No está de más habiendose llegado a este punto hacer una breve mención al estado actual de la legislación [9]

donde el marco regulador es a día de hoy muy restrictivo sobre estos aparatos en el ámbito civil. Esto ha

ocasionado que actualmente la tecnología esté mucho más avanzada que la legislación. Con esto quiero decir

que los RPAS son a día de hoy capaces de realizar acciones muy avanzadas y con mucho potencial práctico,

pero la legislación no permite que esto pueda llevarse a cabo al ser demasiado restrictiva.

Algunos ejemplos de estas restricciones son no permitir que el sistema se aleje de la línea de vista del piloto en

tierra o prohibir que vuele en ciertos lugares restringidos como ciudades. Esta legislación tan prohibitiva se

debe principalmente al desconocimiento por parte de la sociedad de esta nueva tecnología, por lo que se tiende

a restringir su uso dada la existencia del miedo a su posible peligrosidad. El piloto en tierra asume la

responsabilidad legal ante cualquier incidente ocurrido, aunque se trate de un vuelo autónomo.

Pese a esto el reino de España se encuentra tramitando una reforma de la legislación para permitir un mayor

uso de estos aparatos y crear un marco regulatorio lógico. También la UE tiene como objetivo marcado la

creación de una legislación europea sobre estos dispositivos, que según parece serían catalogados en función

del peligro que suponen dadas sus especificaciones y la labor que desempeñen.

Pese a los esfuerzos de las fuerzas gubernamentales, estas nuevas leyes llegarán tarde para muchas empresas

surgidas por la moda de los “drones”. Pese a la lentitud, los expertos tienen esperanzas en que una vez que la

regulación alcance su madurez, el sector entre en auge y se asiente convirtiéndose en una realidad palpable y

con un gran peso económico.

2.2.2 Ámbito militar

Por hacer una breve mención al ámbito militar del que tanto se ha hablado con anterioridad los UAS se

encuentran totalmente asentados en este sector donde la legislación es muchísimo menos restrictiva y son una

herramienta más de uso cotidiano entre las fuerzas armadas más poderosas del mundo. Es aquí además donde

podemos encontrar el UAS más grande del mundo, el global hawk, perteneciente al ejército de USA. Este

aparato es capaz de recorrer distancias elevadas en tareas de reconocimiento y adquisición de información y

trabajar de forma autónoma siguiendo unas directrices desde la GCS.

Figura 2-9 Global Hawk

Estado del arte

8

8

2.3 Aclaración de los términos

Llegados a este punto, me parece adecuado llevar a cabo una aclaración de los términos utilizados en este

trabajo para referirme a los sistemas aéreos no tripulados, ya que existen pequeñas diferencias entre ellos pese

a que en este trabajo prácticamente serán utilizados indistintamente dado su similitud de significado. Esto

ayudará a un lector no familiarizado con este sector a entender mejor cada término, su origen y el porqué de su

uso. [10]

- UAV: Son las siglas de “unmanned aereal vehicle” o vehículo aéreo no tripulado y tiene su origen en

el ámbito militar donde se desarrollaron por primera vez estas máquinas. Es el término favorito por los

expertos junto con el siguiente, pero el término “unmanned” crea cierta desconfianza entre el público

general y en particular los políticos, por interpretarse como una IA independiente capaz de tomar sus

propias decisiones sin una supervisión humana. Como hemos mencionado en el apartado anterior la

existencia de un piloto en tierra es obligatoria dado que un ser humano debe asumir la responsabilidad

ante incidentes que pueda ocasionar el aparato.

- UAS: Son las siglas de “unmanned aerial system” o sistema aéreo no tripulado. Este término es más

amplio que el anterior al incluir no solo al vehículo, sino también a la GCS o estación en tierra, el

piloto en tierra, la carga de pago y cualquier otra cosa que requiera el aparato para llevar a cabo su

misión. Es un término muy utilizado, dado que es más general al referirse a todo lo que conforman

este tipo de aparatos y sus misiones, y suele referirse también a sistemas militares por las mismas

razones que el término anterior.

- RPAS: Son las siglas de “Remotely piloted aereal system” o sistema aéreo pilotado remotamente.

Este concepto nace a raíz de la llegada de estos sistemas al ámbito civil, para aportar cierta seguridad

al consumidor al especificar que el sistema se encuentra pilotado por una persona humana pese a que

esta no se encuentre dentro de la aeronave. El término es de uso común hoy en día pese a que ciertos

expertos no consideran necesaria su existencia, considerándolo simplemente una cuestión de

marketing.

En el caso de la UE es EASA quien se encarga, entre otras muchas cosas, en cerciorarse del correcto uso de

estos términos.

Figura 2-10. Logotipo de EASA

2.4 Tipos de RPAS y elección

Una vez explicados tanto los orígenes de los sistemas aéreos no tripulados como habiendo expuesto de manera

general lo que los rodea hasta el día de hoy, es necesario explicar la elección de un quadrotor para el

desempeño de la misión en este trabajo frente a otras opciones posibles. Esto obliga a quese se exponga de

manera muy resumida las opciones que podrían haberse seleccionado y luego se trate de manera más amplia la

elección entrando en detalles más técnicos.

2.4.1 Tipos de RPAS considerados

Existen multitud de opciones dada la variedad de configuraciones y prototipos creados en los últimos tiempos,

pero como ese no es un objetivo de este trabajo reduciré las opciones a tres: ala fija, helicóptero y multirotor.

- Ala fija: El ala fija, que puede considerarse un avión en miniatura, ofrece los beneficios que le otorga

la sustentación [11]. Esto quiere decir que permite una mayor autonomía de vuelo frente al resto de

opciones estudiadas. El mayor problema de este es, sin embargo, la imposibilidad de efectuar un vuelo

9

9


en punto fijo. Esto lo hace poco adecuado para efectuar vuelos semiestacionarios a baja altura, donde

el principal objetivo es recorrer un entorno de forma lenta y ser capaz de detenerse si se detecta un

objeto de interés.

- Helicóptero: Aunque ofrece la capacidad de vuelo en punto fijo que no ofrecía el ala fija, sacrificando

autonomía de vuelo, presenta un problema que dificulta su uso. No es otro que el enrevesado diseño

de un helicóptero, donde las piezas mecánicas son de una gran complejidad, lo que hace más difícil su

producción y mantenimiento y, en el caso de este trabajo, hace mucho más difícil crear una

simulación operativa de este sistema.

- Multirotores: Aunque presentan la menor autonomía de vuelo, al estar formados por pequeñas hélices

colocadas formando un patrón, ofrecen la mejor maniobrabilidad de todos, el menor mantenimiento y

son los más sencillos de simular. Son por tanto la elección lógica para este TFG.

Figura 2-11. Phantom 2, ejemplo de quadrotor comercial

Estado del arte

10

10

2.4.2 Elección del multirotor

Una vez decidido que el multirotor es la elección adecuada toca decidir entre sus múltiples configuraciones.

Tabla 2-1. Configuraciones típicas de multirotores

En este caso se elige el quadcóptero ya que es el más simple. Otras configuraciones podrían ofrecer mayor

potencia o mayor seguridad ante la pérdida de un motor, pero al ser la carga de pago una simple cámara y no

tener en consideración el fallo de un motor, a priori es la elección más directa.

2.4.3 Quadcóptero o quadrotor

El quadcóptero consiste en cuatro hélices colocadas de manera que dos giran en sentido horario y otras dos en

sentido antihorario, todas ellas colocadas verticalmente. De esta manera, es capaz de estabilizarse en vuelo

variando el empuje de estas. Al ser mecánicamente simple, permite que sea sencillo de automatizar y de

fabricar [12]. Su gran maniobrabilidad lo hace excelente tanto para vuelos en exterior como en interior.

Figura 2-12. Sentido de giro de las hélices de un quadrotor

11

11


2.5 Visión, tipos de sensores

Por último, es adecuado tratar el otro gran bloque en el que se basa el TFG, que no es otro que la visión. La

obtención de las imágenes como su posterior análisis y procesado constituyen una parte muy importante de

este trabajo, cuyo objetivo es implantar esas capacidades a un UAS para utilizar sus características para una

obtención de imágenes óptima e inalcanzable de otra manera. En este trabajo se utilizará una cámara de video

estándar que se simulará embarcada con el quadcóptero, pero existen muchos otros sensores utilizado hoy en

día para interactuar con el medio, cabe ahora mencionar algunos de ellos.

2.5.1 Ultrasónicos

Los sensores ultrasónicos suelen ser los sensores de menor precio empleados en la detección espacial y son

compatibles con la mayoría de superficies siempre y cuando estas tengan reflectividad acústica. Sin embargo,

su baja resolución, de rango y de velocidad de respuesta hacen que sean inadecuados para tareas que requieran

una mayor precisión. También, las múltiples interferencias que pueden recibir los hace problemáticos para

ciertas aplicaciones, quedando relegados a sistemas simples o submarinos (sonar) donde la distorsión es menor

que en otros sistemas dada su baja frecuencia.

Su funcionamiento consiste en lanzar una onda ultrasónica en una dirección y esperar que rebote contra el

objetivo y regrese para estimar la distancia. Dado que la velocidad del sonido es conocida en la atmósfera

terrestre, a 20 grados Celsius, 50% de humedad y nivel del mar, y constante con valor de 343,2 metros por

segundo si el sensor cronometra el intervalo de tiempo desde que la onda sale hasta que regresa, puede calcular

la distancia al objetivo con el que ha rebotado.

Figura 2-13. Sensor ultrasónico HC-SR04

2.5.2 Sensores visuales

Los sensores visuales son dispositivos ampliamente utilizados en la robótica y han experimentado un gran

avance en los últimos tiempos desarrollando múltiples tecnologías que son de uso frecuente en multitud de

campos. En primer lugar, tenemos las cámaras, que son dispositivos de sobra conocidos para cualquier persona

dado su uso lúdico. También han aparecido en los últimos tiempos los sensores RGB-D que combinan

cámaras y sensores infrarrojos para cubrir distintas aplicaciones.

Las cámaras son dispositivos ampliamente utilizados en la obtención de datos del entorno. Sus ventajas

principales son su bajo precio, la cantidad de información que ofrecen y la cantidad de documentación

referente a ellas dado que son dispositivos utilizados durante muchos años por numerosos investigadores.

Existen cámaras llamadas monoculares, que consisten en una sola cámara y estéreo que constan de un número

mayor de cámaras alineadas de distinta manera. Estas, del mismo modo que los ojos humanos, permiten captar

la profundidad y por tanto aportar una mayor información del entorno.

Para ser capaces de calcular distancias con las cámaras monoculares es necesario disponer de una información

previa de los objetos captados para, en función de su tamaño en la imagen, calcular su posición respecto a la

cámara.

Los sensores RGB-D combinan información RGB, de una cámara, con información de profundidad, para lo

último se valen de sensores infrarrojos con un conjunto emisor-receptor. El emisor emite un patrón de luz

infrarroja que luego es captado por el receptor. A partir de esto, conociendo la velocidad de la luz de

aproximadamente 3*10^8 metros por segundo, se obtiene la imagen en profundidad que se sincroniza con la

imagen RGB captada por la cámara. Esto nos permite crear una imagen tridimensional del entorno.

Pese a su gran utilidad en interiores, el sensor infrarrojo es sensible a la luz solar y por tanto esta tecnología no

es aplicable en exteriores, quedando limitada a su uso en lugares cerrados.

Estado del arte

12

12

Figura 2-14. Cámara monocular Figura 2-15. Cámara ZED, tipo de cámara estéreo

Figura 2-16. Kinetic, ejemplo de cámara RGB-D

2.5.3 Sensores láser y lidar

Estos sensores tienen hoy en día un uso muy elevado dada las grandes prestaciones que ofrecen debido a su

precisión sobre todo en interiores, dado que en exteriores la radiación solar impide un uso adecuado de estos.

Abarcan desde los simples sensores de rango que miden distancias en una única dirección, hasta sensores que

captan información 3D precisa en una gran área de trabajo. Algunas de sus ventajas son la buena resolución en

ángulo y distancia y su elevada tasa de muestreo.

Los lidar (light detection and ranging), ofrecen la capacidad de obtener nubes de puntos del entorno con una

gran precisión y menor carga de datos que las cámaras, por lo que su velocidad de procesamiento es mayor.

Su principio de funcionamiento consiste en calcular el tiempo en el que el haz de luz tarda en regresar al sensor

tras ser disparado en una dirección, con ello se estima el objeto más cercano en esa trayectoria. Es la

tecnología mencionada anteriormente para los ultrasonidos y las cámaras RGB-D, pero con otra tipología de

onda.

Es por esto que para vuelo en interior o SLAM son sensores muy utilizados hoy en día, aunque el peso

también es un factor clave en este ámbito. Aunque la tecnología ha avanzado mucho en este ámbito, todavía

este tipo de sensores presentan un peso elevado respecto al resto, por lo que pocos sensores cumplen los

requerimientos necesarios para poder utilizarse en UAS.

Figura 2-17. Velodyne, ejemplo de sensor lidar

13

13 Detección e identificación de formas utilizando imágenes tomadas de un UAV

3 SOFTWARE

na vez realizado el análisis inicial del trabajo, es oportuno centrarse en los programas utilizados para

llevarlo a cabo. Este proyecto somete a estudio una posible aplicación futura de los UAS y para ello se

vale de simulaciones realizadas por ordenador para probar las hipótesis y llegar a una conclusión sobre

su viabilidad, sus mejoras implementables y su potencial futuro.

Es por esto que la exposición del software utilizado es crítica para entender el desarrollo de los experimentos y

es este el objetivo de este tema.

3.1 ROS

El término ROS [13] corresponde a las siglas de “robot operating system” y se trata de una plataforma

software o framework que ofrece todo tipo de herramientas y librerías para aplicaciones de robótica. Su

verdadero valor es, que al tratarse de un programa de código abierto, pone a disposición del usuario una

cantidad ingente de código fácilmente reutilizable e implementable. Es esta la idea que impulsa su creación, el

poder ofrecer un sistema gratuito para programación robótica.

Una de las mayores ventajas es que ROS dispone de paquetes que permiten el uso de aplicaciones robóticas ya

existentes y que han sido utilizadas en este trabajo, como Gazebo u OpenCV, que ampliaremos más adelante.

Un inconveniente, por otra parte, es la imposibilidad de usarse en sistemas operativos tipo Windows, ya que

solo permite su uso en plataformas tipo Unix, por lo que ha sido necesario efectuar el trabajo en Ubuntu.

A la hora de utilizarlo, ROS nos permite diseñar ejecutables de forma separada y combinarlos a la hora de

lanzarlos. Se ejecuta como una red de procesos donde todos se comportan como iguales sin clientes o

servidores fijos. También nos ofrece servicios estándares, como abstracción de hardware, comunicación a

través de mensajes y gestión de archivos, entre muchos otros. Al no tratarse de un sistema operativo pese a su

nombre, ya que debe ser instalado sobre otro sistema como es Ubuntu. Se le suele considerar un Meta-Sistema

operativo.

Figura 3-1. Logotipo de ROS

U

La ciencia de hoy es la tecnología del mañana.

- Edward Teller -

Software

14

14

3.1.1 Ventajas de ROS

La principal ventaja que ofrece ROS es la cantidad de material que pone a disposición gratuitamente para la

realización de proyectos orientados a la robótica. Se muestran algunos de las más notables ventajas. [14]

- Un conjunto de drivers que permiten la lectura de datos y el envío de órdenes a los robots, soportando

una gran cantidad de hardware.

- Una gran cantidad de algoritmos ya desarrollados que permiten multitud de acciones, como la

construcción de mapas y su interactuación con ellos o la lectura e interpretación de datos captados por

sensores. Esto es de la mayor utilidad en el presente proyecto.

- La infraestructura computacional que permite conectar varios componentes de un robot y agregarles

los algoritmos necesarios. Como también un gran conjunto de herramientas que permiten la

depuración de errores.

- Por último, cabe destacar la existencia en su página web de una gran variedad de tutoriales, una

extensa wiki dedicada únicamente a ROS y un foro activo de preguntas donde poder plantear

cuestiones. Todo esto facilita enormemente el aprendizaje y el posterior uso del sistema. [15] [16]

En este trabajo se utilizará la versión Kinetic de ROS por ser la más reciente. Pese a que algunos algoritmos y

tutoriales están algo desfasados, con la ayuda de los foros y la wiki se encuentran soluciones a los problemas

de compatibilidad entre versiones.

Figura 3-2. ROS Kinetic

3.1.2 Tipos de conceptos y elementos principales

ROS presenta un grafo de computación, que consiste en una red de comunicación punto a punto. Sus

elementos están divididos en tres niveles de conceptos. [17] [18] [19]

1. Nivel de Sistema de archivo

2. Nivel de computación gráfica

3. Nivel de la comunidad

Es necesario, para entender correctamente el sistema, explicar algunos de estos elementos en mayor

profundidad.

- Paquetes: Se trata de la unidad principal que utiliza ROS para la organización de software. Puede

contener procesos en tiempo de ejecución como también bibliotecas, datos y archivos de

configuración. Son el elemento de construcción más atómica.

- Repositorios: Es el paquete o conjunto de paquetes que comparten una misma versión y pueden ser

liberados juntos.

- Nodos: Son procesos en los que se realizan acciones tales como cálculos. Utilizan una biblioteca tipo

cliente para comunicarse con otros nodos. Estos pueden publicar o suscribirse a un tópico para utilizar

o proporcionar algún servicio. Como norma general, un sistema tiene activos muchos nodos, cada uno

de ellos con una función específica.

15


- Tópicos o Topics: Como se ha mencionado anteriormente la transferencia de datos se realiza por

medio de paso de mensajes. Los topics son un medio de comunicación entre nodos. Un tópico puede

ser publicador o suscriptor. Los nodos utilizan estos elementos para publicar la información necesaria

o suscribirse a ella en caso de que la requieran.

- Maestro o Master: El ROS Master permite que los nodos sean capaces de encontrarse unos a otros,

dicho de otra manera, permite que exista la comunicación entre nodos. Es una parte primordial del

sistema y debe estar en ejecución cuando se ejecutan los nodos. Sin él no se podrían invocar servicios.

- Parámetro servidor: Permite que los datos sean almacenados en una ubicación centralizada,

actualmente forma parte del Master.

- Mensajes: Al hablar anteriormente de comunicación entre nodos se ha mencionado que se realizan a

través de paso de mensajes. Un mensaje es una estructura de datos. ROS cuenta con una serie de

mensajes predefinidos, pero es posible crear tus propios mensajes. Estos pueden estar compuestos por

distintos tipos de datos como pueden ser enteros, flotantes, etc.

- Servicios: En ocasiones resulta necesario un modelo distinto de suscripción/publicación al de los

topics. En ese caso entran en juego los servicios que utilizan el modelo de petición y respuesta. Se

tiene entonces un servidor y un cliente, este último solicita una respuesta a partir de unos datos de

entrada.

- Bolsas o bags: Es un formato de archivo que permite volver a reproducir datos de mensajes grabados

con anterioridad. Los bags tienen gran utilidad para almacenar datos de sensores, son fundamentales

para la simulación y comprobación de algoritmos.

Figura 3-3. Estructura de funcionamiento de ROS

3.1.3 Conclusión

Como exposición final, ROS pone a disposición del usuario una infinidad de servicios con los que se hace

posible desarrollar proyectos de esta envergadura. Si no fuera por la existencia de ROS probablemente no se

podría realizar este trabajo, dado que no existe otro medio que ofrezca tanto material de manera abierta y

gratuita. Pese a que trabajar con este sistema resulte poco intuitivo al principio, su curva de aprendizaje es

claramente exponencial, premiando mucho el esfuerzo que se realiza y permitiendo realizar acciones cada vez

más complejas a medida que se aprende su funcionamiento.

Software

16

16

Figura 3-4. Diagrama de elementos que interactúan con ROS

3.2 RViz

Un de las mayores utilidades de ROS a la hora de realizar simulaciones es RViz [20]. Se trata de un simulador

3D donde es posible publicar información de sensores, algo muy útil a la hora de simular una cámara como en

el caso de este trabajo. También permite detectar nubes de puntos o información de sensores láser. Permite

además representar tridimensionalmente los robots y utiliza la librería “tf” para mostrar los datos de los

sensores en el sistema de coordenadas de referencia.

Figura 3-5. Logotipo de RViz

Aparte de lo anterior, su funcionamiento es relativamente sencillo. Utiliza topics, mencionados anteriormente.

Los datos que se quieran utilizar se suscriben a un tópico y son asignados a un display de RViz que se encarga

de publicarlos.

Figura 3-6. Ejemplo de simulación en RViz

17


En este caso se utilizará RViz para realizar la simulación de la cámara embarcada en el quadrotor, así como la

del quadrotor en si. Pese a que la simulación de los elementos se hará utilizando Gazebo, RViz es muy

importante ya que el procesamiento de imágenes es una de las piezas clave de este proyecto.

3.3 Gazebo

Gazebo [21] es un entorno de simulación 3D para múltiples aplicaciones. Permite su uso con ROS a través de

un paquete llamado gazebo_ros, que permite una comunicación bidireccional entre ROS y Gazebo.

Figura 3-7. Logotipo de Gazebo

Aparte de tratarse de un sistema gratuito, permite la simulación de todo tipo de modelos robóticos y de

escenarios o “worlds” donde desarrollar las simulaciones. Ofrece además una gran cantidad de modelos en su

librería online de libre acceso. Esto hace que no sea necesario en la mayoría de los casos realizar un modelo

desde cero, sino que puede usarse uno ya creado y modificarlos para la aplicación requerida. Las físicas están

muy bien logradas y ofrecen multitud de opciones para una simulación o absolutamente realista o más ideal.

Figura 3-8. Ejemplo de simulación con Gazebo

Software

18

18

3.4 OpenCV

OpenCV [22] es una biblioteca de visión de acceso libre desarrollada por Intel. Su uso a raíz de su salida en

1999 ha cubierto multitud de propósitos, tanto sistemas de seguridad por detección de movimiento como

aplicaciones de control de procesos donde se requiere reconocimiento de objetos. Se trata de un sistema

multiplataforma con más de 500 funciones que abarcan desde reconocimientos de objetos a calibración de

cámaras o visión robótica.

Figura 3-9. Logotipo de OpenCV

El entorno pretende ser fácil de utilizar e intuitivo, utiliza programación C++ por lo que es accesible a

cualquiera con un conocimiento básico en este lenguaje. Además, contiene una extensa wiki donde consultar

las funciones y un foro donde realizar preguntas. Esto, al igual que en ROS, es de gran ayuda a la hora de

realizar cualquier proyecto.

En este trabajo se utilizará OpenCV para el análisis de las imágenes obtenidas en la simulación, se realizará un

análisis en tiempo real de estas, buscando esferas o líneas rectas que conformen cubos y marcándolas en la

imagen de salida del programa. Para esto se creará un nodo que se suscriba al tópico de las imágenes que

publique RViz y luego se publicará otro con la imagen ya analizada.

19


4 MÉTODOS IMPLEMENTADOS

No existe ningún punto de partida si no se sabe bien a donde ir.

- Sigmund Freud-

n este capítulo se pretenden explicar las aplicaciones que se han empleado para las distintas partes de

este trabajo. Al tratarse de un trabajo basado en experimentos simulados habrá que desarrollar los

elementos tanto de ROS como de Gazebo, RViz y OpenCV que han sido utilizados, como paquetes,

funciones o archivos. Estos elementos han sido en primer lugar probados por separado y luego implementados

en conjunto, debiendo modificarlos para tal fin en primer lugar. Una vez hecho esto ha sido posible realizar las

pruebas que se explicarán en el siguiente capítulo, que son el fin último de este proyecto.

4.1 Elección del UAS

Como se ha mencionado con anterioridad, una de las mayores ventajas de ROS es la existencia de múltiples

paquetes ya existentes con los que se pueden realizar multitud de simulaciones. En este TFG se tratará el

análisis de datos obtenidos por un quadrotor en pleno vuelo, es por eso que se convierte en fundamental la

creación de un quadrotor simulado.

En este caso se ha utilizado un modelo de UAV completo creado por la Universidad Técnica de Darmstadt,

por Johannes Meyer y Stefan Kohlbrecher, llamado hector_quadrotor [23]. Este paquete permite ser instalado

en un workspace de ROS y tras esto define completamente el modelo, con sus propiedades dinámicas y

tópicos que permiten controlarlo y utilizar distintos payloads simulados tales como GPS, sensores láser para

realizar SLAM o cámaras embarcadas, que es el que utilizaremos en este caso. El UAV está especialmente

preparado para realizar simulaciones de navegación en interior de forma autónoma generando, con SLAM, el

mapa del entorno con el fin de poder posicionarse y navegar a su alrededor. También dispone de una

simulación ya preparada de vuelo en exterior, donde se puede añadir GPS para vuelos autónomos con este. El

mantenimiento constante y su adaptación a las nuevas versiones de ROS lo hacen idóneo para esta tarea y

muchas otras, aunque en ningún caso se utilicen todas las funcionalidades que ofrece de forma simultánea.

Figura 4-1. Simulación en Gazebo del hector quadrotor

Aparte de su compatibilidad con ROS, ofrece numerosos programas que permiten varias acciones que son de

utilidad. En primer lugar, es posible desplegar el UAS sobre un escenario previamente diseñado en Gazebo

bajo un archivo “.world” y ejecutar esa simulación con un “.launch”.

E

Métodos implementados

20

20

Además, al ejecutarse este drone simulado, publica varios tópicos a los que es posible suscribirse tales como

las imágenes captadas de la cámara o los comandos de velocidad para controlar el UAV. También es posible

visualizar la información de los sensores utilizando RViz.

Figura 4-2. Numerosos quadrotors simulados en gazebo en un entorno prediseñado.

4.2 Control del UAS

Para que la simulación tenga un sentido, el quadrotor debe moverse. Se abren aquí varias opciones de control

para conseguir que el quadcóptero recorra el entorno simulado.

La primera opción es un control manual, para ello se utiliza el paquete de “teleop_twist_keyboard” [24] que

permite controlar el UAV por teclado. Aunque este método ha sido el implementado para controlarlo

manualmente en este caso, el paquete de hector_quadrotor ofrece la posibilidad de controlarlo con un mando

de Xbox o de PlayStation ejecutando un archivo y conectando el mando al ordenador.

Pese a que el control manual es útil, a la hora de probar el proyecto no tiene sentido si lo que se pretende es

utilizar el UAS para labores de vigilancia y detección de objetos. Es por eso que se intenta implementar un

control autónomo que permita al sistema volar de forma controlada sin que un agente humano intervenga en

esta acción.

Como no se dispone de GPS, ni de ningún sistema de localización en tiempo real, no es posible realizar un

control por waypoints como se hace con muchos quadrotors hoy en día utilizando por ejemplo el “Mission

Planner” de libre acceso y muy útil para estas aplicaciones. Si se trabajase con un drone real en lugar de una

simulación, seguramente se habría utilizado este tipo de navegación, dada su versatilidad y sencillez una vez

controlado la interfaz del programa. Al no ser esto posible se ha optado por otras soluciones que se detallarán

en el siguiente capítulo.

21


Figura 4-3. Interfaz del Mission Planner, mostrando un recorrido por Waypoints en un entorno real.

Esta no es otra que diseñar un nodo de ROS que se suscriba el tópico “cmd_vel” del hector_quadrotor. Este

nodo al que se ha llamado “flying”, dado que es el encargado de dar las órdenes de vuelo del quadrotor. Su

trabajo consiste en enviar parámetros de velocidad lineal y angular al UAS a una frecuencia determinada.

Modificando los parámetros a lo largo de la ejecución del nodo se consigue que recorra el entorno de la

manera que se quiera. Obviamente es necesario conocer previamente el entorno para poder evitar colisiones y

recorrerlo de forma óptima.

4.3 Entorno de simulación

Los entornos de simulación se diseñan en archivos “world” que pueden ser modificados al gusto. Pese a que

hector_quadrotor trae prediseñados algunos entornos, es sencillo crear uno propio que cumpla los requisitos

para probar los algoritmos realizados en este trabajo. El entorno consiste en una superficie plana simple con

objetos que deben ser detectados por el drone, pueden añadirse objetos que cumplan una función estética, pero

no responden al objetivo de este trabajo.

Figura 4-4. Ejemplo de entorno predeterminado, con montañas.


22

22

4.4 Análisis de imágenes

Se pasa ahora al apartado más crítico de la simulación, el reconocimiento de imágenes. El UAS publica las

imágenes en un tópico al que se puede suscribir un nodo. Utilizando un nodo, se debe entonces analizar las

imágenes captadas utilizando OpenCV para obtener los datos deseados. En este caso, el objetivo es detectar

formas simples como esferas u líneas rectas que formen parte de poliedros.

Para lo anterior se emplean distintas funciones de OpenCV como pueden ser, “Houghcircles” [25] o

“Houghlines” [26] que a su vez utiliza el “Canny Edge Detector” [27].

4.4.1 Algoritmo de Canny

El algoritmo de Canny es un operador diseñado por John F. Canny en 1986 que utiliza un algoritmo de

múltiples etapas para detectar bordes en imágenes. Las premisas que debía cumplir cuando surgió la idea de su

desarrollo fueron:

- Buena detección. Debían detectarse el mayor número de bordes existentes en la imagen real.

- Buena localización. Los bordes detectados debían estar lo más cercanos posibles a su posición en la

imagen real.

- Respuesta mínima. Los bordes no debían detectarse más de una vez y el ruido no debía presentar

falsos positivos en la medida de lo posible.

El proceso que realiza el algoritmo es el siguiente. En primer lugar, realiza un filtro utilizando la primera

derivada de una Gaussiana. Aplicando este filtro se consigue una imagen algo difuminada que es menos

susceptible al ruido. A continuación, aplica a esta imagen unos filtros para detectar bordes horizontales,

verticales y diagonales. Por último, suprime los píxeles que no pertenezcan a una línea y aplica histéresis para

suprimir todos los bordes que no cumplan con la longitud o las características deseadas.

Figura 4-5. Ejemplo de un filtro gaussiano de orden 5.

Figura 4-6. Cálculo del gradiente de borde y dirección.

Este es el método que utiliza la función “Canny Edge Detector” que a su vez es utilizada por las otras dos

funciones.

23


4.4.2 Transformada de Hough

La transformada de Hough es una técnica de detección de figura en imágenes digitales. Es muy utilizada en el

campo de la visión por computador, para captar formas como rectas, circunferencias o elipsis.

Su funcionamiento es muy simple, dado un punto bidimensional por sus coordenadas (x, y) es posible dibujar

gráficamente toda la familia de líneas que pasan por ese punto de la imagen, que aparecen como una curva

senoidal. Realizando esta acción para todos los puntos si se produce el hecho de que dos curvas intersectan en

un punto significa que estos puntos pertenecen a una recta. Con esto se pueden detector las líneas y acotarlas

en función del número de puntos mínimos que deban tener para ser consideradas como tales.

Figura 4-7. Tres curvas de diferentes puntos intersectando, forman parte de una sola línea.

Este método es el que usan tanto “Houghlines” como “Houghcircles”, partiendo como base de una imagen

procesada por el algoritmo de Canny que arroja como resultado una imagen binaria de los bordes con la que es

más sencillo trabajar.

En definitiva, lo que se pretende implementar es un nodo, que tras suscribirse al tópico de la cámara del

quadrotor, realice un análisis en tiempo real de las imágenes de video. Tras comprobar la existencia de líneas o

círculos en la imagen, pueden realizarse varias operaciones. En el caso de este proyecto, en primer lugar, se

marcan los objetos en la pantalla. Las esferas se marcan con un círculo rojo que aproxima el perímetro y un

punto verde que marca el centro, mientras que las líneas se marcan en azul.

De forma adicional, se va a intentar aproximar la distancia de los objetos al quadrotor con el fin de ofrecer una

especie de visión espacial. Al tratarse de una cámara monocular, no es posible tener visión 3D, pero si se

conoce el tamaño aproximado del objeto y la resolución en píxeles de la cámara es posible aproximar su

tamaño por el número de pixeles que ocupa. Comparándolo con el tamaño real se puede entonces calcular su

distancia.


24

24

25


5 RESULTADOS

Lo importante es no dejar de hacerse preguntas.

- Albert Einstein-

na vez expuesto todo lo analizado en los capítulos anteriores es hora de exponer y explicar los

experimentos realizados en este trabajo con el fin de demostrar la funcionalidad de los métodos

implementados en una simulación. Se trata de simulaciones realizadas en Gazebo y RViz a través de

ROS y utilizando OpenCV. Se seguirá en este capítulo una estructura en la que se irán exponiendo las pruebas

y comentando las dificultades aparecidas, las mejoras que se han ido implementando y el resultado final

obtenido.

5.1 Primeros pasos

En un principio, el primer paso es crear un workspace, en este caso se utilizará el que se crea al descargar el

hector_quadrotor [23] ya que estarán a disposición los paquetes para realizar la simulación de su entorno y

solo habrá que añadir paquetes adicionales para realizar los experimentos que se deseen. Para crear un

workspace basta con seguir los tutoriales básicos de ROS.

Figura 5-1. Workspace del proyecto.

Se puede observar en la imagen 5-1 que los paquetes se instalan automáticamente al descargar el

hector_quadrotor y también una carpeta llamada perception_module creada desde cero donde se realiza el

análisis de imágenes y también se encuentran nodos que sirven para hacer volar de forma autónoma al UAS.

Algunos archivos de las demás carpetas también se modifican para adaptarlos al trabajo.

U

Resultados

26

26

5.2 Vuelo del quadrotor

En primer lugar, se realiza un vuelo de pruebas del quadrotor para comprobar su correcto funcionamiento. Se

abren aquí varios interrogantes que deben ser resueltos para poder llevar a cabo esta prueba.

Figura 5-2. Primer ensayo de hector_quadrotor.

Se ejecuta una simulación de las propuestas en la página web de ROS para realizar este ensayo. Como se

puede observar, el quadrotor se despliega en un entorno montañoso simulado. Utilizando en los terminales el

comando “rostopic list”, se puede ver que existe un tópico llamado cmd_vel que permite aplicar velocidades,

pero antes de pensar en que forma comandarlas se deben activar los motores, ya que vienen deshabilitados en

un principio, haciendo inútiles los comandos de velocidad.

Figura 5-3. Ejemplo de terminales utilizados simultáneamente.

27


El problema anterior se solventa con el comando “rosservice call enable_motors true”, directamente en un

terminal. Se puede ver en la imagen 5-3 la cantidad de terminales simultáneos que se deben de manejar

simultaneamente para poder realizar los experimentos.

5.2.1 cmd_vel

Hay diferentes formas de ordenarle al UAV que vuele, la más sencilla es publicar con rostopic en un terminal

unos parámetros para la velocidad lineal y angular.

Figura 5-4. Quadrotor despegando ante una orden dada.

Esta orden, aunque eficaz, resulta poco útil para vuelos más complejos ya que exige estar constantemente

publicando órdenes en el terminal. Se deben explorar alternativas que nos permitan realizar un vuelo

controlado de manera más simple, ya sea autónomo o manual. El objetivo de este trabajo es obtener datos a

través de una cámara, que puede apreciarse en las imágenes de RViz abajo a la izquierda, datos que habrá que

analizar luego y por tanto el modo de vuelo debe permitir variabilidad de forma rápida.

Resultados

28

28

5.2.2 Nodo flying

La solución natural al problema es crear un nodo que se suscriba al tópico anterior y permita publicar órdenes

a una frecuencia deseada, modificándola cuando se crea oportuno en función de la frecuencia de publicación

de mensajes elegida. Para ello se ha creado el nodo flying que permite esta función y puede ser ejecutado con

el comando rosrun.

Figura 5-5. Quadrotor realizando un vuelo circular utilizando el nodo flying para esto.

Con este sistema se dispone de una mayor autonomía en el vuelo lo que puede definirse como vuelo autónomo

y permite centrar la atención en los sensores que deben ser analizados.

5.2.3 Control manual

El último de los métodos implementados para el control del RPAS es el control manual por teclado, utilizando

el paquete de “teleoperation twist keyboard” [28] que permite manejar manualmente el quadcóptero por

teclado comandándole las velocidades lineales y angulares. A la hora de experimentar es muy útil ya que es el

método que ofrece un mayor control del UAS y por tanto permite realizar distintas pruebas en un entorno sin

tener que modificar un archivo o estar comandando constantemente desde un terminal. La velocidad de

respuesta es mucho mayor que los dos sistemas anteriores, y es por tanto el que se ha utilizado en toda la fase

experimental.

29


5.3 Análisis de imagen

El análisis de imagen es una de las partes más importantes del proyecto, y para poder llevarlo a cabo, se ha

tenido que crear un nodo que se suscribiese a las imágenes publicadas por el quadrotor para proceder a su

posterior análisis. Existe un tópico que publica las imágenes que se observan en RViz, una vez suscrito a este

es el momento de analizar las imágenes en tiempo real en busca de formas de interés.

El nodo “img_proc” realiza este análisis utilizando las funciones de OpenCV mencionadas en el tema anterior.

Si se identifica alguna figura se pasa a marcarla en la imagen utilizando otras funciones de OpenCV como

pueden ser “line” o “circle”. Una vez modificada la imagen original esta se publica en un nuevo tópico para

poder ser observada.

5.3.1 Rqt_image_view

A la hora de observar la imagen modificada se utilizará este paquete que permite observar los distintos tópicos

publicados en tiempo real. Esto ayuda mucho a la hora de controlarlo en manual, pudiendo realizar así un

vuelo en primera persona utilizando solo la imagen de salida como referencia.

5.3.2 Cálculo de la distancia

Una funcionalidad que se ha decidido introducir es la del cálculo de la distancia del objeto al drone. Al tratarse

de una cámara monoscópica, como se ha dicho en temas anteriores, se debe conocer el tamaño de objeto a

priori para realizar los cálculos. Una vez hallada la distancia se publicará en la misma imagen con el comando

“putText” tanto para las esferas como para las líneas utilizando para unas el radio de la esfera y para la otra la

longitud de sus lados para la aproximación del tamaño y la distancia

5.4 Entorno

Los “world” de gazebo permiten crear gran variedad de entornos como se ha visto con anterioridad, esto

incluye multitud de estructuras y objetos disponibles en las librerías de gazebo, pero también formas simples

con distintos colores y fondos.

Figura 5-6. Entorno en Gazebo con cielo con nubes y objetos y suelo de distintos colores.

Resultados

30

30

El problema de crear entornos con tantas formas complejas o tantas diferencias de colores es que facilita

mucho la aparición de falsos positivos. Es por eso que a la hora de realizar las pruebas se haya optado por

entornos más sencillos para evitarlos en la medida de lo posible.

5.5 Pruebas

Las pruebas comienzan utilizando un entorno predefinido ya por el paquete que se ha utilizado. Esto causa

distintos problemas que pueden apreciarse en la figura 5-7. El primero son la aparición de falsos positivos

debido a que el nodo que analiza la imagen capta líneas rectas en objetos del entorno como son las montañas

en este caso, lo cual crea incorreciones difíciles de eliminar. El otro problema es que el color por defecto de los

objetos a identificar es el mismo que el del fondo predefinido y por tanto puede camuflarse con este y

dificultar la detección.

Figura 5-7. Detección de objetos con errores no deseados.

Por todos estos factores se decide personalizar un entorno más acorde con los requisitos. También cabe

mencionar, que la resolución de la cámara no es muy grande y por ende es más difícil captar detalles. Esto

causa un mayor número de errores debido a que al concentrarse varios elementos en una parte de la imagen es

más sencillo que se confundan con otros y se produzcan falsos positivos.

5.5.1 Pruebas de vuelo

En primer lugar, se puede volar en los distintos entornos con el nodo que permite un vuelo autónomo, esto es

posible, pero causa algunos problemas. Estos son principalmente que la ruta comandada es fija, no pudiendo

modificarla durante la ejecución, y por tanto limita a la hora de realizar las pruebas. Aparte de ser muy

engorroso tener que modificar o crear nuevos nodos cada vez que se quiera realizar una aproximación a la

pieza desde distintos ángulos.

31


Figura 5-8. UAV volando autónomamente en Gazebo.

Se puede ver en la imagen 5-9 que la cámara observa las figuras, pero se está limitadoa a esos ángulos si se

trabaja con nodos.

Figura 5-9. Vuelo autónomo en RViz.

Es por esto que se trabajará con el control manual en los siguientes apartados para permitir más libertad de

vuelo y más rapidez en las pruebas.

Resultados

32

32

5.5.2 Detección de círculos

Aplicando la función de Hough para círculos y especificando el tamaño mínimo del radio para dar una

detección positiva, se pueden detectar esferas en el entorno de manera muy sencilla. Además, la función

devuelve el radio de la esfera detectada, que puede utilizarse directamente para calcular la distancia de la

cámara a la esfera. Se marca el centro y el perímetro aproximado para confirmar la detección. El cambio de

color a azul se realiza en el world modificando la línea Gazebo/Grey por Gazebo/Blue dentro del script entre

name. La elección del color azul es simplemente por prueba y error, ya que es un color que la cámara detecta

mejor.

Figura 5-9. Detección de una esfera.

Se observa que el perímetro es muy exacto. La distancia se ha ido mejorando a partir de pruebas, al no

conocerse la resolución exacta de la cámara en píxeles ni el tamaño exacto del objeto, llegando a un resultado

bastante fiable. Como se ha mencionado anteriormente, todo esto se realiza con control manual, como se

puede observar en las imágenes ya que se pilota desde el terminal. Esto permite el acercamiento a una pieza

desde los ángulos deseados.

5.5.3 Detección de líneas

Para la detección de líneas se ha utilizado la función de Hough equivalente. Esta plantea más dificultades que

la anterior, ya que es menos precisa y la resolución de la cámara le causa más problemas. Además, no

devuelve la longitud de la línea sino sus puntos inicial y final en coordenadas cartesianas por lo que es

necesario realizar un cálculo sencillo con estos datos para poder despejar su longitud y con esto la distancia al

objetivo. Pese a ello, sigue siendo una aproximación más inexacta, ya que mientras más oblicua se encuentre la

línea, más error existirá en su detección al variar su longitud, algo que no pasa con las esferas. Pese a todo es

una aproximación que en la mayoría de los ensayos suele ser realista.

33


Figura 5-10. Detección de cubo frontalmente.

No importa si la detección se hace oblicua ya que el sistema lo detecta de manera satisfactoria.

Figura 5-11. Cubo detectado tras aproximación oblicua.

Resultados

34

34

5.5.4 Detección simultanea

Con las funcionalidades implementadas es posible detectar ambas figuras a la vez. Esto es así dado que el

nodo funciona de manera escalonada analizando siempre la imagen original y por tanto la detección de un

elemento no afecta al otro.

Figura 5-12. Detección de dos figuras simultáneamente.

Con esto se llega al final de las pruebas realizadas. Se ha conseguido realizar el objetivo de este trabajo, que no

era otro que completar una simulación de un UAS con detección de objetos. La finalidad era demostrar en una

simulación que existen amplias aplicaciones reales para estos vehículos cuya evolución parece imparable

mientras la legislación evolucione de manera consecuente.

35


6 CONCLUSIONES Y TRABAJO FUTURO

Nadie es capaz de señalar el lugar del cerebro donde se generan las buenas ideas.

- Miguel Delibes-

l trabajo realizado ha sido fruto de una idea que surgió tras cursar distintas asignaturas de robótica y

control dada la especialidad elegida de automática. Tras finalizar este TFG es posible estar satisfecho del

trabajo realizado, ya que se han cumplido los objetivos planteados.

El reto principal de este proyecto ha sido aprender ROS, pese a disponer de una extensa wiki y un buen foro, el

nulo conocimiento que se adquiere en el grado hace que embarcarse en esta empresa sea algo que puede

asustar en un principio. Es sorprendente que dada su utilidad y su uso a nivel empresarial y de investigación no

sea una herramienta que vean apropiado impartir en la escuela al menos a los que cursan la especialidad de

automática o electrónica.

Aun así, dado el conocimiento que se adquiere de distintos lenguajes de programación durante el grado y de

otras cualidades que se desarrollan durante el mismo esto permite que el aprendizaje de ROS de manera

autodidacta no sea imposible. Además, se convierte en algo muy satisfactorio a medida que se van alcanzando

objetivos, aunque al principio pueda resultar lento y parecer inabarcable.

6.1 Posibles mejoras

Al partir desde cero en este proyecto se ha podido llegar a este punto, pero es evidente que partiendo de esta

base pueden desarrollarse mejoras que doten al sistema de aptitudes para desarrollar tareas más complejas y

por tanto le permitan ser una base para un robot comercial o de investigación.

6.1.1 GPS

Una de las más claras al tratarse de un vehículo que a priori circularía en el exterior es la implementación de

un GPS para poder navegar de manera autónoma de forma mucho más sencilla. Esto permitiría varios modos

de vuelo y ayudaría a la detección tanto del RPAS como del objetivo.

Figura 6-1 Vuelo en Mission Planner en un entorno real con GPS

E

Conclusiones y trabajo futuro

36

36

6.1.2 Detección de formas complejas

En este Proyecto no se ha pasado de la detección de formas simples, pero es evidente que para que esto sea útil

a un nivel mayor el UAS debería ser capaz de reconocer otras formas más complejas. Estas pueden ser

distintos tipos de objetos o por ejemplo caras de personas para su posterior identificación.

OpenCV ofrece algunas funciones algo más complejas para realizar estas acciones como pueden ser:

- Cascade Classifier [29]

Figura 6-2. Reconocimiento facial con cascade clasiffier.

- Face recognition with video [30]

- Download object models and use it for object detection [31]

- Find_object_2D [32]

Entre muchas otras que se pueden encontrar tanto en la wiki de OpenCV como en la de ROS y sirven para

detectar formas o caras utilizando distintos métodos. Principalmente utilizan comparación con imágenes de

referencia para identificar el objeto buscado. Esto permite que con suficiente cantidad de datos puedan ser

identificadas formas muy complejas.

37


Figura 6-3. Aplicación del find_object_2D

6.1.3 Evitación de obstáculos y seguimiento de objetivos

Una funcionalidad muy útil que no necesitaría utilizar la cámara, sino otro tipo de sensores, como ultrasónicos

o láser, es que el sistema evitase obstáculos dinámicos y estáticos de manera automática, evitando colisiones

indeseadas y dándole una mayor seguridad al vuelo. Esto podría lograrse utilizando distintos algoritmos de

evitación de obstáculos. Algunos de estos son simples como utilizar sensores de distancia para detectar

obstáculos y realizar un hovering hasta que el obstáculo desaparezca. Algunos más complejos pueden

encontrarse en la wiki de ROS como pueden ser los siguientes.

- Xbot obstacle aviodance [33]

- Quadrotor altitude hold and obstacle avoidance [34]

- Obstacle Avoidance and Robot Footprint Model [35]

Entre muchas otras que pueden encontrarse. Se parte de la premisa de que el sistema, en este caso el UAS, es

capaz de conocer su entorno utilizando algún sensor, aproximar la distancia a ese objetivo para determinar si

es peligroso o no y saber si requiere ser evitado. A raíz de esa información, el sistema comienza o no una

rutina de evitación que puede consistir en multitud de maniobras o acciones dependiendo de la situación.

Una vez realizado lo anterior, se podría implementar alguna forma de seguimiento de objetivos, ya sea

utilizando una cámara estereoscópica o aproximaciones utilizando GPS y una cámara monocular como la de

este trabajo. Esto sería útil para muchas aplicaciones que exijan mantener al objetivo dentro de la imagen y

constantemente localizado. La evitación de obstáculos es crítica para llevar a cabo esta acción, dado que si el

sistema realiza un seguimiento de objetivos sin tener en cuenta su entorno fácilmente colisionaría. Un ejemplo

de esto lo tenemos ya implementado en ROS con el robot turtlebot [36] que es capaz de seguir a un objetivo

que se le coloque delante, si este objetivo se le acerca el robot retrocederá, evitando una colisión.

6.2 Aplicaciones

Se pasa ahora a exponer un par de campos de aplicaciones de esta tecnología en el ámbito real que para el

autor podrían presentar una mejora respecto a la tecnología utilizada en la actualidad.

6.2.1 Tareas de grabación

La idea de este trabajo parte de la lectura de un paper [37] que trata el uso de quadrotors para grabar películas

o distintas filmaciones profesionales. Esta tecnología ya empieza a aplicarse, pero requiere a un experimentado

piloto que controla el quadrotor. El artículo propone un quadrotor automatizado que identifique al objetivo que

debe seguir y lo mantenga en el centro de la imagen mientras lo sigue y evita colisiones de forma autónoma.

Conclusiones y trabajo futuro

38

38

Esta tecnología también podría usarse para la grabación de anuncios, por ejemplo, no solo siguiendo personas

sino también objetos móviles de interés.

Figura 6-4. Ejemplo de filmación de un coche.

6.2.2 Labores de vigilancia y patrulla

Una aplicación cuya idea ha surgido a lo largo de este proyecto es la posibilidad de utilizar RPAS tanto para

vigilar propiedades privadas como por ejemplo fincas rurales, como labores de patrulla y seguimiento de

presuntos delincuentes en ciudad.

Ambas funcionalidades servirían para la identificación de sospechosos, y en caso de ser necesario, que se le

siguiese para poder proceder a su detención. Evidentemente la legislación está lejos de poder permitir esto en

ciudad, pero en zonas rurales en lugar de usar cámaras fijas podría tratarse de una buena alternativa.

Figura 6-5. Drone persiguiendo a un ciclista, posible seguimiento e identificación.

6.3 Reflexión final

Este TFG ha supuesto una experiencia muy satisfactoria para mí. Un trabajo ambicioso con el que partía sin

ninguna garantía de éxito y que puedo llamar como mío. Es por tanto mi primera publicación y supone una

gran satisfacción personal que me abre la mente para trabajos futuros. Las ganas de aprender y de mejorar

deben ser inherentes al oficio de ingeniero y es por esto que cosas así me hacen pensar en que estoy dando

pasos para ser un miembro productivo de este gremio.

Tal vez en algún momento vea adecuado trabajar sobre esta base que finalizo aquí y ampliarla con los

elementos propuestos para publicar un trabajo mejorado con el conocimiento que adquiera en el futuro y del

que sentirme más orgullos si cabe que ahora.

39


REFERENCIAS

[1] https://eltornilloaereo.jimdo.com/el-tornillo-aereo/

[2] https://es.wikipedia.org/wiki/Hermanos_Wright

[3] https://es.wikipedia.org/wiki/Veh%C3%ADculo_a%C3%A9reo_no_tripulado

[4] John F. Keane and Stephen S. Carr, (2013) A Brief History of Early Unmanned Aircraft

[5] Bob Ward, (2009) Dr. Space: The Life of Werner Von Braun

[6] Annie Jacobsen, (2013) Operation paperclip

[7] John Swift, (2008) Atlas histórico de la Guerra Fría

[8] Anibal Ollero, (2016) General Characteristics of Unmanned Aircraft Systems

[9] Boletín oficial del estado, (17.10.2014)

[10] https://www.easa.europa.eu/unmanned-aircraft-systems-uas-and-remotely-piloted-aircraft-systems-rpas

[11] https://es.wikipedia.org/wiki/Sustentaci%C3%B3n

[12] https://es.wikipedia.org/wiki/Quadcopter

[13] http://www.ros.org/

[14] M. Quigley, B. Gerkey, and W. D. Smart, “Programming robots with ros,” 2015.

[15] http://wiki.ros.org/es

[16] http://answers.ros.org/questions/

Referencias

40

40

[17] http://erlerobotics.gitbooks.io/erlerobot/content/es/ros/ROS-concepts.html

[18] Carmen Mera Prieto, (2015) Métodos reactivos basados en campos potenciales

para UAVs

[19] Ana Escalante Escalante, (2016) Análisis del método de odometría lidar LOAM

[20] http://wiki.ros.org/rviz

[21] http://gazebosim.org/

[22] http://opencv.org/

[23] http://wiki.ros.org/hector_quadrotor

[24] http://wiki.ros.org/teleop_twist_keyboard

[25] http://docs.opencv.org/2.4/doc/tutorials/imgproc/imgtrans/hough_circle/hough_circle.

html?highlight=hough

[26] http://docs.opencv.org/2.4/doc/tutorials/imgproc/imgtrans/hough_lines/hough_lines.

html?highlight=hough

[27] http://docs.opencv.org/2.4/doc/tutorials/imgproc/imgtrans/canny_detector/canny_detector.

html?highlight=canny

[28] http://wiki.ros.org/teleop_twist_keyboard

[29] http://docs.opencv.org/2.4/doc/tutorials/objdetect/cascade_classifier/cascade_classifier.html#cascade-

classifier

[30] http://docs.opencv.org/2.4/modules/contrib/doc/facerec/tutorial/facerec_video_recognition.

html?highlight=recognition

[31] http://wiki.ros.org/roboearth_stack/Tutorials/

Using%20recorded%20models%20for%20object%20detection

[32] http://wiki.ros.org/find_object_2d

41


[33] http://wiki.ros.org/xbot/tutorials/indigo/Xbot%20Obstacle%20Avoidance

[34] http://wiki.ros.org/openni/Contests/ROS%203D/Quadrotor%

20Altitude%20Control%20and%20Obstacle%20Avoidance

[35] http://wiki.ros.org/teb_local_planner/Tutorials/Obstacle%

20Avoidance%20and%20Robot%20Footprint%20Model

[36] http://wiki.ros.org/turtlebot_follower

[37] Tobias Nageli, Javier Alonso-Mora, Alexander Domahidi, Daniela Rus, Otmar Hilliges. (2017) Real-time

Motion Planning for Aerial Videography with Dynamic Obstacle Avoidance and Viewpoint Optimization

Referencias

42

42

43


GLOSARIO

UAS: Unmanned Aerial System 1

RPAS: Remotely Pilotes Aercraft System 1

UAV: Unmanned Aerial Vehicle 1

USA: United States of America 4

NASA: National Aeronautics and Space Administration 5

URSS: Unión de Repúblicas Socialistas Soviéticas 6

UE: Unión Europea 7

GCS: Ground Control Station 7

IA: Inteligencia Artificial 8

EASA: European Aviation Safety Agency 8

TFG: Trabajo de Fin de Grado 9

RGB-D: Red Green Blue - Depth 11

Lidar: Light Detection and Ranging 12

SLAM: Simultaneous Localization and Mapping 12

Glosario

44

44

Detección e identificación de formas utilizando imágenes...

Documents

Transcript of Detección e identificación de formas utilizando imágenes...