Graduado en Matemáticas e Informática

Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieros Informáticos

TRABAJO FIN DE GRADO

Visualizador gráfico para monitorización

del comportamiento de vehículos aéreos

no tripulados

Autor: Jorge S. Sánchez Serrano

Director: Martín Molina

MADRID, JULIO 2017

”Hoy en dıa la mayorıa del software existe no para resolver un problema,sino para actuar de interfaz con otro software”

I. O. Angell

I

Abstract

This report is a complete and detailed explanation of the final grade work done by Jorge

Sanchez with tutor Martın Molina and the Aerostack team at the Informatics ETS.

The purpose of this work was to create a new tool for the software package that could be

integrated with a graphical interface called the interface HMI or the Human Machine Interfa-ce[8]. Aerostack[1] is a set of tools for working with unmanned aerial vehicles. In particular,

the developed tool is a graphical visualization tool to monitor the vehicles. The purpose of

this tool is to make the human eye pleasant and visually rich. For search of information has

been used Internet for search of graphic examples on which to base and specific pages for

software developers like forums, wikis.

Among the sections and subsections will be explained which is each piece of the project,

what are the ideas that have emerged during the development and the final results of those

ideas. This report will also describe the results of the tests, about the general impression and

conclusions that he got from the project.

Resumen

Esta memoria es una explicacion completa y detallada del trabajo de final de grado realizado

por Jorge Sanchez con Martın Molina de tutor y el equipo de Aerostack en la ETS de In-

formaticos.

El proposito de este trabajo era crear una nueva herramienta para el paquete de software Ae-rostack[1] que pudiera ser integrada con una interfaz grafica llamada interfaz HMI o HumanMachine Interface[8]. Aerostack es un conjunto de herramientas para trabajar con vehıculos

aereos no tripulados. En concreto, la herramienta desarrollada es una herramienta de visuali-

zacion grafica para monitorizar los vehıculos. Para busqueda de informacion se ha utilizado

Internet para busqueda de ejemplos graficos en los que basarse y paginas especificas para

desarrolladores de software como foros, wikis.

Entre las secciones y subsecciones se explicaran que es cada pieza del proyecto, cuales son las

ideas que han surgido durante el desarrollo y los resultados finales de dichas ideas. Tambien

se hablara sobre los resultados de las pruebas, sobre las apreciaciones generales y conclusio-

nes que haya sacado de la realizacion del proyecto.

Indice general

1. Introduccion 11.1. Contexto del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4. Organizacion de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5. Contexto general e identificacion de necesidades . . . . . . . . . . . . . . . 3

1.6. Descripcion de las funciones del sistema a desarrollar . . . . . . . . . . . . . 3

2. Antecedentes del trabajo 52.1. Robotica aerea y entorno Aerostack . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Arquitectura de Aerostack . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2. La interfaz HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Tipos de HUD para pilotos de aeronaves . . . . . . . . . . . . . . . . . . . . 10

2.2.1. Factores de diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2. Ejemplos de referencia de HUDs . . . . . . . . . . . . . . . . . . . . 11

3. Diseno de la solucion 133.1. Diseno grafico propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Etapas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1. Diseno de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. Programacion de la solucion 184.1. ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2. Uso de la biblioteca de OpenCv . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3. Organizacion del codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.1. El paquete catkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3.2. Creacion de la clase . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4. El proceso de transformacion de imagen . . . . . . . . . . . . . . . . . . . . 21

4.4.1. La imagen superpuesta y la realidad aumentada . . . . . . . . . . . . 23

4.4.2. Los procesos internos . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5. Solucion de integracion con Aerostack . . . . . . . . . . . . . . . . . . . . . 28

I

5. Validacion 305.1. Pruebas de funcionamiento del programa . . . . . . . . . . . . . . . . . . . . 30

5.2. Pruebas de integracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3. Metricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.4. Resultado de las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6. Conclusiones 356.1. Revision de los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2. Lıneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7. Anexos 377.1. La funcion linspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.2. Programas utilizados en las simulaciones . . . . . . . . . . . . . . . . . . . . 38

7.2.1. Video Stream OpenCv . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2.2. Rosbag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2.3. OpenCv imshow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7.2.4. Creacion de bordes con OpenCv . . . . . . . . . . . . . . . . . . . . 38

II

Indice de figuras

2.1. Logo de Aerostack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Diagrama de la arquitectura de Aerostack . . . . . . . . . . . . . . . . . . . 7

2.3. Ventana HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1. Diseno final para la imagen de camara amplia . . . . . . . . . . . . . . . . . 15

3.2. Pizarra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3. Primer diseno. Destacarıa la creacion de bordes automatica por contornos7.2.4 17

3.4. Primer diseno en modo oscuro. Aquı vemos un ejemplo de// la deteccion de

brillo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1. Logo de ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2. OpenCv y Qt son hermanos en este tfg . . . . . . . . . . . . . . . . . . . . . 19

4.3. Archivos del paquete Camera Overlay . . . . . . . . . . . . . . . . . . . . . 20

4.4. Cv Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5. Visualizacion 3d de capas de imagen . . . . . . . . . . . . . . . . . . . . . . 23

4.6. Integracion de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.7. Qt designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.1. Vecinos/Conectividad de pıxeles . . . . . . . . . . . . . . . . . . . . . . . . 39

7.2. Deteccion de ejes por algoritmo Canny . . . . . . . . . . . . . . . . . . . . . 39

7.3. Deteccion y dibujo de contornos . . . . . . . . . . . . . . . . . . . . . . . . 41

III

Capıtulo 1

Introduccion

El trabajo consiste en la creacion de una Interfaz grafica para operadores que realicen

visualizacion de misiones de vehıculos roboticos aereos en la human machine interface [8]

y su integracion dentro del entorno Aerostack y concretamente la interfaz previamente men-

cionada.

1.1. Contexto del trabajoEste trabajo se enmarca dentro del proyecto Aerostack, desarrollado en la Universidad Po-

litecnica de Madrid y producto de la colaboracion de los grupos de investigacion Vision4UAV

de la E.T.S. de Ingenieros Industriales y el Grupo de Sistemas Inteligentes e Ingenierıa del

Conocimiento de la E.T.S. de Ingenieros Informaticos. El proyecto Aerostack engloba un

conjunto de actividades de desarrollo informatico centrado en el campo de la robotica y los

vuelos no tripulados.

1.2. ObjetivosEl objetivo principal es la mejora de Aerostack mediante una nueva herramienta de vi-

sualizacion de misiones. Los objetivos secundarios son la elaboracion de una investigacion

e implementacion de diversas formas de representacion grafica de los datos. Los objetivos

considerados en el desarrollo del presente trabajo de fin de grado han sido:

Analisis del problema Se trata de realizar un estudio del problema de la representa-

cion y visualizacion de los datos que reflejan el estado de vuelos no tripulados. Dicho

estudio comprende la revision de las tecnicas de realidad aumentada en tiempo real,

las diferentes representaciones de las variables y los visualizadores graficos (HUD)

profesionales que ofrecen una funcionalidad similar.

1

Estudio de los metodos existentes: Analisis y estudio de las tecnologıas y tecnicas

actuales cuya utilizacion permita dar una solucion eficiente y robusta al problema que

se desea resolver.

Diseno del sistema Se trata de disenar un sistema informatico para la visualizacion.

La idea es que el software sea lo suficientemente flexible como para poder ir incor-

porando anadidos y nuevas funcionalidades de acuerdo a las necesidades del cliente.

Ademas, se preve que futuros desarrolladores pueda incorporarse en el mantenimiento

y desarrollo del software. Es por ello que se busca un diseno simplificado, eficaz y bien

documentado que facilite todas estas cuestiones.

Implementacion. Programacion del sistema informatico haciendo uso de los lenguajes

adecuados de acuerdo con el diseno planteado. La programacion necesita de la eficien-

cia suficiente al al manejar procesos largos con volumenes importantes de datos, la

adicion de la informacion visual el rapido procesamiento de los datos para mantener

una tasa de refresco similar a la de recepcion.

Pruebas y validacion Se trata de preparar casos de prueba disenados para verificar el

correcto funcionamiento del sistema. Las pruebas consisten en la visualizacion de los

resultados de la transformaciones y de la correcta emision de los datos en estos. Por

supuesto, tambien se disenan pruebas de eficiencia para verificar que las metricas del

programa no exceden los limites de tiempo y consumo.

1.3. OrganizacionEl objetivo principal de este trabajo consiste en desarrollar un sistema que permita vi-

sualizar informacion de vuelo de drones superpuesta a la camara del dron con la finalidad

de facilitar la obtencion de datos al ojo humano mediante el uso de tecnicas graficas de edi-

cion de imagen 2D junto con la integracion con el resto de un interfaz grafica que mejora la

usabilidad del programa.

1.4. Organizacion de la memoriaEsta memoria se divide en 4 capıtulos principales. En el primero de ellos se realiza un

analisis del dominio del problema, mediante una descripcion del entorno del vehıculo aereo

no tripulado y un analisis de las diferentes herramientas existentes para la operacion con UAV.

El segundo y tercer capıtulo tienen como finalidad ofrecer un contexto en el que se realiza

el trabajo para darle coherencia y fondo suficiente como para seguir el hilo de la memoria.

En el tercer capıtulo se describe el diseno de la arquitectura software del que forma parte la

2

herramienta y factores determinantes en el diseno de la misma. Finalmente se proporciona

una descripcion detallada del diseno de los componentes que integran el sistema y requisitos

del mismo. El cuarto capıtulo trata sobre el diseno general con las funcionalidades esenciales

que incluye la herramienta, ası como una descripcion del proceso de creacion. A continua-

cion, en el quinto capıtulo, se realiza una descripcion de la implementacion de la herramienta

e integracion y comunicacion de los diferentes componentes con el software. Por ultimo, se

presentan los resultados obtenidos de las pruebas realizadas para comprobar el correcto fun-

cionamiento del sistema y las herramientas utilizadas en cada uno de los bloques de prueba.

1.5. Contexto general e identificacion de necesidadesEl proyecto Aerostack tiene entre sus modulos la human machine interface, una interfaz

para la monitorizacion de vuelos de vehıculos aereos no tripulados. Dada la cantidad de in-

formacion que hay que monitorizar y la dificultad de extraer conclusiones a partir de una lista

de datos numericos, se penso en hacer un visualizador grafico que pudiera dar la informacion

de forma grafica. Esto atiende a la necesidad de tener los datos ya interpretados sin necesi-

dad de mirar la lista de indicadores manualmente y de representar informacion de tal manera

que facilite el trabajo de un operador. Es necesario que utilice la camara del vehıculo como

primera fuente de informacion para ser enriquecida con datos de vuelo interpretados. Esta in-

terpretacion debe ser facilmente distinguible e interpretable, debe ocupar un espacio ajustado

a la vision de las imagenes de la camara para no tapar la vision de vuelo. Un apunte sobre

esto es que la human machine interface es una interfaz hecha para humanos, es decir, que

cualquier adicion o nueva seccion debe cumplir esta premisa, hay que armonizar el conjunto

para cumplir con las premisas del software en el que se va a integrar.

1.6. Descripcion de las funciones del sistema a desarrollarEl objetivo del trabajo es construir un visualizador para monitorizacion grafica del com-

portamiento de vehıculos aereos no tripulados que realizan tareas de forma autonoma. El

trabajo realizado es el diseno, programacion, integracion y validacion del visualizador grafi-

co, colaborando ası con un equipo de trabajo especializado en sistemas aereos roboticos en

la propia ETS de Ingenieros Informaticos de la UPM. El visualizador podra hacer uso de

tecnicas de realidad aumentada para superponer sobre imagenes de la camara del vehıculo, la

informacion de su estado ası como la interpretacion realizada por los sistemas de percepcion

sensorial que posee. Tambien se plantea la presentacion de otros elementos graficos dinami-

cos orientados a una mejor comprension de las maniobras del vehıculo. Para la realizacion del

trabajo, el alumno hara uso del software de robotica aerea Aerostack, el lenguaje de progra-

macion C++, bibliotecas de software grafico y vision artificial OpenCv y el sistema operativo

robotico ROS. Ademas para determinadas partes es posible que sea necesaria la busqueda o

3

creacion de iconos y como complemento se utilizara algun software de edicion de imagen

sencillo como Pixlr.

4

Capıtulo 2

Antecedentes del trabajo

2.1. Robotica aerea y entorno Aerostack

Figura 2.1: Logo de Aerostack

En esta seccion se presenta el proyecto

Aerostack, desarrollado en la Universidad Po-

litecnica de Madrid y producto de la cola-

boracion de los grupos de investigacion Vi-

sion4UAV de la E.T.S. de Ingenieros Indus-

triales y el Grupo de Sistemas Inteligentes e

Ingenierıa del Conocimiento de la E.T.S. de

Ingenieros Informaticos. Desde un punto de

vista mas tecnico, Aerostack es una arquitectura software de proposito multiple. Dicha ar-

quitectura fue concebida como un sistema soporte para operaciones y misiones multiagente,

esto es, como soporte a operaciones en las que pueden intervenir varios U.A.V.. El proyecto

Aerostack ha sido financiado parcialmente por el Ministerio de Economıa y Competitividad

a traves del proyecto VA4UAV (Visual autonomy for UAV in Dynamic Environments) Las

principales caracterısticas de Aerostack incluyen:

Infraestructura software flexible: Aerostack permite a los desarrolladores programar

sus propios modulos con sus propios algoritmos e incorporarlos a Aerostack.

Distintos modos de operacion: Este sistema permite dos tipos de vuelos, controlado

por el usuario (teleoperacion) y vuelo autonomo guiado por sensores visuales.

Misiones multi robot: Aerostack es capaz de realizar misiones que precisan de varios

robots aereos. En estas misiones se utiliza un swarm de robots identicos comunicados

mediante WLAN.

Sistema de supervision del comportamiento de un vehıculo aereo no tripulado

5

Independencia del hardware: La distribucion actual permite la utilizacion de distintas

plataformas aereas. Se puede ejecutar en ordenadores portatiles u ordenadores a bordo

del UAV.

Modularidad: Una de las principales caracterısticas.Le permite desarrollar modulos

individuales y conectarlos al resto del sistema. Esto facilita el diseno, la implementa-

cion y el testeo de modulos individuales y permite que terceros desarrollen sus propios

componentes.

Para el desarrollo de Aerostack se utiliza Robot Operating System (ROS), un framework

utilizado en el desarrollo de software para robots. ROS proporciona abstraccion del hardware

y de los dispositivos de mas bajo nivel. Este framework tambien proporciona dos metodos de

comunicacion entre distintos procesos, los topics y los servicios. ROS permite el desarrollo

de componentes utilizando los lenguajes de programacion c++ y python. Aerostack se ha

disenado utilizando la version jade de ROS. En cada componente se ha separado la parte

dependiente de ROS de la parte funcional. Es decir, se ha dividido cada modulo entre la

interfaz de comunicacion ligada a ROS y los distintos elementos (algoritmos, clases ...) que

no basan su funcionamiento en este framework. Esto se ha hecho ası con el objetivo de poder

utilizar estos elementos no dependientes de ROS con otras plataformas.

2.1.1. Arquitectura de AerostackComo se ha mencionado anteriormente, una de las principales caracterısticas de Aeros-

tack es la modularidad. Se va a proceder a explicar la arquitectura completa de Aerostack,

explicando las distintas capas que lo forman y los componentes correspondientes a cada capa.

Se entiende que a la hora de utilizar Aerostack no es necesario utilizar todos los componen-

tes, pudiendo escoger los deseados. El diseno de Aerostack consta de cinco capas: reactiva,

ejecutiva, deliberativa, reflexiva y social. Este diseno esta extiende el popular diseno hıbrido

conocido como la arquitectura de tres capas, el cual organiza los algoritmos acorde a tres

capas; la capa reactiva (los algoritmos no tienen estado interno), la capa ejecutiva (los al-

goritmos tienen un estado interno que recuerda la situacion anterior) y la capa deliberativa(los algoritmos tienen un estado interno con predicciones de futuro). Esta arquitectura, por

tanto, sigue el “Hybrid deliberate/reactive paradigm” en el robot primero planea los pasos

a seguir y los divide en subtareas y comportamientos que seran ejecutados. El “Hybrid deli-

berate/reactive paradigm” se diferencia de otros modelos mentales en que la informacion de

los sensores es dirigida tanto a la capa reactiva como a la deliberativa. En la imagen 2.2 se

puede apreciar la arquitectura completa de Aerostack. Es importante notar que nos aparecen

nombrados todos los componentes de los distintos sistemas.

Sistema de supervision del comportamiento de un vehıculo aereo no tripulado A

continuacion se describen todas las capas y los distintos sistemas de cada una de ellas. Las

6

Figura 2.2: Diagrama de la arquitectura de Aerostack

capas en las que se engloba este proyecto corresponde a la capa reflexiva y a la capa ejecutiva,

por lo que se explican estas capas en mayor profundidad.

Capa reactiva: Es la capa correspondiente a los sensores y controladores. Estan presen-

tes el Feature Extraction System, que recibe informacion de los sensores del UAV, y el

Motor System, que manda comandos al vehıculo.

Capa ejecutiva: Actua de intermediaria entre el sistema de planificacion y los contro-

ladores de bajo nivel. Formada por el Executive System, encargado de secuenciar las

ordenes proporcionadas por la capa deliberativa y Situation Awareness System, encar-

gado de un modelo del entorno segun la informacion recibida del Feature extraction

system.

Capa deliberativa: Proporciona directivas de alto nivel segun la mision proporcionada.

Su unico sistema es el Planning System, que se encarga de planificar las tareas a realizar

y la manera de lograrlas.

Capa reflexiva: Es consciente del resto de componentes de la arquitectura. Es la encar-

gada de reaccionar a fallos y de informar a la capa deliberativa la situacion actual de

los sistemas, ayudandolo en la toma de decision. Es la encargada tambien de comuni-

car el estado de las tareas programadas por la capa deliberativa. Esta capa, tambien se

comunica con la capa social, informandola del rendimiento del sistema.

7

Capa social: Es la encargada de comunicar el UAV con elementos externos. Estos ele-

mentos pueden ser un usuario (mediante interfaces graficas) u otros vehıculos.

2.1.2. La interfaz HMILa interfaz HMI (Human Machine Interface) posibilita la interaccion con el vehıculo, la

observacion de los distintos estados de este y sus dinamicas, como pueden ser la velocidad o

la posicion. Esta interfaz proporciona una comunicacion bidireccional entre el operador y el

sistema robotico. Esto es esencial, ya que el operador debe monitorizar el estado de la mision

y le permite a este actuar en el caso de que esta tenga que redefinir, y el robot necesita tener

en todo momento informacion proporcionada previamente por el operador. En general, el

operador puede usar la interfaz grafica para especificar el comportamiento del vehıculo antes

de comenzar la mision, monitorizar el progreso de una mision compleja durante su ejecucion,

operar manualmente el drone con el teclado y el raton, mediante el envıo de comandos basicos

de movimiento y recolectar datos para su uso posterior, como pueden ser imagenes (tanto

videos como fotografıas), o datos relacionados con los sensores. Mientras que el operador

monitoriza el comportamiento del vehıculo durante la ejecucion de una mision, se pueden

distinguir diferentes niveles de descripcion:

Nivel de mision: Este nivel se corresponde al lenguaje usado para describir los objetivos

de la mision. El operador y el vehıculo utilizan conceptos tales como: mision, nombre

de la mision, tarea (parte especıfica de la mision), skill, accion (que es el elemento mas

simple que puede ejecutarse en una mision.

Nivel de operacion: Este nivel se corresponde a los hechos que ocurren derivados de

la accion del vehıculo durante su operacion. Estos pueden ser relacionados con estados

internos de drone, parametros medidos por los sensores e imagenes obtenidas por las

camaras.

Nivel software: Se corresponde al comportamiento interno del vehıculo con respecto a

la ejecucion de los procesos en ejecucion y a los mensajes de error internos. El modu-

lo HMI 2.3 esta creada utilizando las librerıas de Qt, que proporcionan una API que

posibilita la creacion de interfaces de todo tipo. Esto permite una modularizacion de

la interfaz en widgets, siendo cada uno de ellos sub-interfaces graficas independientes.

La modularizacion en widgets permite que existan distintos modulos integrados en una

misma ventana. Lo modulos mas importantes son:

Control Panel: Muestra el estado general del UAV y los controles principales. Esta

dividido en tres areas: el estado del vehıculo, el modo de operacion y los comandos

de operacion, siendo el estado del vehıculo informacion sobre el nivel de baterıa, el

estado de la conexion, la accion ejecutandose en ese momento, y el numero de errores

detectados durante la mision, el modo de operacion la forma en la que el vehıculo sera

8

Figura 2.3: Ventana HMI

controlado y los comandos de operacion controles a traves de los cuales se opera el

drone.

Camera Viewer: Proporciona una interfaz en la que se muestran las imagenes captadas

por las camaras, ademas de proveer al operador con varios layout o modos de vision

distintos para ellas.

Process Monitor: Muestra todos los procesos activos para ayudar al usuario a supervisar

el estado actual del software, proporcionando una lista con todos los procesos activos,

su estado y sus posibles mensajes de error.

Parameter Viewer: Muestra el estado del vehıculo detalladamente, mediante la infor-

macion de los sensores presentes en el drone proporcionada en forma de grafico. El

grafico muestra la evolucion en tiempo real de esta informacion, siendo el eje vertical

el valor y el eje horizontal el tiempo.

Requested skills: Muestra las skills y permite al usuario realizar peticiones de activa-

cion para skill especıficas.

Mission Reporter: Gracias a esta pestana, el operador puede ver un registro completo

de las acciones realizadas por el vehıculo durante la ejecucion de la mision.

9

Dynamics of the vehicle: La interfaz incluye un visor donde poder observar las dinami-

cas del vehıculo, como podrıan ser la posicion y la velocidad.

2.2. Tipos de HUD para pilotos de aeronavesLos robots teleoperados son definidos por la NASA como: Dispositivos roboticos con

brazos manipuladores y sensores con cierto grado de movilidad, controlados remotamente por

un operador humano de manera directa, o mediante un ordenador. En el diseno de Telerobots

se desarrollan y aplican las tecnologıas para el funcionamiento dirigido en el espacio y en

las aplicaciones terrestres. El telerobot dirigido, operando en un sitio, utiliza dispositivos de

entrada, como la visualizacion grafica, planeando las ayudas para ordenar la ejecucion de una

tarea a un sitio remoto usando un sistema telerobotico. Las areas actuales de investigacion y

desarrollo incluyen:

El manipulador y el mando del robot movil.

Las arquitecturas del telerobot remotas.

Procesado, integracion, y fusion, del sistema sensorial.

Tareas interactivas que planea y ejecuta.

La visualizacion grafica de las imagenes sobrepuestas.

Multisensor - el mando equilibrado.

Micromecanismos - control para el despliegue de los instrumentos.

Respecto a nuestro sistema teleoperado, nosotros vamos a trabajar en el punto de visuali-

zacion grafica de imagenes superpuestas. Este aspecto

2.2.1. Factores de disenoHay varios factores que interactuan en el diseno de un HUD, pero solo vamos a hablar de

los que nos competen a nosotros puesto que la mayorıa de las representaciones de HUD son

referentes a la aviacion y nosotros vamos a adaptar de forma sencilla alguna de sus ideas.

Campo de vision Llamado ’FOV’ o Field of View, indica el angulo, verticalmente y

horizontalmente, subtendido en el ojo del piloto o de la camara en nuestro caso que

podemos observar. Un ’FOV’ estrecho significa que la vista (de una pista, por ejemplo)

podrıa incluir poca informacion adicional ; Mientras que una ’FOV’ amplia permitirıa

una vision ”mas amplia”. En nuestro caso, cuando mas pequena sea la ’FOV’, afec-

tarıa a la resolucion de la imagen y nos dejarıa poco espacio para incluir informacion

10

aumentada. Para las aplicaciones de la aviacion, el principal beneficio de una ’FOV’

ancha es que una aeronave que se acerca a la pista en un viento cruzado podrıa tener la

pista a la vista siendo representada en el HUD.

Luminancia / contraste Las pantallas tienen ajustes de iluminacion y contraste para

tener en cuenta la iluminacion ambiental, que puede variar ampliamente (por ejemplo,

desde el resplandor de las nubes brillantes hasta los enfoques nocturnos sin luna hasta

los campos mınimamente iluminados).

Boresight Los componentes HUD de los aviones estan alineados con precision con los

tres ejes de la aeronave un proceso llamado boresighting. Esto permite que la panta-

lla muestre al piloto exactamente donde esta el horizonte artificial, y en avionica se

muestra tambien el trayecto proyectado de la aeronave con gran precision. Cuando se

utilizan determinadas tecnologıas de visualizacion, por ejemplo, la pantalla de las luces

de la pista se alinean con las luces reales de la pista cuando las luces reales se vuelven

visibles.

Escalado - La imagen mostrada (trayectoria de vuelo, escala, inclinacion, etc.) se escala

para presentar al piloto una imagen que supera al mundo exterior en una relacion exacta

de 1: 1. Por ejemplo, los objetos que estan 3 grados bajo el horizonte visto desde la

cabina, deben aparecer en el ındice de -3 grados en la pantalla del HUD.

Compatibilidad Los componentes HUD deben ser disenados para ser compatibles con

otros drones En nuestro caso, los objetos representados en la realidad aumentada se de-

ben escalar segun el tipo de imagen que queramos visualizar y del tamano de la imagen

emitida. Ademas debe ser compatible con cualquier vehıculo robotico con camara.

Datos visualizados Los HUD tıpicos de los aviones muestran la velocidad aerodinami-

ca, la altitud, la lınea del horizonte, el rumbo, el giro / el banco y los indicadores de

deslizamiento / deslizamiento. Otros sımbolos y datos tambien estan disponibles en

algunos HUD: El punto de mira o el sımbolo de lınea de flotacion, el vector de la

trayectoria de vuelo (FPV) o el sımbolo del vector de la velocidad, el indicador de

aceleracion o la senal de energıa y el indicador de angulo de ataque.

Datos de navegacion y sımbolos

2.2.2. Ejemplos de referencia de HUDs

11

(a) Hud 1 (b) hud 3

(c) hud 2 (d) hud 5

12

Capıtulo 3

Diseno de la solucion

Para comenzar a trabajar en el diseno primero hay que hacer dos cosas:

Toma de requisitos: Es el proceso de hablar con el cliente para ver cuales son las necsi-

dades del producto. En este caso, necesitabamos un sustituto para la parte de la interfaz

grafica human machine interface donde se emitian los principales datos de vuelo. Esta

herramienta deberia permitir ver tanto la camara como los datos simultaneamente. Las

caracterısticas mas concretas se van viendo segun la disponibilidad de herramientas y

las capacidades para realizarlas. Es un proceso que se va concretando en iteraciones

de desarrollo. Los primeros pasos del desarrollo a este respecto hacer una busqueda

de Heads-Up Display (HUD) que tomar como referencia y luego crear un prototipo de

diseno a partir de ellos. En general este proceso fue al principio muy primitivo hasta

bastante tiempo empezado el proyecto por dificultades para encontrar formas viables

de cumplir los requisitos.

Busqueda de herramientas Este aspecto ha sido el cuello de botella principal del desa-

rrollo. Dadas las circunstancias, el equipo de Aerostack no tenia conocimientos al res-

pecto, asi que hubo que hacer una busqueda importante de soluciones desde el primer

momento. El primer paso fue entender el funcionamiento del sistema base sobre el que

tendrıa que operar el desarrollo o sea ROS (Robotic Operating System). Tras cono-

cer el funcionamiento basico de ROS, hubo que encontrar la manera de tratar imagenes

con ROS. Sorprendentemente, en los tutoriales de ROS ya habıa suficiente informacion

para no tener que hacer una nueva busqueda de herramientas puesto que te explicaban

como tratar imagenes con las librerıas de opencv en un esqueleto de programa adaptado

al flujo de ROS, que es la siguiente herramienta necesaria para trabajar.

3.1. Diseno grafico propuestoDurante el principio del proyecto se buscaron modelos de HUD sobre los que tomar

referencias y probar a hacer un diseno propio aunque similar a los utilizados en aviacion.

13

El planteamiento principal era adaptarlo para que recordara a un HUD comercial pero sin

perder de vista el objetivo final. Dado el espacio reducido que pueden tener las pantallas

de los drones habıa que procurar que ocuparan lo minimo el espacio de visualizacion pero

que los datos representados sigan visibles. La principal caracterıstica que debia portar era el

dinamismo controlado. El HUD debıa permitir al operador obtener informacion sin que se

viera saturado por el rapido cambio de los datos. Puedo decir que en alguna prueba, los datos

cambiaban de forma tan rapida que eran relativamente molestos y difıciles de observar. Por

esto, los indicadores graficos poseen un sistema de transiciones de datos de forma que existen

perıodos en los que se modifican lentamente y perıodos donde aceptan el nuevo valor. Es muy

importante ademas que el HUD sea coherente y tenga sus propios ’lugares geometricos’ si

se me permite la expresion. Por ejemplo debe ser relativamente simetrica respecto del eje

central en cuanto a posicionamiento y cantidad de objetos.

Los principales elementos que habıa que representar era la lista de datos perteneciente a

la Human Machine Interface:

Datos de posicion

Datos de inclinacion

Baterıa del dron

Nombre del dron

Tiempo de vuelo

Velocidad

El diseno final propuesto incluye las siguientes caracterısticas:

A la izquierda: Bateria del dron, inclinacion del dron en los tres ejes cartesianos.

En el centro: Indicador de angulo lateral (Roll) en forma de curva representado de -30

a 30 grados a escala 1:1.

Debajo, el indicador de pitch representado como una rueda cuyos numeros van girando

segun la variacion de la inclinacion vertical.

Abajo del todo, el indicador de inclinacion horizontal (Yaw) representado como una

circunferencia con marcas recorrida por una flecha interior que va rotando.

Respecto de este indicador, la idea inicial era una rosa de los vientos pero fue descartada

por no haber datos de coordenadas geograficas en los vuelos.

A la derecha:Un panel de texto con el tiempo de vuelo, las coordenadas de posicion y

la velocidad.

14

Figura 3.1: Diseno final para la imagen de camara amplia

3.2. Etapas de desarrolloEl proceso de desarrollo a partir de la toma de requisitos es un proceso largo que debıa

tener en cuenta multiples factores.

Entre ellos primero hay que tener en cuenta los requisitos del cliente, lo siguente es tener en

cuenta las capacidades y/o habilidades para crear un producto que satisfaga las necesidades

del cliente. Ahi es cuando comienza el desarrollo como tal. Realmente, hay que avanzar junto

al cliente con su opinion respecto de lo que le ofreces, pues los requisitos pueden cambiar o

ser mas especificos o anadir algo nuevo que haya que desarrollar.

3.2.1. Diseno de la interfazLa primera interfaz disenada tenıa una serie de iconos e indicadores acumulados a los

lados de la pantalla. Tenia carencia tanto de diseno estetico como de una forma conveniente

para los indicadores. Es bastante parecida al segundo prototipo. Realmene de esta pizarra no

quedo nada y se desecho por completo salvo alguna idea. No llego a implementarse por lo

tanto no existe ningun ejemplo de prueba. La primera interfaz completa implementada servıa

para investigar las opciones graficas aplicables. Con esta interfaz hubieron muchas pruebas y

se implementaron bastantes caracterısticas como el cambio de color segun el brillo, insercion

de iconos (sensibles al brillo tambien), limite de frames emitidos, el primer indicador de

inclinacion (en ingles Attitude indicador) y la generacion de bordes para los objetos (texto,

15

Figura 3.2: Pizarra

iconos, lıneas, etc) del overlay. Este diseno fue desechado.

16

Figura 3.3: Primer diseno. Destacarıa la creacion

de bordes automatica por contornos7.2.4

Figura 3.4: Primer diseno en modo oscuro. Aquı vemos un ejemplo de// la deteccion de

brillo

17

Capıtulo 4

Programacion de la solucion

Para programar la solucion habıa que realizar una serie de fases de investigacion y adap-

tacion al resultado que se quiere obtener. Lo primero es el estudio de los tutoriales de ROS

4.1. ROS

Figura 4.1: Logo de ROS

En espanol es traducido como Sistema Opera-

tivo Robotico (en ingles Robot Operating System,

ROS) es un framework para el desarrollo de softwa-

re para robots que provee la funcionalidad cluster

heterogeneo. ROS se desarrollo en 2007 por el La-

boratorio de Inteligencia Artificial de Stanford para

dar soporte al proyecto STAIR2.

ROS provee de servicios tales como abstraccion

del hardware, drivers de dispositivos, paso de men-

sajes entre procesos, gestion de paquetes, visualiza-

cion,etc. Esta basado en una arquitectura de grafos

donde el procesamiento toma lugar en los nodos que pueden recibir, mandar y multiplexar

mensajes de sensores, control, estados, planificaciones y actuadores, entre otros. La librerıa

esta orientada para un sistema UNIX (Ubuntu concretamente en el proyecto).

ROS tiene dos partes basicas: la parte del sistema operativo, ros, como se ha descrito

anteriormente y ros-pkg, una suite de paquetes aportados por la contribucion de usuarios

(organizados en conjuntos llamados pilas o en ingles stacks) que implementan la funciona-

lidades tales como localizacion y mapeo simultaneo, planificacion, percepcion, simulacion,

etc.

ROS es software libre bajo terminos de licencia BSD.

Las areas que incluye ROS son:

Un nodo principal de coordinacion.

18

Publicacion o subscripcion de flujos de datos: imagenes, estereo,control, actuador, con-

tacto, laser, ...

Los nodos que pueden recibir, mandar y multiplexar sensores, controlar, controlar es-

tados, planificar, actuar y otros mensajes.

Creacion y destruccion de nodos.

Distribucion de nodos: Los nodos estan perfectamente distribuidos, permitiendo pro-

cesamiento distribuido en multiples nucleos, multiprocesamiento, GPUs y clusteres.

Parametros de servidor.

Testeo de sistemas.

Login.

Las aplicaciones de los paquetes de ROS incluyen: Percepcion: identificacion de objetos,

segmentacion, reconocimiento de caras y gestos. Movimiento: Seguimiento de movimiento,

comprension de movimiento egomotion, estructura de movimiento (SFM). Vision Estereo:

percepcion de profundidad a traves de dos camaras. Robotica movil, control, planificacion,

agarre (de objetos).

4.2. Uso de la biblioteca de OpenCv

Figura 4.2: OpenCv y Qt son

hermanos en este tfg

Como hemos visto en ROS, ROS tiene mu-

chos paquetes y aplicaciones relacionadas con la

interaccion de los Robots en el entorno. Algu-

nos ejemplos rapidos: Reconocimiento de obje-

tos, deteccion del movimiento, etc. Se podrıa de-

cir que OpenCv es la base del tratamiento de la

informacion grafica fundamental para estas apli-

caciones. Esto se debe a que tiene una estrecha

relacion con OpenCv que soporta la mayoria de

las operaciones que se utilizan en el mundo de

la robotica. OpenCV es una librerıa de codigo li-

bre de vision artificial originalmente desarrolla-

da por Intel. Es multiplataforma y multilenguaje,

con versiones para GNU/Linux, Mac OS X y Windows y Api para C++, C (deprecada), Pyt-hon y Java. Contiene mas de 500 funciones que abarcan una gran gama de areas en el proceso

de vision, como reconocimiento de objetos (reconocimiento facial), calibracion de camaras,

vision esterea y vision robotica. Su programacion esta escrita en codigo C y C++ optimiza-

dos, permite aprovechar ademas las capacidades que proveen los procesadores multinucleo

19

mediante la ejecucion paralela. OpenCV puede ademas utilizar el sistema de primitivas de

rendimiento integradas de Intel, un conjunto de rutinas de bajo nivel especıficas para proce-

sadores Intel (IPP). Los bucles for son en mi experiencia, uno de los cuellos de botella princi-

pales de cualquier programa, pero especialmente de los programas de Opencv que operan con

todos los pıxeles de una imagen. Un ejemplo, durante el testeo de mi programa hay un bucle

cuyo tiempo de ejecucion quintuplica al del resto del codigo. Este bucle edita todos los pıxe-

les en una imagen de resolucion 420x560 (por ejemplo) de forma independiente. Anadiendo

paralelismo, la mayoria de las operaciones costosas pueden reducir su tiempo de ejecucion en

arquitecturas multinucleo. Para este proposito tiene disponible la operacion parallel for, que

es nativa para paralelizacion de bucles for, aunque tambien permite parelizacion con otras

Apis multiproceso como OpenMP (C, C++ y Fortran), TBB (Intel),Concurrency (PLL, De

Microsoft), GCD (Apple),C= (Extension de C++).

4.3. Organizacion del codigo

4.3.1. El paquete catkin

Figura 4.3: Archivos del paquete

Camera Overlay

El codigo del modulo que captura, transfor-

ma y re-emite la imagen transformada esta en-

capsulado dentro de un paquete catkin llamado

camera_overlay. Este paquete tiene asignadas las

dependencias y demas instrucciones de compila-

cion en el CMakeLists.txt que es el fichero que

utiliza el compilador catkin para determinar lo

que tiene que hacer. Este compilador se ejecu-

ta desde la ruta de archivos principal de Aeros-

tack y puede ejecutarse con muchas opciones, co-

mo es normal para todos los compiladores. Hay

una carpeta launch que tiene diferentes archivos

de configuracion, estos archivos pueden substi-

tuir dinamicamente a las constantes que se utili-

zan en los programas cuando necesitamos parametros que cambien segun el tipo de ejecucion

que queramos realizar. Un ejemplo sencillo es poner como variable los colores que queremos

para las letras o definir el texto que nombre a los canales donde queremos usar para emitir las

imagenes. Ademas tiene la carpeta source, donde se encuentra el fichero de codigo principal

y la carpeta include donde se encuentra el archivo de includes del codigo principal. El archivo

principal contiene una clase llamada ImageConverter que conforma el paquete es una unica

clase ImageConverter que contiene el constructor y los metodos principales que realizan las

fases de creacion, almacenamiento y transformacion de las imagenes. Los paquetes catkin se

crean mediante el comando catkin create package o en caso de conocerlo ya, se puede hacer

20

manualmente. Lo mas importante del paquete es el CMakeLists.txt pues es lo que necesita

un paquete para ser detectado y compilado por catkin. Respecto de esto, es importante de-

notar que ciertos cambios exigiran recompilar los CMakeLists.txt y para forzar esto, se debe

modificar mınimamente en el archivo y guardarlo.

4.3.2. Creacion de la claseLo primero que hay que hacer para crear una clase que interactue con ros es buscar entre

los tutoriales un esqueleto para tomar de referencia y aprender la utilidad de cada funcion. En

nuestros caso necesitabamos un programa que pudiera enviar y recibir mensajes de imagenes.

El esqueleto fue tomado de los tutoriales de ros bajo el nombre de ’Converting between

ROS images and OpenCV images’ Puesto que a estas alturas se supone que ya entendemos

como funciona el sistema de subscripcion y publicacion nos explica como utilizarla para

la modificacion de imagenes y republicacion. El esqueleto basico realiza una subscripcion

de ejemplo, que utiliza un puntero del tipo de transporte de mensajes de imagen de ROS

imageTransport. Estos mensajes recibidos debian ser convertidos a una imagen de un tipo

(cv::Mat) que nuestra librerıa de manipulacion (OpenCv) de imagen pudiera utilizar. Despues

esta imagen es convertida a mensaje de imagen y publicada. Para cualquier otra subscripcion

de datos se debe usar el tipo ros::subscriber como hacemos para los topics de feed de datos.

Image Transport y cvBridge

Image Transport siempre debe utilizarse para suscribirse y publicar imagenes. Pro-

porciona soporte transparente para transportar imagenes en formatos comprimidos de bajo

ancho de banda. Incluye compresion JPEG / PNG y vıdeo de transmision de Theora con

sus plugins. CvBridge convierte entre los mensajes de imagen de ROS y las imagenes de

OpenCV.

4.4. El proceso de transformacion de imagenParte 1: Paso de mensaje a CvImage

Para esta seccion anadire algunos nombres de tipos que son autodescriptivos. Puesto que

nuestro objetivo es editar las imagenes recibidas por la camara del dron necesitamos ha-

cer una subscripcion al topic de ROS que este emitiendo dichas imagenes: Por ejemplo

/drone1/camera/front/image_raw que serıa un ejemplo de nombre de topic o stream de men-

sajes de imagen al que nos subscribirıamos para poder recibirlas. Existe un tipo llamado

CvBridge que es un puente que nos permite transformar un mensaje de imagen de ROS a

un tipo de objeto ‘cv::Mat‘ (O matriz de datos de OpenCv) con una codificacion que po-

demos elegir de entre las que permite OpenCv. En nuestro caso, vamos a pedir imagenes

de tipo BGRA de 4 canales. Es necesario para nuestra tarea que sea esta codificacion y es

21

Figura 4.4: Cv Bridge

una de las primeras cosas que me dı cuenta a la hora de

empezar a manipular las imagenes.

Este tipo CvBridge dispone de unos meto-

dos de copia que espera a la recepcion de una

imagen y cuando recibe algun mensaje, devuel-

ve un puntero CvImagePtr que contiene dentro de

su estructura de datos nuestra imagen, su codifi-

caciony la cabecera de ROS. Este puntero con-

tiene la misma informacion que el tipo de ROS

sensor_msgs/Image, lo cual nos permite convertirlas

entre si.

Paso 2: Transformacion de la imagen

Despues de obtener nuestra imagen nos disponemos a transformarla. En el proceso de desa-

rrollo llegue a la conclusion de que puesto que la imagen puede ser de cualquier tamano. Lo

justo serıa hacer un molde sobre el que poner todos los cambios que quisiera anadir, como

una pegatina y ponerlo encima de la imagen que fuera a emitir. Asi conseguimos ajustarnos a

cualquier imagen recibida, ası que lo primero que hace al comenzar la ejecucion es crear una

matriz vacıa.

¿Cual es la importancia de la codificacion?

La codificacion es la distribucion de color de cada pıxel de la matriz de datos (cv::Mat).

La codificacion por defecto utilizada en OpenCv es BGR (Blue Green Red). Surge un pro-

blema, con esta codificacion los fondos de las imagenes vacıas estan forzados a ser de un

color en ausencia de otro, lo cual significa que una matriz vacıa, de ceros, en una codificacion

BGR es negra por defecto. Esto era un problema cuando intentabas poner texto de color igual

al del fondo y ademas habıa problemas con otros colores. En su momento pensaba que era a

consecuencia de mi falta de conocimientos en la materia de transformacion de imagen digital,

pero llegue a la conclusion de que si querıa poner texto sobre una imagen negra, debıa haber

un cuarto canal que indicara si habıa o no un pıxel ‘activo‘. Ese canal es el canal alpha y es

la principal diferencia estructural entre los archivos de tipo png (RGB+Alpha) y jpg (RGB).

Por suerte, el CvBridge de ROS tiene entre sus codificaciones el BGRA (BGR+Alpha) con

lo cual trabajar con un objeto cv::Mat vacıo, era posible para lo que necesitaba. Resuelto este

problema hacıa falta hacer cambios en la imagen sin que estos afectaran al rendimiento o

modificaran las imagenes entre si. Puesto que ademas el rendimiento se veıa reducido por

la etapa de desarrollo hubo que separar el molde del cv::Mat sobre el que se realizaban las

modificaciones.

22

Resumiendo,cuando comienza el programa, al recibir el primer mensaje crea el molde para

las imagenes. Despues ese molde se copia en otra imagen sobre el que se realizan transfor-

maciones. Finalmente ese molde se pone encima de la imagen original y como resultado da

nuestra imagen con HUD. Y esto es gracias a el canal alpha que nos permite utilizar transpa-

rencias en la imagen.

Paso 3: Paso de Imagen a mensaje de ros

El paso de imagen cv::Mat a mensaje de ros es casi mas sencillo de explicar que la recepcion.

Al principio se declara una sentencia que describe el nombre del topic (o canal de paso de

mensajes) por el que se va a emitir y se pasa por parametro el puntero dentro del cual se

encuentra la imagen al metodo toImageMsg() que es un metodo del tipo cvPointer para este

fin.

4.4.1. La imagen superpuesta y la realidad aumentada

Figura 4.5: Visualizacion 3d de capas de

imagen

La Realidad Aumentada (RA) es el conjunto

de tecnologıas que permiten la superposicion de

informacion o imagenes generadas por ordenador

sobre imagenes del mundo real, enriqueciendo la

visualizacion grafica, por lo tanto, la percepcion

de la realidad con informacion digital. Para vol-

car esta informacion hay que utilizar una interfaz

grafica, en nuestro caso un HUD (Heads-Up Dis-

play). Los Heads-up Display son muy variados

y cada uno tiene unas propiedades diferentes. La

idea principal es poder ver tanto la realidad (o

sea, la salida de la camara en este caso), como una interfaz grafica que cumpla dos requisi-

tos: Que aumente la cantidad de informacion que recibe la persona que esta mirando. Que la

imagen superpuesta no afecte a la visibilidad y en las partes menos utiles, por ejemplo en las

esquinas o si el grafico es pertinente en el centro pero teniendo en cuenta esta premisa. Como

hemos visto en el apartado de transformacion de la imagen 4.4, nos dedicamos a manipular

capas de imagenes.

La mejor analogıa a esto creo que es la utilidad de capas de los programas de edicion de

imagenes y como las capas van superponiendose unas con otras hasta el fin del proceso de

transformacion. (Adobe Photoshop, paint.net, Pixlr, etc).

Como podemos ver en la imagen 4.5 tenemos una imagen original sobre la cual se van

poniendo capas. A nivel de datos, los pıxeles originales deben sustituirse por los pıxeles que

23

contengan alguna informacion. Ası, consiguen emitir imagenes modificadas pero solo lo justo

y necesario. Para esto se implemento la funcion overlayImage que explicare mas abajo.

Previo al este metodo de superposicion de imagenes hubo dos operaciones fueron candi-

datas a ser las que hicieran la operacion pero que hubo que descartar por no proporcionar un

resultado adecuado.

addWeighted: Este metodo fue la primera opcion a la hora de mezclar imagenes. Al

igual que el metodo overlayImage (que explicare despues) realiza una suma de pesos

segun el valor de la transparencia de los pıxeles. Siguiendo la formula:

originalPx ∗ (1.− opacidad) + overlayPx ∗ opacidad (4.1)

Siendo la opacidad, el valor de la transparencia del pıxel a superponer. El problema es

que mantiene un peso fijo donde opacidad vale 0.5 y no se comportaba correctamente

como consecuencia, los colores se veıan mezclados y transparentaba el overlay com-

pleto a pesar de manipular los parametros de opacidad del metodo, hubo que desecharlo

porque no servıa.

copyTo: Este metodo sirve para copiar imagenes al igual que overlayImage. Ambas

pueden copiar una ROI (Region of interest) a otra imagen, pero hubo problemas cuan-

do querıas copiar una imagen sin contar sus pıxeles transparentes, ası que hubo que

descartarla puesto que substituıa totalmente la imagen original dejando solo la capa de

overlay con los datos.

Durante el desarrollo se anadieron iconos que en la version final se acabaron desechan-

do por graficos mas simples. Estos iconos que se copiaban directamente al overlay y

para esto la funcion servıa a su cometido. El problema era cuando tenıas que poner

un icono en superposicion de otro, lo cual sobreescribia el pıxel. El unico caso donde

sucedio esto fue en una idea que tuve para reflejar la direccion del dron, puse una bruju-

la, para dar sensacion de movimiento habıa que superponer una aguja pero esta aguja

sobreescribia los pıxeles que tuviera por debajo de la brujula. Con lo cual para super-

poner encima de una imagen, es necesario usar el metodo overlayImage que respeta los

pıxeles vacios. A nivel de programacion, el aspecto de la superposicion de imagenes es

el aspecto central (o core), es decir, es la parte principal tanto funcionamiento como en

coste computacional, pues es la operacion mas larga. Ademas, las librerıas de OpenCv

no tienen ninguna operacion nativa que permita realizarla correctamente y hubo que

implementarla por completo.

El metodo implementado se llama overlayImage:

Con el conocimiento de como funciona la estructura de datos de matrices de OpenCv

que almacena la imagen se busca pıxel a pıxel el valor de los canales de opacidad del

pıxel a superponer y se opera segun la misma formula 4.1 que el metodo addWeighted.

Solo se modifican los pıxeles en el caso de que no sea transparente(es decir, que la

opacidad no sea nula).

24

4.4.2. Los procesos internos¿Como funciona el programa? Para explicarlo voy primero a adjuntar un esqueleto des-

glosado de las funciones principales Voy a poner nombres diferentes a las funciones a modo

de pseudocodigo legible, que sabra interpretar tanto quien continue desarrollando como otros

lectores. La idea principal del programa es que se subscribe al topic de imagen emitida por la

camara del dron, recibe los mensajes de imagen, hace transformaciones graficas en la imagen

contenida en los mensajes y reemite los cambios por dos topics con mensajes que contienen

imagenes diferentes. Las funciones subscribe son para recibir datos y ejecutar una funcion

Callback cada vez que se recibe un mensaje. Las funciones advertise son para publicar en un

topic determinado mensajes

Callback de tratamiento de imagen

imagesub = nodo.subscribe(topicDeImagen, 1000,&ImageConverter::CallbackDeImagen, this);subGrande= nodo.advertise(topicGrande);subPequeno=nodo.advertise(topicPequeno)void CallbackDeImagen(mensaje){punteroCv = toCvCopy(msg, formato::BGRA8);OperacionesCadaSegundo();CrearMolde();ProcesarOverlay(imagenGrande,0);subGrande.publicar(punteroCv.imagen);ProcesarOverlay(imagenPequena,1);subPequeno.publicar(punteroCv.imagen);

}

Esta es la funcion principal, ya entraremos en detalle con lo que hace cada funcion pero se

ejecuta cada vez que recibe una imagen. En la primera lınea se define el mecanismo que lo

ejecuta. Como sabemos, la guarda en el puntero con el formato BGRA. Pero esta funcion solo

se ejecuta si recibe imagenes, si no recibe imagenes queda a la espera. Despues de recibir

imagenes realiza el metodo de OperacionesCadaSegundo() que hace todas las operaciones

necesarias para la toma del tiempo y de frames.

void secondOperations(){//Comprueba si ha pasado un segundo//Si ha pasado un segundo hace://calcula el frame-rate//resetea el contador de framescomprobacionBrillo();//comprobacion del brillo

}

25

Al final de esta funcion se encuentra comprobacionBrillo(), esta funcion divide la imagen

en canales (R,G,B,A) la convierte a formato HSV y hace la media del canal de brightess.

Hace una comparacion y si esta oscuro activa un flag que cambia el color de los objetos que

se anadan al overlay.

Despues, la funcion principal crea el molde (si no ha sido creado ya), recuerdo que el

molde era una imagen vacıa sobre la que ıbamos a poner nuestra imagen superpuesta. Des-

pues realiza el procesamiento del primer overlay, lo publica y repite con el segundo overlay.

Esto nos permite procesar imagenes de forma diferente puesto que cada imagen tiene un pa-

rametro diferente y nos permite identificarlas. Segun el numero una imagen tendra algunas

caracterısticas diferentes.

En la funcion ProcesaOverlay se puede ver como se ponen diferentes configuraciones. La

base de esto es que hay variables en la clase que se cambian segun necesitemos Esta funcion

realiza AnadirOverlay que pone todo el contenido de indicadores, texto, etc y despues hace

el overlay propiamente dicho.

void ProcesaOverlay(overlay,int id){overlay=clonarMolde();if(id==0){valorTmnoTexto=Tamano1;

}if(id==1){valorTmnoTexto=Tamano2;

}AnadirOverlay(overlay,id);overlayImage(punteroCv->imagen, overlay,punto);

}void AnadirOverlay(overlay,int id){//Add dynamic content each frameDibujaPanelDerecho(overlay,id);DibujaPanelIzquierdo(overlay,id);DibujaPanelDerecho(overlay,id);

}

Paneles e indicadores

No voy a entrar en los detalles de programacion de cada funcion utilizada pero si que voy

a destacar las partes mas importantes de ellas para explicar su funcionamiento.

La idea es que en cada panel estan organizadas las diferentes operaciones de dibujo y se

dibujan secuencialmente: En el panel izquierdo comienza en la esquina izquierda arriba y

dibuja los textos en paralelo hacia abajo. Para mantener la proporcion utiliza la altura de la

ROI que contiene a un texto de ejemplo. Se utiliza la funcion cv::getTextSize para medir el

tamano del rectangulo que contiene a un texto concreto. Los textos estan tabulados segun

26

el espacio que ocuparıa el bloque de texto mas grande. Se han puesto los indicadores mas

relevantes y con mas coherencia para el lado izquierdo.

En el panel central hay indicadores de inclinacion, para los que se utilizan funciones de

dibujo de OpenCv y se realizan calculos de posicionamiento segun el tamano de la imagen

sobre la que se este trabajando. Empezando por arriba:

Indicador de inclinacion lateral o roll: Es una curva imaginaria (concretamente una

seccion de una circunferencia expresada con marcas concretas de graduacion). A nivel

de programacion esta circunferencia toma de referencia una fraccion de la altura de la

imagen y mide los vectores que existen entre el centro de la imagen y dichos puntos,

despues dibuja lıneas en proporcion a ese vector con una determinada longitud. Pone

unos cuadros de texto escalados segun el tamano del texto para quedar alineados. Fi-

nalmente y con el mismo procedimiento, toma otra referencia y dibuja una flecha en

funcion del valor del roll o inclinacion lateral.

Indicador de inclinacion vertical o pitch: Esta representado como una rueda marcada

que varıa fluidamente segun cambia la inclinacion. Para cumplir su papel, creı oportuno

tomar de referencia la distancia entre los puntos del roll correspondientes a -30 y 30

grados. Esta distancia se toma como referencia para dibujar una escala numerica mar-

cando en el medio el valor actual del pitch. Es una lista descendente de numeros, por

ejemplo, si nuestro pitch vale 2, de arriba a abajo saldrıa en nuestra escala [4,3,2,1,0].

Para conseguir un efecto de transicion entre dos valores de inclinacion diferentes, se

utiliza una escala 7.1 entre el numero anterior y el actual. Por ejemplo, si tenemos un

valor de 2 y varıa a 7, si tenemos 5 frames de transicion, en cada momento irıa varian-

do tanto el texto como la posicion de nuestros numeros. Nuestros numeros variarıan

[4,3,2,1,0] [5,4,3,2,1] [6,5,4,3,2] [7,6,5,4,3] [8,7,6,5,4] [9,8,7,6,5]. Esto claro depende

de los parametros que establezcamos al respecto que podrıan variar la representacion

de los numeros o el tiempo de transicion, para la variacion de estas cifras recomiendo

una duracion mınima de medio segundo o algo mas (15-20 frames) porque poner tran-

siciones cortas provoca demasiada rapidez de cambio. Cada frame el indicador se va

desplazando en proporcion a la proporcion de la transicion que lleva realizada. El indi-

cador tiene casos condicionales diferenciados tanto para numeros positivos, negativos

como para aumentos o decrementos en el valor del pitch.

Indicador de inclinacion horizontal: Es decir, el angulo respecto de una referencia (el

cero) geografica o en nuestro caso, una referencia arbitraria. Este es bastante sencillo,

usando la misma tecnica que en el indicador de roll, pero cerrando la circunferencia.

Tiene una flecha unida al centro que va girando segun la direccion de este.

En el panel derecho hay mas indicadores de texto, que funcionan igual que el derecho.

Tambien estan tabuladas las cifras. Para tabular las cifras se hace un calculo del texto mas

largo y se ponen todas a continuacion. Esto hace necesario que se pongan dos bloques de texto

27

en vez de uno. La tabulacion es necesaria por las particularidades de OpenCv que hacen que la

funcion de anadir texto a una imagen no deje el mismo espacio para todos los caracteres. Por

otra parte ha puesto los indicadores que visualmente tenıan mayor coherencia y abreviados

de forma que fueran intuitivos.

4.5. Solucion de integracion con AerostackPara la integracion con Aerostack primero se ha estimado cual era la tarea concreta que

tenıa que cumplir dentro de este y despues definir donde tendrıa que integrarse. Despues de

realizar un prototipo se hizo una integracion de prueba. Se anadio una pestana a la humanmachine interface donde se emitian las imagenes transformadas. Se anadio un widget nuevo

a la interfaz y se anadio como pestana nueva. El widget creado respondıa a las senales de

recepcion de imagenes y al recibir senales desde el receptor de imagenes (subscripciones a

topics) de la human machine interface, estas senales mandaban la imagen para ser anadida

como imagen al widget acoplado en la pestana nueva de la human machine interface. Esta

integracion fue una prueba que termino de forma exitosa, pero hubo que hacerla de nuevo una

vez se decidio anadirlo como parte de la interfaz oficialmente. En este caso nuevo, la interfaz

debıa soportar dos widgets en vez de uno aunque con las mismas especificaciones. Para tra-

bajar con Aerostack y verificar su funcionamiento, hay que correr el proceso con aerostack

lanzado al completo. Esto implica a la human machine interface. Despues hay que conectar

el computador por wi-fi a un dron preparado con los sensores y la camara activados. Ası se

puede observar correctamente que la integracion esta funcionando y que se ha terminado a

nivel de procesos.

A nivel estetico siempre hay que afinar para que la combinacion de ambos software me-

jore y cumpla su funcion de aumento de la realidad o enriquecimiento de imagenes.

La interfaz human machine interface tiene tres partes 4.6: El panel de control, el panel de

Vehicle Dynamics y el tab manager. La camara superpuesta tenıa que poderse ver tanto en el

administrador de pestanas en grande, como en la parte de Vehicle Dynamics en sustitucion de

los datos que se representan ahı, es decir los datos de posicion y de inclinacion del vehiclo.

Por otra parte si queremos verla en grande podemos ir a la pestana del tab manager dedicada

a ello. Como son dos widgets separados no se utilizan de la misma manera, por lo que son

dos imagenes diferentes, como podemos ver en el area de programacion. Cada widget recibe

imagenes de un topic diferente para facilitar la lectura. Para crear los widgets se ha utilizado

la herramienta QtDesigner, 4.7 cuyo funcionamiento es bastante sencillo. La idea es crear

una ui, un objeto Widget que luego se vera anadido a la human machine interface, este objeto

tiene unas propiedadades que permiten modificarlo. Cada recepcion de imagen por el callback

de recepcion de imagenes es una orden a la ui para albergar una nueva imagen.

28

Figura 4.6: Integracion de la interfaz

Figura 4.7: Qt designer

29

Capıtulo 5

Validacion

Se han disenado para probar aspectos especıficos ası como el funcionamiento del sistema

de forma global. Ademas, el sistema ha de quedar operativo e integrado en la human machineinterface para su uso en casos reales. Es por ello que se requiere el mayor ajuste posible en

la version final.

En el caso de este programa el proceso de validacion ha tenido bastante peso pero ha

requerido en la mayorıa de los casos de comprobaciones humanas porque es un software de

representacion grafica y salvo las inspecciones del codigo y la depuracion en si, la mayorıa

de las verificaciones han sido realizadas examinando detenidamente las imagenes emitidas:

Para probar la funcionalidad del programa se han usado programas de emision y recep-

cion de imagenes en simulacion de la camara de un hipotetico vehıculo no tripulado y de

la interfaz donde se debe insertar. 7.2 Tambien se han utilizado archivos de vuelos realiza-

dos previamente que contienen los mensajes de la camara frontal y otros topics para tener

una mejor simulacion con datos reales. Finalmente tambien se han hecho pruebas de vuelo e

integracion con la human machine interface donde se confirmaban las demas pruebas.

5.1. Pruebas de funcionamiento del programaSe han realizado las siguientes pruebas dentro :

Comprobacion de la funcionalidad de recepcion y emision de imagen: Se verifica

mediante la emision de imagenes desde un programa emisor 7.2.2 7.2.1 y la visualiza-

cion 7.2.3. Estas pruebas se realizan al principio del desarrollo y son la base para las

demas.

Comprobacion de que la imagen emitida es modificable y se modifica segun loesperado: Es el siguiente paso, una vez conseguida la recepcion y emision correcta se

prueba a modificar la imagen emitida. Estas pruebas son fundamentales porque en un

principio los colores no se modificaban correctamente por las modificaciones realiza-

das. Podemos desglosar esta prueba en otras subpruebas:

30

• Comprobacion de la correcta representacion de los bloques de texto: Un

ejemplo, la funcion de OpenCv para poner texto no admite todos los caracteres

que podemos escribir en el teclado, por lo tanto que hay verificar que no existan

cambios no contemplados de numero de caracteres representados. Los numeros

negativos tienen que estar contemplados a la hora de representar numeros reales,

se ha comprobado en cada uno de los bloques de texto insertados que no existen

variaciones que descuadren a lo demas

• Comprobacion de color, tamano de los objetos: Aquı se verifica si el color de

los objetos dibujados es el color definido en los parametros. Un ejemplo, el indi-

cador de frames por segundo salıa en un color diferente del resto porque estaba

parametrizado de forma diferente al resto. Se verifica que el color del texto es el

adecuado en definitiva Los objetos ademas deben tener un tamano relativo a los

demas objetos, por ejemplo si dibujamos una circunferencia que toma una fracion

de la altura de la imagen como diametro, sus pıxeles deben coincidir con los de

un giro de un punto con el mismo centro y el mismo radio. Al igual con el texto,

debe poder comprobarse la homogeneidad de los tamanos de los textos. Se han

realizado alrededor de diez pruebas de este tipo por cada indicador o panel de

texto anadido (teniendo en cuenta ideas desechadas).

• Comprobacion del proceso de superposicion de imagenes: Esta comprobacion

se ha realizado cuatro veces. Se basa en comprobar la funcionalidad de superpo-

sicion de imagenes (overlayImage) 4.4. Primero al implementar la funcion habıa

que comprobar que la imagen de fondo se emitiera correctamente. Despues tras

realizar alguna transformacion o dibujo sobre la capa superior, se realiza la se-

gunda comprobacion de que la imagen se superpone sin ocultar o modificar la

imagen inferior mas que en lo establecido. Hubo que repetir este proceso cuando

se realizo una modificacion al codigo que emitıa dos imagenes diferentes con dos

overlays diferentes pero encima de la misma imagen.

• Comprobacion del cumplimiento de los estandares de la geometrıa en losindicadores: Estas pruebas se realizan conforme a las instrucciones del cliente y

las capacidades del sistema. Cada vez que se produce un nuevo prototipo el cliente

debe ver si la representacion le parece correcta (Si los parametros geometricos

le convencen). Ademas, debe comprobarse el rendimiento con valores simulados

para que coincida con la geometrıa u orden que el cliente establece como estandar.

Esta prueba es mas comun y se ha realizado con relativa frecuencia.

Comprobacion del tiempo y de la tasa de frames: Esta prueba esta relacionada con

el rendimiento, con el numero de imagenes recibidas y con temporizadores. Para esto se

utiliza una utilidad de medida de estadisticas interna y otra externa. Hay un parametro

entre las utilidades de ros que al definirlo a true publica un topic extra con estadisticas

de las transferencias de datos en tiempo real. Aparte en el propio codigo, se realiza

31

una estadıstica interna de el numero de frames en funcion del tiempo. Para verificarlo,

hay un texto representado directamente en el overlay que refleja esto. La idea es que la

tasa se mantenga constante y que coincida con la tasa de frames que queremos emitir.

Al respecto de esto, si el programa supera la duracion de 33 ms aproximadamente,

se produce retardo y el programa se vuelve inestable. Al respecto del tiempo como

tal, debe modificarse el indicador de tiempo del programa de forma constante para

confirmar la ausencia de retraso.

Comprobacion de entrada y representacion correcta de los datos recibidos pormensajes de los topics de ros subscritos: Esta es una verificacion en la que se utiliza

rostopic echo y la visualizacion directa de las imagenes emitidas 7.2.3. Primero se lan-

zan los procesos y en una consola se lanza el programa rostopic echo nombreDelTopic,

este programa emite en tiempo real el desglose en variables del mensaje transferido

al que se subscribe el programa. Debe coincidir con el mensaje emitido o al menos,

que el programa trate adecuadamente los datos. Con esto se comprueba, por ejemplo,

que mientras en las pruebas de funcionalidad de los indicadores se ve que funcionan,

aquı se comprueban con datos reales. En estas pruebas, realizadas con datos reales se

verifica ademas que el programa esta adaptado al tipo de datos que va a recibir y que

su representacion coincide con los estandares de visualizacion.

Comprobacion del posicionamiento correcto y estandar de los bloques de textoen los paneles derecho e izquierdo Para realizar esta comprobacion hay que verificar

que las cantidades a la derecha de cada texto esten tabuladas y alineadas en vertical.

Despues que la tabla al completo no ocupe el espacio de otros indicadores y objetos.

Esta tarea es bastante sencilla una vez se eliminan los iconos de la ecuacion puesto

que tienen sus propias medidas y no se escalan en la misma manera que el texto. Se

realizo al terminar el prototipo de paneles, puesto que hubo dos prototipos de paneles

desarrollados, se realizo dos veces.

Comprobacion del alineamiento y posicionamiento de los indicadores pertene-cientes al panel central En realidad es la misma prueba que la anterior pero teniendo

en cuenta que la geometrıa es diferente. En la version final los indicadores estan ali-

neados en el eje central de la imagen.

Comprobacion de cohesion de la interfaz completa Una vez terminadas las pruebas

anteriores con esta prueba hemos verificado que el tamano de la interfaz sea el adecuado

en conjunto y que los parametros geometricos de los paneles sean coherentes. Esto esta

ligado a la visualizacion final en la human machine interface sobretodo puesto que la

imagen que se representa en el pestana de mayor tamano no tiene los mismos requisitos

de visualizacion que la de menor tamano, hay indicadores que no se pueden distinguir

correctamente y textos que deben poder verse con mayor facilidad.

32

5.2. Pruebas de integracionProbar la integracion es el proceso final de verificacion final del proyecto. Se han disenado

pruebas para medir aspectos especıficos ası como el funcionamiento del sistema de forma

global. Ademas, el sistema ha de quedar operativo e integrado en la human machine interfacepara su uso en casos reales. Es por ello que se requiere el mayor ajuste posible en la version

final. Una vez creados los espacios donde se van a albergar la representacion de las imagenes

en la interfaz, se conecta con un dron via wi-fi, se inicializa el programa madre que ejecuta

todos los subprogramas que alberga la human machine interface y en paralelo se ejecuta

nuestro programa de generacion de overlay. Si las imagenes se representan con exito y en el

tiempo adecuado podemos concluir en que la integracion ha sido un exito.

5.3. MetricasLas imagenes del dron de pruebas tienen una resolucion de 640x360. Segun los calculos

de trafico que devuelve las estadisticas del topic de estadisticas de Ros, el volumen de image-

nes emitidas es de 55.44 Mb de media. Puesto que el programa emite y recibe 30 frames por

segundo por imagen se puede delimitar que cada frame de cada imagen ocupa 0,9240576 Mb

aproximadamente. Esto quiere decir que la conexion con el dron debe transmitir aproxima-

damente 27,72/4*3= 20.8 Mb de imagenes sin comprimir. Esta ultima operacion la tengo que

explicar, las imagenes recibidas no tienen 4 canales, sino 3, pero nosotros las podemos proce-

sar como si lo tuvieran cambiando la codificacion en la recepcion 4.4 . Como comprobacion

si dividimos esta cifra entre el numero de pıxeles:

55,44/(30 ∗ 2) = 0,924057,6 (5.1)

924057,6/(640 ∗ 360) = 4B (5.2)

Estos cuatro bytes corresponden a los valores de cada pıxel de 0-255 en los cuatro canales

(Blue, Green, Red, Alpha).

Para Las pruebas realizadas se ha utilizado un portatil con un procesador Intel(R) Co-

re(TM) i5 CPU M 520 2.40GHz de cuatro cores con 3,7 Gb de memoria RAM.

5.4. Resultado de las pruebasEl codigo del programa principal tiene alrededor de 480 lıneas mas 84 lneas en los in-

cludes. El codigo de los widgets de integracion y demas modificaciones a la human machineinterface tienen alrededor de 95 lıneas en total. En total se han realizado 50 pruebas funcio-

nales.

33

Los resultados de las pruebas funcionales han sido satisfactorios. Algunos estandares

geometricos son mejorables en tanto en cuando para que se adapten a otros parametros que

pudieran darse, funcionan correctamente. En cuanto a las pruebas de velocidad, el programa

cumple con bastante margen los limites establecidos en las pruebas aunque podrıa mejorarse

para ser mas ligero o rapido. La integracion se ha realizado de forma exitosa. Las metricas son

bastante buenas y dejan espacio a nuevas aplicaciones del programa que requieran mas coste

computacional. Las pruebas tanto mias como las del cliente, por decirlo de alguna manera,

en conjunto pueden dar este software como validado. En definitiva, el programa ha superado

las pruebas con exito.

Aparte, de todas las pruebas funcionales descritas anteriormente. Tambien se han hecho

metricas para estimar el coste computacional, tiempo, tamano en memoria, tasa de refresco

del proceso, tasa de frames, tiempo dedicado a cada operacion concreta, etc.

Segun los datos del monitorizador de procesos, ocupa de media 1 Gb de memoria virtual

(RAM) en ejecucion y un 60 %(± 5 %) de la CPU, cuando no procesa imagenes, es decir,

cuando no se emiten y esta en espera, la carga de la CPU es del 0 %. La carga media del sis-

tema no se ve significativamente afectada. Segun las metricas internas alrededor del 46 % del

tiempo de cada frame esta libre lo cual se traduce en 15 milisegundos de espacio disponible,

esta es la franja que delimita en la que podrıamos anadir calculos nuevos u otras operacio-

nes como aumentar utilizar imagenes de una camara con un resolucion mayor. Teniendo en

cuenta que tratan dos imagenes por frame es un dato bastante positivo.

34

Capıtulo 6

Conclusiones

6.1. Revision de los objetivosEn esta seccion se van a revisar los objetivos de este trabajo de final de grado y hacer una

valoracion sobre su cumplimiento. Los objetivos iniciales incluıan dos lıneas de trabajo, la

primera lınea era crear un configurador para las misiones de Aerostack aunque se descarto

finalmente. Respecto de la segunda lınea, la mejora de Aerostack para monitorizar el vuelo

estaba dividida en los siguientes objetivos:

Analizar las necesidades del software y los requerimientos: Se ha realizado una valo-

racion de algunas de las herramientas existentes para crear un HUD integrable con la

interfaz HMI. El estudio de las herramientas y tecnologias fue fundamental para crear

el software disenado. Las herramientas utilizadas nos han permitido cumplir correcta-

mente los requisitos. Ademas esta fase ha proporcionado una vision global del software

para el que se desarrolla esta herramienta.

Integrar vista de camara con parametros y acciones En esta fase se ha realizado el

diseno del hud. Al respecto de esto, las posibilidades que ofrecen las herramientas

de dibujo y manipulacion de matrices de imagen nos hay permitido crear un HUD

sin depender de importar graficos externos, esto probablemente haya ido en favor del

rendimiento.

Construir un Heads-Up Display En esta fase se han desarrollado un diseno especıfico

de HUD que representara de la mejor manera la informacion en tiempo real de los

vuelos de drones con Aerostack. Los requisitos de este HUD eran ser un complemento

a la informacion mas importante transmitida por la interfaz HMI y que transmitiera

dinamismo para reflejar los cambios de estado del dron. Los requisitos se han cumplido

y el resultado cumple su funcion.

Desarrollar prototipo Se ha completado una primera version de la herramienta de over-

lay de la camara del dron que implementa todos los requisitos establecidos en la fase

35

anterior. Este desarrollo incluye la creacion de una herramienta de visualizacion que

facilita el uso de Aerostack y que complementa el uso de otros modulos creados duran-

te su desarrollo. Esta herramienta ha sido creada gracias al lenguaje de programacion

C++, la librerıa OpenCv y al framework ROS.

Validar prototipo Se han realizado pruebas para esta fase final de desarrollo que com-

pletan el desarrollo con exito. Estas pruebas han facilitado el desarrollo y ademas han

servido para confirmar el correcto funcionamiento de la version final, simplificando y

mejorando la herramienta. La herramienta funciona correctamente junto con Aerostack

y en un plazo relativamente corto, formara parte integra de este.

Extraer conclusiones

Los requerimientos y necesidades del software estan cumplidos, su funcion esta cubierta y

las expectativas estan cubiertas. La integracion con los mensajes de ros y la human machi-ne interface esta correctamente implementada. El Heads-Up Display funciona correctamente

y cumple su funcion de dar informacion al operador de forma regular y no distorsionante.

El prototipo esta bastante logrado y puede realizar su funcion. Ademas, las pruebas de va-

lidacion confirman su utilidad. Puesto que en esta memoria he desarrollado extensamente

las particularidades de esto podrıa decir que tenemos conclusiones bastante interesantes y

sobretodo relevantes sobre el software.

6.2. Lıneas futurasEn un futuro, el programa podria ser modificado de varias maneras. Una modificacion

inmediata que podrıa hacerse es la paralelizacion de sus procesos y concretamente de la parte

de mayor coste computacional que es el proceso de realizar el overlay que ocupa alrededor

del 66 % del tiempo de ejecucion y si queremos mejorar la velocidad es la principal seccion a

atacar. Respecto a velocidad yo no tocarıa nada mas. Respecto a diseno, algunos indicadores

podrıan generalizarse para ampliar el tipo de casos que puedan representar. Por otra parte, si

hubiera otros objetos que se quisiera representar. Vease, indicadores de aruco. Podrıan imple-

mentarse formas de representacion de reconocimiento de objetos, por ejemplo de arucos que

se anadirian en el metodo que llama a todos metodos de dibujo del programa. Por otra parte,

este programa no creo que tenga mucho mas desarrollo puesto que esta bastante encorsetado,

pero de todas maneras hay multiples opciones que no se han explotado como la variedad

cromatica, el reconocimiento de contornos, etc. Me refiero a que OpenCv es una librerıa con

muchas operaciones que probablemente no llegue a utilizar o conocer y que pueden llevar a

nuevas herramientas mejores que pueden ayudar a tener una mayor calidad de programacion.

36

Capıtulo 7

Anexos

7.1. La funcion linspaceEsta funcion es original de los lenguajes de computacion cientifica matlab o las librerıas

aplicadas a ello de python como numpy o scipy. La funcion linspace toma como parametro

dos numeros y el numero de paso , y devuelve un vector de numeros linearmente espaciados.

Aunque es una idea muy sencilla y es muy facil de implementar, los usos posibles de esta

funcion son muy interesantes. El primer uso que le dı en este trabajo fue el de un limitador

de frames, la idea inicial era anadir cierto retardo midiendo la duracion de los calculos y

anadiendo esperas. Esta solucion no es util puesto que el programa acaba teniendo retraso y

es inestable. La idea es recibir tantas imagenes y emitir otras tantas, pero sin ello provocar

retrasos ni falsear los resultados. Tras una busqueda de formas estadisticamente sencillas de

repartir equidistantemente los resultados acabe recordando funciones que habıamos utilizado

durante la carrera, puesto que mi carrera esta muy focalizada en la computacion cientifica.

Para ello surgio la idea de implementar linspace en C++, que no era muy costosa y daba bue-

nos resultados. Se hacıa una lista de frames a publicar y si estaba en la lista se publicaba el

frame y se esperaba a que coincidiera el siguiente con el de la lista. Como estamos transmi-

tiendo imagenes y no videos, se quedan las imagenes hasta que las sustituyes por otra nueva,

por lo tanto problema resuelto. Esta funcionalidad esta disponible solo que ya no se utiliza.

La segunda utilidad para la que he utilizado linspace es para hacer las escalas del indicador

de pitch. Ası hace una lista con los valores intermedios que debe tener la rueda del pitch

mientras esta en transicion.

37

7.2. Programas utilizados en las simulaciones

7.2.1. Video Stream OpenCvEste programa es un paquete catkin multiusos que permite emitir multiples tipos de feed.

Desde videos, emisiones web, etc. Es muy util cuando necesitas feed de imagenes y no dis-

pones de un archivo rosbag para trabajar. Durante la mayoria del desarrollo lo he estado

utilizando aunque una vez tuve a mi disposicion un archivo rosbag, lo deje de utilizar. Para

anadir un video al feed, simplemente hay que darle una ruta al launcher de video (pues tiene

un launcher para cada medio) de Video Stream OpenCv y despues conectar con el topic que

emite.

7.2.2. RosbagRosbag es una utilidad de ros que sirve para grabar en archivo toda la informacion emitida

por los topics durante su ejecucion. Despues este archivo puede ser reproducido y reemite

toda esa informacion capturada como si estuviera realizandose en ese momento. Mediante un

rosbag, tuve por primera vez, informacion de inclinacion y de posicion del vuelo de un dron

de forma simulada pero me permitia hacer pruebas de subscripcion.

7.2.3. OpenCv imshowEsta utilidad es una funcion de OpenCv que emite la imagen en una ventana de visualiza-

cion de imagenes. Tiene varias maneras de interactuar con ella puesto que acepta recepcion

de teclas y puede controlar el flujo del programa si es necesario. Sirve para ver la informacion

que se esta publicando a los topics de salida del programa. Puede llegar a ser muy costosa

computacionalmente y a consumir mucha memoria y procesamiento. Recomiendo hacer las

mediciones de metricas y pruebas de integracion sin estas funciones. Tener en cuenta que

emite una ventana flotante, que si le aumentamos el tamano puede llegar a ralentizar el pro-

grama de forma importante.

7.2.4. Creacion de bordes con OpenCvEn los planteamientos iniciales del desarrollo, se planeaba una forma de que los graficos

fueran legibles sin esfuerzo por el ojo humano en cualquier situacion de iluminacion. Hubo

mucha investigacion al respecto porque es algo complicado de hacer bien, el principal proble-

ma es que la librerıa de OpenCv no da ninguna facilidad sobre como hacerlo, hay que conocer

bien la librerıa para saber como utilizarla, es decir, que la curva de aprendizaje es bastante

alta en mi opinion. Inicialmente la propuesta era anadir borde a los texto en las 8 direcciones.

38

Figura 7.1:

Vecinos/Conectividad

de pıxeles

La manera teorica de hacerlo era anadir texto alrededor en los ve-

cinos del pıxel donde se insertarıan los textos. En cambio, a la hora

de aplcarlo, era poco practico porque la manera de hacerlo era po-

niendo 9 veces el mismo texto sobre el overlay, esto exigıa un gran

coste de procesamiento: Se podıan llegar a ejecutar mas de 80 ve-

ces el metodo de anadir texto cada frame. El primer acercamiento a

una mejor solucion era eliminar los textos en horizontal y vertical,

los resultados eran ligeramente peores en cuando a presentacion,

pero el rendimiento era mucho mejor aunque seguı siendo una op-

cion muy poco practica. Tras una investigacion sobre metodos de OpenCv llego la solucion

mas adecuada para el caso de que quisieramos poner bordes a objetos utilizando OpenCv.

He decir que es una librerıa muy potente y con una curva de aprendizaje bastante importante

para hacer operaciones avanzadas, pero este caso era el caso mas basico.

Analisis de contornos

(a) Original image (b) After Canny edge detection

Figura 7.2: Deteccion de ejes por algoritmo Canny

Aquı es donde llegamos a una solucion muy interesante con muchas aplicaciones y de

gran interes en robotica, que es el analisis de contornos. El analisis sobre contornos median-

te determinados algoritmos forma parte de la vision artificial, que es una aplicacion de la

robotica asociada al reconocimiento de patrones de vision. En nuestro caso lo que hacemos

es ejecutar la deteccion de bordes con el algoritmo de Canny ( John F. Canny, 1986) sobre

la imagen a superponer. Despues, clasificarlos con una funcion de OpenCv que encuentra

los contornos (findContours) y finalmente dibujarlos. Como vemos en la figura anterior, el

resultado es bastante bueno y dibuja las partes tanto exteriores y agujeros de los objetos.

39

Aquı es cuando queremos hilar fino, la deteccion de contornos varıa segun la conectivi-

dad de las componentes. En la librerıa de OpenCv todas las funciones de dibujo (de lıneas,

insercion de texto, figuras geometricas, etc) tienen un argumento para especificar el tipo de

lınea que desea usar. Normalmente no sabrıamos para que sirve este argumento aun sabiendo

lo que es. Me explico, si no trabajas con funciones en las que no sea solamente una cuestion

estetica no te vas a dar cuenta de su relevancia.

Como esta explicado en la documentacion de la Api de OpenCv: Para las lıneas no antiali-

sadas con coordenadas enteras, para lıneas 4 y 8 conexas se usa el algoritmo de Bresenham.

Las lıneas anchas se dibujan con extremos redondos. Las lıneas antialisadas se dibujan con

filtro Gaussiano. En topologıa digital se aprende que dos puntos son 8-adyacentes si son dis-

tintos y sus coordenadas difieren a lo sumo en una unidad,y 4-adyacentes si son 8-adyacentes

y difieren a lo sumo en una coordenada.

Por el Teorema de la Curva de Jordan:

1. Toda curva cerrada simple del plano divide al plano en dos componentes conexas disjuntasque tienen a la curva como frontera comun. Una de estas componentes esta acotada (elinterior de la curva) y la otra es no acotada y se le llama exterior.

En este teorema se fundamenta nuestro algoritmo de deteccion de bordes. Un ejemplo de

aplicacion de este teorema son los algoritmos de deteccion de bordes es la teledeteccion que

analiza las imagenes de satelite para obtener informacion de terreno de forma rapida, eficaz,

barata y fiable.

En esta imagen se puede ver nuestro detector de inclinaciones con sus contornos desglo-

sados. Estamos utilizando lınea gruesa antialisada lo que en nuestro caso se puede explicar

como, tomando ejemplo de lıneas de un pıxel de grosor, que es conexo a todos los vecinos en

una matriz de 5x5 alrededor del pıxel. Al contrario los otros algoritmos solo garantizan las

lıneas que sean conexas a sus vecinos en la matriz de 3x3 alrededor. Por eso, una diagonal

puede ser detectada incorrectamente como contorno y es necesario usar lıneas antialisadas.

Por las imperfecciones de la imagen digital, salen mas contornos de los esperables, si cam-

biasemos el tipo de lınea a lınea 8 conexa saldrıan muchos contornos no relevantes como

puntos casi imperceptibles. Como ultimo detalle que anadir, los contornos pueden ser orga-

nizarse en jerarquıas de padres e hijos de anterior y siguiente, lo cual hace diferencias que

nos permitirıan clasificarlas. Como se puede ver en la figura anterior. Hemos coloreado las

interiores de colores diferentes y las exteriores de otro color para poder visualizarlo.

Finalizando este tema, esta idea fue desechada al no ser practica y gastar demasiado tiem-

po de procesamiento. Ademas, los resultados no eran perfectos y dependıan de la distribucion

de los pıxeles. Esto hacıa que no fuera del todo determinista. Consumıa ademas un 33 % del

tiempo disponible para procesamiento, en la actualidad el programa no podrıa soportar esa

carga extra.

40

Figura 7.3: Deteccion y dibujo de contornos

41

Bibliografıa

[1] J.L. Sanchez-Lopez, M. Molina, H. Bavle, C. Sampedro, R. A. Suarez-Fernandez, P.

Campoy. (2017). A Multi-Layered Component-Based Approach for the Development of

Aerial Robotic Systems: The Aerostack Framework. Journal of Intelligent & Robotic

Systems, 1-27.

[2] J. L. Sanchez-Lopez, R. A. Suarez-Fernandez, H. Bavle, C. Sampedro, M. Molina, J.

Pestana, P. Campoy (2016): AEROSTACK: An Architecture and Open-Source Software

Framework for Aerial Robotics. ICUAS 2016, Arlington, USA.

[3] OpenCV library [Online] http://code.opencv.org.

[4] Willow Garage. Robot Operating System [Online] http://www.ros.org/wiki/

[5] Anatoly Baksheev, Kirill Kornyakov, Victor Eruhimov in Communications of the ACM,

June 2012 Real-time computer vision with OpenCV (pdf) Kari Pulli (NVIDIA)

[6] The OpenCV Library Gary Bradski in Dr. Dobbs Journal, 2000

[7] The aerostack wiki.[Online] https://github.com/Vision4UAV/Aerostack/wiki

[8] Aerostack wiki. Human Machine Interface.[Online]

https://github.com/Vision4UAV/Aerostack/wiki/Human-Machine-Interface

[9] Michael Jepson, 2012. Overlaying transparent images in OpenCv

http://jepsonsblog.blogspot.com.es/2012/10/overlay-transparent-image-in-opencv.html

[10] Valencia Laray, Carlos (2017): Interfaz grafica de usuario para configuracion de mi-

siones de vehıculos aereos no tripulados”. Trabajo Fin de Grado. ETS de Ingenieros

Informaticos, Universidad Politecnica de Madrid.

42

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Mon Jul 03 20:55:27 CEST 2017

Emisor delCertificado

EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe Signature)