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
[email protected], 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)
Top Related