Академический Документы
Профессиональный Документы
Культура Документы
Director
Pablo González Nalda
Septiembre de 2015
Copyright © 2015 Daniel Laguna Soto.
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.3 or any later
version published by the Free Software Foundation; with no Invariant Sections,
no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is
included in the section entitled “GNU Free Documentation License”.
Agradecimientos
Gracias a mi madre, por apoyarme en todos los momentos difíciles de mi vida, eres
increíble y se que eres capaz de todo con tal de que seamos felices. Para mi siempre seras
un modelo a seguir.
Gracias a mi hermana, aunque te cueste demostrarlo, se que siempre vas a estar ahí a
mi lado.
Gracias a Fran, mi amigo de la infancia, gracias por estar ahí siempre que te he
pedido ayuda. Te deseo buena suerte en lo que te queda de carrera, estoy seguro de que
la terminarás con buenos resultados.
Gracias a Diego, mi compañero de trabajos, sin ti todos estos años no hubiesen sido
lo mismo. Me alegro de haberte conocido.
iii
iv AGRADECIMIENTOS
Gracias a Iban, por acompañarme todo este tiempo en la carrera con tan buenos (y
frikis) momentos.
Gracias a Pablo y Alberto por aquellas conversaciones matutinas camino a Vitoria.
Las voy a echar de menos.
Gracias a mis amigos, pues no le habéis dado importancia al hecho de que no os haya
dedicado el tiempo que os merecéis durante el desarrollo de este proyecto.
Quiero finalizar agradeciendo a mi familia, sobre todo a mi abuela gracias por todo lo
que has hecho y haces por nosotros.
Mi director de trabajo de fin de grado me ha movido este agradecimientos al final
porque no podía estar antes de su familia y amigos. Quiero dar las gracias a Pablo, mi
tutor de proyecto, por todo ese tiempo que me has dedicado cuando te he pedido y más
aún por todo aquel tiempo que no te he pedido. Gracias por estar ahí todo este tiempo,
sobre todo en aquellas ocasiones en las que he estado perdido y has sabido guiarme. Este
proyecto ha sido una experiencia inolvidable.
Índice general
Agradecimientos III
Índice general V
Índice de figuras XI
Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi
v
vi ÍNDICE GENERAL
2 Viabilidad 7
2.1. Requisitos funcionales del trabajo . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Planificación del tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Estructura de descomposición del trabajo . . . . . . . . . . . . . . . 8
2.2.2. Fases, tareas y entregables . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Entregables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.4. Agenda del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.5. Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3. Gestión de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4. Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.1. Explicación de los riesgos y plan de contingencia . . . . . . . . . . . 25
3 Conceptos generales 31
3.1. Visión por computador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2. Modelo de un sistema de visión por computador . . . . . . . . . . . . . . . 32
3.2.1. Modelo Pinhole . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2. Cámara CCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3. Calibración de la cámara . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3. Estereoscopia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1. Adquisición de imágenes . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2. Modelo de las cámaras . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2.1. Geometría epipolar . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2.2. Definición de disparidad y triangulación . . . . . . . . . . 39
3.3.3. Elección de características . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.4. Búsqueda de correspondencias o matching . . . . . . . . . . . . . . 41
3.3.5. Determinación de la profundidad . . . . . . . . . . . . . . . . . . . 42
3.3.6. Interpolación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4. Algoritmos propuestos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.1. Correspondencia densa local. BM . . . . . . . . . . . . . . . . . . . 43
ÍNDICE GENERAL vii
4 Tecnologías y herramientas 45
4.1. OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2. Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Características importantes de ROS . . . . . . . . . . . . . . . . . . 46
4.2.2. Conceptos básicos de ROS . . . . . . . . . . . . . . . . . . . . . . . 46
4.3. Raspberry Pi 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Sistema estereoscópico 51
5.1. Construcción del sistema estereoscópico . . . . . . . . . . . . . . . . . . . . 51
5.2. Calibrado y Rectificado del sistema estereoscópico . . . . . . . . . . . . . 53
8 Desviación en la planificación 77
V Apéndices y bibliografía 83
A Manual de Usuario 85
A.1. Requisitos mínimos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A.2. Dónde descargarlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.3. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.4. Como compilar el Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.5. Cómo utilizar la librería SCalibData . . . . . . . . . . . . . . . . . . . . . 87
A.6. Ejecución del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.6.1. Software de calibración del sistema estéreo . . . . . . . . . . . . . . 88
A.6.2. Software de cálculo de disparidad y estimación de distancia . . . . . 89
A.6.3. Software de captura de cámaras . . . . . . . . . . . . . . . . . . . . 91
A.6.4. Software algoritmo SURF . . . . . . . . . . . . . . . . . . . . . . . 91
Appendices 85
B Pliego de condiciones 93
B.1. Condiciones de hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.2. Condiciones de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
B.3. Condiciones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
D Rosberry Pi 97
D.1. Pre-requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
D.1.1. Añadir los repositorios de ROS . . . . . . . . . . . . . . . . . . . . 97
D.1.2. Instalar dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . 98
D.1.3. Inicializar rosdep . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
D.2. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
D.2.1. Crear el espacio de trabajo de catkin . . . . . . . . . . . . . . . . . 98
D.2.2. Resolver dependencias . . . . . . . . . . . . . . . . . . . . . . . . . 99
D.2.2.1. Dependencias no disponibles en los repositorios de Jessie . 99
D.2.2.2. Resolviendo las dependencias con rosdep . . . . . . . . . . 100
D.2.3. Compilando el espacio de trabajo catkin . . . . . . . . . . . . . . . 100
4. MODIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5. COMBINING DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6. COLLECTIONS OF DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . 112
7. AGGREGATION WITH INDEPENDENT WORKS . . . . . . . . . . . . . . 112
8. TRANSLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10. FUTURE REVISIONS OF THIS LICENSE . . . . . . . . . . . . . . . . . . 114
11. RELICENSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Bibliografía 117
Índice de figuras
xi
xii Índice de figuras
xiii
xiv Índice de tablas
Resumen
En este trabajo se lleva a cabo el diseño y la implementación de un sistema de visión
estéreo que permite la estimación de distancias a los objetos que se encuentran en la escena.
El objetivo es hacer una primera aproximación a estas funcionalidades y tecnologías para
servir de base a futuros trabajos de visión artificial en sistemas autónomos. Para ello se
observan la precisión y velocidad de varios algoritmos para dos plataformas informáticas
y se busca la mejor solución.
Se han comparado dos algoritmos para conocer su precisión en el cálculo de distan-
cias para unos recursos computacionales determinados, es decir, la mejor relación entre
completitud de mapa de disparidad y velocidad de ejecución. Se ha medido el error en
situaciones de luz natural y en interiores. Asimismo, se ha analizado el rendimiento y
paralelizado para aprovechar la limitada potencia de un ordenador de placa única (Single
xv
xvi RESUMEN Y ORGANIZACIÓN DE LA MEMORIA
Abstract
This project develops the design and implementation of a stereo vision system that
estimates distances to the objects found at the scene. The purpose is to make a first
approach to these features and technologies and provide a basis for future works on auto-
nomous machine vision systems. To fulfill these goals, the accuracy and speed of several
algorithms for two computing platforms are evaluated.
A comparison of two algorithms are made to know the precision of the distance esti-
mation for a certain computational resources, meaning that, try to found the best ratio
between completeness of disparity map and speed of execution. The error has been mea-
sured in situations of natural light and indoors. It has also been analyzed the performance
of both systems and parallelized to take advantage of the limited power of a single board
computer such as the Raspberry Pi 2. For reference has taken a PC.
The system has been built using low-cost components: two webcams, one PC and a one
Raspberry Pi 2. All software has been developed using C++ programming language and
the computer vision library OpenCV. In addition, the correspondence matching software
has been parallelized using OpenMP.
The developed software consists mainly of an application that allow us the proper
calibration of the stereo system and various applications with different correspondence
matching algorithms, which are responsible of generating disparity maps and estimate
the distance to the principal objects of the scene.
Organización
La primera parte de esta memoria la forma el capítulo en el que se presenta el alcance
del proyecto, donde se hace una descripción del mismo, se enuncian los objetivos que debe
ORGANIZACIÓN xvii
1
Descripción, Motivación y Objetivos del
proyecto
1.1. Descripción
En este trabajo se desarrolla un sistema de estereoscopia utilizando recursos materia-
les de bajo coste, principalmente dos cámaras web y una Raspberry Pi 2. Este sistema
permite realizar una comparación entre varios algoritmos de búsqueda de corresponden-
cias, encontrar las ventajas de cada uno de los dos métodos de estimación de distancia y
recoger información de las pruebas de rendimiento realizadas con el software desarrollado
en versión serie y paralela. Estas pruebas de rendimiento han sido probadas tanto en una
plataforma x86 (Intel Core i5 750) y en ARM (ARMv7 Cortex-A7) con el objetivo de
evaluar las posibilidades de un sistem similar en el mundo de La Internet de las Cosas
(IoT) o en el de los vehículos no tripulados (drones).
En resumen y como resultado global se obtiene una panorámica, un análisis de las
posibilidades que proporciona un sistema sencillo y de bajo coste para futuros proyectos
3
4 CAPÍTULO 1. DESCRIPCIÓN, MOTIVACIÓN Y OBJETIVOS DEL PROYECTO
y trabajos.
Para el funcionamiento del sistema estereoscópico se ha desarrollado diversos progra-
mas de los que se destacan:
1.2. Objetivos
El objetivo principal de este proyecto es analizar las diferentes posibilidades que nos
proporciona un sistema de visión artificial de bajo coste. Con dos cámaras web y una SBC
(Single Board Computer, Ordenador de Placa Única) se puede conseguir información fiable
de una escena tridimensional a partir de información bidimensional utilizando para ello
técnicas y algoritmos de visión estéreo.
Como el software va a ser ejecutado en un SBC, un sistema embebido ARM (Raspberry
Pi 2) cuya potencia es bastante menor comparada a la de un equipo de escritorio, se
requiere que el software este lo más optimizado posible. Por ello en el trabajo siempre se
analizan los métodos para obtener la mejor relación entre información fiable y rendimiento.
Este trabajo tiene también como objetivo que pueda ser usado como base para otros
proyectos sobre visión por computador. De hecho, las herramientas usadas en este proyecto
son todas libres (C++, OpenCV, OpenMP, LATEX, GNU/Linux, Raspberry Pi).
1.3. Motivación
Empecé a hacer este proyecto a propuesta del director del mismo, Pablo González
Nalda. La idea inicial era implementar este proyecto en paralelo a otro proyecto que él
mismo está desarrollando junto con otros profesores del centro. Este proyecto se comenzó
a desarrollar debido a la curiosidad que sentía el desarrollador sobre el mundo de la
visión artificial y la reconstrucción de espacios en tres dimensiones mediante un sistema
de visión estereoscópica. Además este proyecto surge del auge que se vive actualmente
con los drones tripulados y sobre todo los no tripulados.
1.3. MOTIVACIÓN 5
Este trabajo se encuadra en las dos primeras fases de las que componen la Inteligencia
Artificial en la robótica clásica, las correspondientes a la adquisición de información del
entorno y la creación de un modelo. Posteriormente se crea un plan de actuación y se
lleva a cabo. Estas fases se resumen en la expresión SMPA (Sense-Model-Plan-Act). En
un primer análisis, antes de conocer técnicas de visión estéreo, se pensó en usar un sensor
capaz de obtener información de la escena. Se pensó en crear un telémetro como candidato
a sensor (Sense), pero debido a su poca utilidad, ya que solo obtendría información de
un único punto, se desechó la idea por otra, que consistía en una cámara en conjunto con
un sensor 3D. Con la información conseguida del sensor, se crearía un modelo de mundo
(Model) utilizando para ello la librería OpenCV. Una vez creado un modelo sólo quedaría
planificar y actuar. Para ello el director del proyecto sugirió utilizar ROS (Robot Operating
System) que nos ayudaría a cumplir estas dos ultimas partes (Plan-Act) del paradigma
SMPA y unirlas a las demás gracias a su modularidad para transmitir información entre
diferentes módulos del sistema.
En un segundo análisis y conforme el desarrollador iba entrando en materia se aprendie-
ron técnicas y algoritmos de visión por computador y estéreo. Debido a que la universidad
no disponía en esos momentos de un sensor 3D, se optó por descartar esta idea, utilizando
como sustituto dos cámaras que formarían el sistema estereoscópico usado.
Una de las grandes motivaciones de este trabajo es hacer un desarrollo de software
libre, utilizando para ello el lenguaje de programación C++. Debido a que el lenguaje
al que estaba acostumbrado el desarrollador era JAVA, el aprendizaje de C++ no fue
muy complicado. Al usarse CMake como build system los ficheros fuentes pueden ser
compilados en múltiples sistemas operativos y el sistema es muy portable.
Capítulo
2
Viabilidad
En este capítulo se analizan los requisitos del trabajo para cumplir los objetivos y
se define una planificación de los recursos humanos, de tiempo y económicos. Además se
estudian los riesgos que pueden dificultar, retrasar o impedir la realización de los objetivos.
7
8 CAPÍTULO 2. VIABILIDAD
9
10
Figura 2.2: Estructura de Descomposición del Trabajo 2
CAPÍTULO 2. VIABILIDAD
2.2. PLANIFICACIÓN DEL TIEMPO 11
Número: 0.1.1.
Nombre: Objetivos de proyecto.
Descripción: Hacer un análisis previo para determinar los objetivos que se inten-
tarán alcanzar con este proyecto.
Trabajo estimado: 8 horas.
Número: 0.1.2.
Nombre: Definir requisitos del proyecto.
Descripción: Establecer los requisitos funcionales que abordará el proyecto.
Trabajo estimado: 5 horas.
2.2. PLANIFICACIÓN DEL TIEMPO 13
Número: 0.2.1.
Nombre: Formación C/C++.
Descripción: Adquirir los conocimientos necesarios para utilizar el lenguaje
C/C++.
Trabajo estimado: 8 horas.
Número: 0.2.2.
Nombre: Formación CMake.
Descripción: Realizar un estudio exhaustivo de la herramienta CMake para poder
compilar el software.
Trabajo estimado: 7 horas.
Número: 0.2.3.
Nombre: Formación OpenCV.
Descripción: Realizar un estudio exhaustivo de la librería OpenCV necesaria para
el desarrollo del trabajo.
Trabajo estimado: 15 horas.
Número: 0.2.4.
Nombre: Formación API V4L2.
Descripción: Familiarizarse con la API V4L2 necesaria para el manejo de las
cámaras en Linux.
Trabajo estimado: 10 horas.
Número: 0.2.5.
Nombre: Formación ROS.
Descripción: Aprender a utilizar el framework que se utilizará para implementar
el software en el Robot.
Trabajo estimado: 15 horas.
14 CAPÍTULO 2. VIABILIDAD
Número: 0.2.6.
Nombre: Formación visión por computador.
Descripción: Formación básica en técnicas de visión por computador.
Trabajo estimado: 25 horas.
Número: 0.2.7.
Nombre: Formación Latex.
Descripción: Familiarizarse con Latex para escribir la memoria.
Trabajo estimado: 5 horas.
Número: 0.3.1.
Nombre: Instalación en el PC.
Descripción: Instalación de las herramientas necesarias para el desarrollo del
proyecto en el PC.
Trabajo estimado: 2 horas.
Número: 0.3.2.
Nombre: Instalación en la Raspberry Pi 2.
Descripción: Instalación de las herramientas necesarias para el desarrollo del
proyecto en la Raspberry Pi 2.
Trabajo estimado: 4 horas.
Número: 0.4.
Nombre: Aprendizaje con maduración del proyecto.
Descripción: Como no se sabe exactamente como van a ser abordadas las si-
guientes tareas, se crea esta. Pues lo mas seguro, es que mas adelante surgirán nuevas
tareas.
Trabajo estimado: 0 horas.
2.2. PLANIFICACIÓN DEL TIEMPO 15
Número: 0.5.1.
Nombre: Diseño.
Descripción: Diseño del software necesario para calibrar la cámara.
Trabajo estimado: 7 horas.
Número: 0.5.2.
Nombre: Implementación.
Descripción: Implementación del software encargado de calibrar la cámara.
Trabajo estimado: 12 horas.
Número: 0.5.3.1.
Nombre: Comprobar la eficacia de la calibración.
Descripción: Se realizarán pruebas para determinar la eficacia de la calibración.
Trabajo estimado: 3 horas.
Número: 0.5.4.
Nombre: Solución de errores.
Descripción: Se solucionaran los errores que surjan en el software de calibración.
Trabajo estimado: 1 hora.
Número: 0.6.1.
Nombre: Diseño.
Descripción: Diseño del software encargado de detectar los objetos y estimar las
distancias.
Trabajo estimado: 15 horas.
Número: 0.6.2.
Nombre: Implementación.
16 CAPÍTULO 2. VIABILIDAD
Número: 0.6.3.1.
Nombre: Realizar pruebas detección de objetos.
Descripción: Se realizarán pruebas para determinar la función de detección de
objetos.
Trabajo estimado: 3 horas.
Número: 0.6.3.2.
Nombre: Realizar pruebas de estimación de distancia.
Descripción: Se realizarán pruebas que evaluarán el error de la detección de
objetos.
Trabajo estimado: 3 horas.
Número: 0.6.3.3.
Nombre: Realizar pruebas de rendimiento. PC y RPI2.
Descripción: Se evaluará el rendimiento del programa tanto en el PC, como en
la Raspberry Pi 2.
Trabajo estimado: 6 horas.
Número: 0.6.4.
Nombre: Solución de errores.
Descripción: Corrección de errores que surjan en el software de detección de
objetos y estimación de distancias.
Trabajo estimado: 1 hora.
Número: 0.7.1.
Nombre: Creación paquete de ROS con el software.
2.2. PLANIFICACIÓN DEL TIEMPO 17
Número: 0.7.2.
Nombre: Modularizar el software en nodos.
Descripción: Se separará en módulos las funcionalidades del software desarrolla-
do, con la idea de intentar utilizarlo de forma distribuida.
Trabajo estimado: 10 horas.
Número: 0.8.
Nombre: Montaje en el robot.
Descripción: Montaje del trabajo en el robot.
Trabajo estimado: 20 horas.
Número: 0.9.1.
Nombre: Manual técnico.
Descripción: Redactar un manual que explique el proceso seguido para el desa-
rrollo del proyecto.
Trabajo estimado: 65 horas.
Número: 0.9.2.
Nombre: Manual de usuario.
Descripción: Redactar un manual detallado que explique al usuario como utilizar
el software de este trabajo.
Trabajo estimado: 14 horas.
Número: 0.9.3.
Nombre: Elaboración del resumen de la memoria.
Descripción: Elaborar el resumen necesario de la memoria.
Trabajo estimado: 2 horas.
18 CAPÍTULO 2. VIABILIDAD
Número: 0.9.4.
Nombre: Elaboración de la presentación.
Descripción: Elaborar las diapositivas necesarias para la defensa del proyecto.
Trabajo estimado: 4 horas.
Número: 0.9.5.
Nombre: Preparación de la defensa.
Descripción: Realizar ensayos previos a la presentación para conseguir una buena
exposición.
Trabajo estimado: 4 horas.
Número: 0.10.
Nombre: Entrega de la documentación.
Descripción: Hito.
Trabajo estimado: 0 horas.
2.2.3. Entregables
Al finalizar el proyecto se entregará el software desarrollado junto con un manual
técnico y de uso que explicará de forma sencilla y concisa la compilación y utilización del
trabajo.
Fecha Evento
1 de Enero Año nuevo
6 de Enero Día de Reyes
19 de Marzo San José
2 de Abril Jueves Santo
3 de Abril Viernes Santo
6 de Abril Lunes de Pascua
28 de Abril San Prudencio
1 de Mayo Día del trabajo
25 de Julio Santiago Apostol
5 de Agosto Virgen Blanca
15 de Agosto Asunción de la Virgen
12 de Octubre Fiesta Nacional de España
8 de Diciembre Inmaculada Concepción
25 de Diciembre Navidad
es totalmente compatible con las clases de universidad a las que tiene que acudir el desa-
rrollador. Por otra parte, se ha dejado margen hasta el Martes 1 de Septiembre en caso
de requerir más tiempo del previsto para finalizar el trabajo.
Se ha estimado lo siguiente:
El diagrama de Gantt 2.3 y 2.4 expone el tiempo de dedicación previsto para las diferentes tareas a lo largo del tiempo total determinado
para el proyecto.
CAPÍTULO 2. VIABILIDAD
Figura 2.3: Diagrama de Gantt 1
2.2. PLANIFICACIÓN DEL TIEMPO
Figura 2.4: Diagrama de Gantt 2
21
22 CAPÍTULO 2. VIABILIDAD
2.3.1. Presupuesto
Para realizar la estimación del presupuesto se han tenido en cuenta los datos que
aparecen de la tabla 2.2 a 2.8. En ellas se indica lo que cobran los recursos humanos,
que tienen una tasa estándar por hora correspondiente a la de un analista programador.
Los recursos materiales se consideran con un coste por uso de 1,25 € en concepto de luz
ADSL/Fibra óptica y otros gastos que se cobran independiente del tiempo de uso excepto
la Raspberry Pi 2 y las camaras que tendrán un coste de 1 €.
Los datos de tiempo y trabajo han sido extraídos de las siguientes vistas de Micro-
soft Project. En la realización de este presupuesto se tiene en cuenta tanto los recursos
materiales como las licencias de software necesarias para el desarrollo del trabajo.
Para el cálculo de las amortizaciones se ha considerado un tiempo de amortización
de 3 años. El cálculo del coste unitario de amortización es la división entre el cos-
te unitario y el tiempo de amortización. Se considera el tiempo de amortización como
3 años × 200 días laborables × 8 horas = 4800 horas.
Concepto Coste
Daniel Laguna 17,57 €/h
Concepto Coste
PC Sobremesa 550,20 €
PC Portátil 512,71 €
Raspberry Pi 2 39,99 €
Logitech C310 40,00 €
Logitech C310 40,00 €
Tabla de madera 1,50 €
Cinta americana 1,00 €
Concepto Trabajo (h) Trabajo horas extra Coste Coste horas extra Importe
Daniel Laguna 300 0 17,57 €/h 0 5271,00 €
Total 300 0 17,57 €/h 0 5271,00 €
Concepto Coste unitario Tiempo de amortización Coste unitario de amortización Tiempo de uso Importe
PC Sobremesa 550,20 € 4800 horas 0,114625 € 89 h 10,20 €
PC Portatil 512,51 € 4800 horas 0,106773 € 196 h 20,93 €
Raspberry Pi 2 39,99 € 4800 horas 0,008331 € 30 h 0,25 €
Logitech C310 40,00 € 4800 horas 0,008333 € 60 h 0,50 €
Logitech C310 40,00 € 4800 horas 0,008333 € 60 h 0,50 €
Windows 7 Professional N 125,00 € 4800 horas 0,026042 € 25 h 0,65 €
Microsoft Project 2013 1.369,00 € 4800 horas 0,285208 € 16 h 4,56 €
Chart Pro 0,00 € 4800 horas 0,000000 € 10 h 0,00 €
Manjaro Linux 0,00 € 4800 horas 0,000000 € 130 h 0,00 €
Arch Linux 0,00 € 4800 horas 0,000000 € 130 h 0,00 €
Vim 0,00 € 4800 horas 0,000000 € 60 h 0,00 €
Raspbian 0,00 € 4800 horas 0,000000 € 30 h 0,00 €
Librería OpenCV 0,00 € 4800 horas 0,000000 € 50 h 0,00 €
ROS 0,00 € 4800 horas 0,000000 € 15 h 0,00 €
Gimp 0,00 € 4800 horas 0,000000 € 3h 0,00 €
Total 37,59 €
Concepto Importe
R.T. 5271,00 €
R.M. 52,50 €
Costo Fijo 0,00 €
Amortización 37,59 €
SUMA
Gastos generales (10 %) 536,11 €
Beneficio (15 %) 804,16 €
SUBTOTAL
IVA (21 %) 1407,29 €
TOTAL 8108,65 €
Por tanto el presupuesto asciende a ocho mil ciento ocho con sesenta y cinco euros
(8108,65 €)..
Riesgo Peligrosidad
Dedicación no exclusiva al trabajo Media
Cambios/Ampliación de requisitos Media
Estancamiento en la codificación Media
Problema con recursos materiales Media
Perdida de Información Alta
Personal poco experimentado Alta
Enfermedades Alta
Elección equivocada de herramientas, algoritmos o métodos Alta
Planificación muy optimista Alta
Cambios/Ampliación de requisitos
Estancamiento en la codificación
• Descripción: Podría llegar a darse algún problema de difícil solución que para-
lizaría momentáneamente el avance del proyecto.
• Probabilidad: 47 %
• Peligrosidad: Media.
• Medidas preventivas: Se estudiará con detalle las herramientas que manejara
el desarrollador.
• Medidas correctoras: Replanificar las tareas posteriores y dedicar mas forma-
ción a las herramientas.
Perdida de información
• Probabilidad: 70 %
• Peligrosidad: Media.
• Medidas preventivas: Se estudiará con detalle todas las materias involucradas
en el desarrollo del trabajo.
• Medidas correctoras: Se estudiará con mas detalle las distintas materias.
Enfermedades
3
Conceptos generales
31
32 CAPÍTULO 3. CONCEPTOS GENERALES
m = CM ∩ R (3.1)
3.2. MODELO DE UN SISTEMA DE VISIÓN POR COMPUTADOR 33
m=(x, y)
fY
C Z
Z
f
y Y x X
= =
f Z f Z
x = f X
Z
(3.2)
fY
y =
Z
X
x
f X
f 0 0 0
Y
Z y = f Y = 0 f 0 0 (3.3)
Z
1 Z 0 0 1 0
1
λm = P M (3.4)
h i
P= K 0 (3.5)
Para conseguir que los ejes coincidan se debe hacer una transformación sobre un
espacio Euclideo en R3 , ya que las únicas transformaciones implicadas son la rotación
y la traslación del objeto.
Suponiendo que la rotación de los ejes X 0 , Y 0 y Z 0 sobre los ejes X, Y y Z está definida
por la matriz ortonormal 3 × 3 R y que la traslación aplicada al eje está definida por el
vector 3 × 1 t se puede definir:
X 0
X
Y 0
i
h
Y = R t (3.6)
Z0
Z
1
o bien
M = SM 0 (3.7)
3.2. MODELO DE UN SISTEMA DE VISIÓN POR COMPUTADOR 35
λm = KSM 0 (3.8)
En la sección 3.2.1 se mencionó que hasta ese momento habíamos asumido ciertas
cosas, y una de ellas era:
Con una cámara CCD no podemos asumirlo, debido a que las coordenadas proyecta-
das x, y en la sección anterior son transformadas en un nuevo sistema de coordenadas u,
v debido a lo siguiente:
Cambio de escala: Para medir la escena utilizamos unidades métricas, como por
ejemplo milímetros, mientras que la imagen será medida en pixels. Por eso, en la transfor-
mación (x, y) → (u, v) se necesita de un factor de escala. Además es posible que el factor de
escala no sea el mismo para cada eje, ya que los píxeles no son cuadrados, sino rectangula-
res. Los factores que vamos a utilizar son αx y αy , normalmente expresados en [pixel/mm].
Traslación del origen: Como es prácticamente imposible que el eje óptico intersec-
cione con el punto central del CCD, denotaremos (u0 , v0 ) como el nuevo punto principal
dentro del nuevo sistema de coordenadas. Es decir (u0 , v0 ) corresponden al punto x = 0,
y = 0, lo que viene a ser el desplazamiento del centro de coordenadas del CCD respecto
al punto principal, tal como se muestra en la figura 3.4.
36 CAPÍTULO 3. CONCEPTOS GENERALES
Figura 3.4: Desplazamiento del punto principal respecto al centro del sensor
u
x
α s u0 f 0 0 x
v = 0 αy v0 0 f 0 y (3.9)
1 0 0 1 0 0 1 1
w = Km (3.10)
λw = KSM 0 (3.11)
α
x
s u0 f 0 0 αx0 s0 u0
0 αy v0 0 f 0 = 0 αy0 v0 (3.12)
0 0 1 0 0 1 0 0 1
3.3. Estereoscopia
La estereoscopia es una técnica utilizada para la recuperación de las coordenadas
tridimensionales de una escena a partir de dos o más imágenes tomadas desde distinta
perspectiva.
La restricción epipolar señala que para que dos puntos m1 y m2 sean correspondientes,
el punto m2 debe estar en la linea epipolar de m1 o al contrario. Esto es una condición
necesaria pero no suficiente, pues no todos los puntos de la linea epipolar de m1 son
correspondientes a éste. Aunque no lo parezca esto es de gran utilidad, pues simplificará
mucho el problema de matching o búsqueda de correspondencias. Esto es debido a que,
en vez de buscar en toda la imagen (dos dimensiones), se buscará en una única recta (una
dimensión). Es decir, si tenemos una imagen de tamaño N × N simplifica un problema de
tamaño N 2 en uno de tamaño N .
De esta forma, si los ejes ópticos tienen la misma dirección y son paralelos, m1 y m2 de
coordenadas (u, v) compartirán una coordenada, la v, haciendo que la linea epipolar sea
una única recta paralela a la recta que une los centros ópticos, es decir el baseline, y que
los epípolos se encuentren en el infinito. Solo diferirán en la coordenada u, esta diferencia
es llamada disparidad.
Z x Z x−B
= =
f u1 f u2
40 CAPÍTULO 3. CONCEPTOS GENERALES
Z x M x−B
u1 u2 X
f
C1 C2
Baseline B
Bf Bf
Z= = (3.13)
u1 − u2 d
Bordes: Pueden tener atributos geométricos de forma (curvas, líneas, etc), orienta-
ción e intensidad. Pueden ser un problema y es que a veces las cámaras no ven las
mismas partes del objeto.
Textura de los objetos: algunos objetos, pueden presentar texturas que provocan
un aumento de la ambigüedad entre puntos. Por ejemplo una textura con patrones
periódicos (como una pared de ladrillos) aumenta el número de puntos similares,
mientras que un objeto de textura lisa o de escasa textura, puede dificultar la bús-
queda del punto correspondiente ya que todos los puntos del objeto son parecidos.
Esto provoca múltiples correspondencias falsas.
42 CAPÍTULO 3. CONCEPTOS GENERALES
Figura 3.9: Capturas donde se aprecia el problema de la intensidad luminosa y del fenó-
meno de oclusión
3.3.6. Interpolación
A veces es necesario aplicar una interpolación debido a que en nuestro mapa de dis-
paridad múltiples puntos no encontraron correspondencia o encontraron una errónea. Por
eso mediante la interpolación se consigue llenar vacíos o corregir errores.
4
Tecnologías y herramientas
4.1. OpenCV
Es una librería de visión por computador de código libre bajo una licencia BSD.
Proporciona un compendio de más de 2500 algoritmos ya optimizados, como el de re-
conocimiento facial, identificación de objetos, seguimiento de objetos en movimiento o
extracción de modelos en 3D a partir de información 2D, etc. . . Son tantas sus funciones
que esta librería es un estándar utilizado en ámbitos como el tratamiento de imágenes o
la inteligencia artificial.
La librería esté escrita en C++, C, Python, Java y MATLAB y es compatible con
Windows, GNU/Linux, Android y Mac OS. Muchas de sus funciones pueden ser utilizadas
para aplicaciones en tiempo real y se está desarrollando una versión compatible con CUDA
y OpenCL para acelerar el cómputo en el hardware de las tarjetas gráficas.
45
46 CAPÍTULO 4. TECNOLOGÍAS Y HERRAMIENTAS
ROS es escalable, pues gracias a que se ejecuta de forma distribuida es posible disponer
de una única instancia de ROS en varios dispositivos.
Por otra parte es totalmente compatible con OpenCV, lo que nos posibilita implemen-
tar los programas desarrollados en ROS.
Principalmente ROS sólo puede ser ejecutado en plataformas basadas en Unix, siendo
las principales Ubuntu y Mac OS X, mientras que gracias a la comunidad también esta
adaptada a otros sistemas operativos como Debian, Arch Linux, Gentoo y otras platafor-
mas que usen el kernel Linux, consideradas como experimentales.
Nodos: Cada nodo dentro de la red es un proceso que realiza una tarea. ROS está
diseñado para ser modular, con lo que de esta forma podemos tener varios nodos
ejecutando distintas tareas. Esta modularidad nos proporciona muchas posibilidades
y siguiendo en la línea del proyecto podríamos utilizar un nodo para capturar el
entorno, otro encargado de crear el mapa de disparidad, otro que estime distancias,
uno que tome decisiones respecto a los datos obtenidos, etc. . .
4.2. ROBOT OPERATING SYSTEM 47
Servicios: Los nodos para comunicarse también cuentan con un modelo Cliente/-
Servidor. De esto se encargan los servicios encargados de servir la tarea para la que
se les invoca. Estos están definidos por un par de mensajes: uno para la petición
y otro para la respuesta. De esta forma un nodo ofrece un servicio y otro nodo lo
utiliza enviando una petición y esperando una respuesta.
Bolsas: Las bolsas son un almacén de datos. Nos permiten guardar y reproducir
distintos tipos de datos que podemos utilizar posteriormente en distintos nodos.
48 CAPÍTULO 4. TECNOLOGÍAS Y HERRAMIENTAS
4.3. Raspberry Pi 2
La Raspberry Pi 2 es la segunda versión de la plataforma embebida de mismo nombre.
Es un ordenador completo de bajo consumo en una única placa. Esta trae varias mejoras
respecto a su anterior modelo, de las cuales destacaremos:
5
Sistema estereoscópico
51
52 CAPÍTULO 5. SISTEMA ESTEREOSCÓPICO
3. Dispone de un micrófono, que podría ser útil y puede ser convertida en cámara
infrarroja.
4. Es compatible con GNU/Linux a través de V4L2 (Video for Linux v.2), siendo
este el sistema en el que ha sido desarrollada la aplicación. Aunque como ya se ha
comentado, los fuentes son compilados con CMake, por tanto son validos también
para otros sistemas.
Finalmente no se utilizaron estas cámaras, sino una versión mayor, la C310 debido a
que se disponía de ellas en el departamento y así no era necesario hacer este desembolso.
La C310 mejora a la C270, en varias características y pueden ser encontradas con un coste
de 40e.
El sistema cuenta con una distancia de baseline de un total de 7,5 cm y para fijar las
cámaras se ha utilizado la estructura que se ve en las figuras 5.1 y 5.2.
Se han fijado las cámaras a una tabla de madera con cinta americana de tal modo
que éstas no consigan moverse. Esta estructura es lo bastante estable para no moverse
siempre que no haya algún elemento externo al sistema que las mueva. Siendo suficiente
para poder desarrollar el trabajo siguiente. Sin embargo, esta estructura podría no servir
si se montase el sistema en un vehículo, por lo tanto habría que reforzarlo. Para ello se
podrían sujetar ambas cámaras con tornillos y hacer unas hendiduras en las que encajar
las cámaras.
El sistema cuenta con una distancia de baseline de un total de 7,5 cm y para fijar las
cámaras se ha utilizado la estructura que se ve en las figuras 5.1 y 5.2.
Se han fijado las cámaras a una tabla de madera con cinta americana de tal modo
que éstas no consigan moverse. Esta estructura es lo bastante estable para no moverse
siempre que no haya algún elemento externo al sistema que las mueva. Siendo suficiente
para poder desarrollar el trabajo siguiente. Sin embargo, esta estructura podría no servir
si se montase el sistema en un vehículo, por lo tanto habría que reforzarlo. Para ello se
podrían sujetar ambas cámaras con tornillos y hacer unas hendiduras en las que encajar
las cámaras.
Su validez es tan buena como la de cualquier otro método que devuelva buenos
resultados.
En este método utilizamos un objeto de calibración del que conocemos las coordena-
das tridimensionales exactas. Así, para cada par de puntos correspondiente identificado,
conoceremos la posición tridimensional. De este modo, como paso previo necesitamos de
un objeto de calibración. Se ha utilizado para ello un tablero de ajedrez, que es un objeto
que sigue un patrón de zonas blancas y negras fácilmente diferenciables, lo que permite
que el algoritmo identifique las esquinas interiores de éste de forma precisa y trabaje efi-
cazmente. En la figura 5.3 puede verse una serie de 15 capturas realizadas con un damero
en el proceso de calibración.
2. Se buscan las esquinas interiores del tablero, en ambas cámaras. Para ello utilizare-
mos el método:
b o o l findChessboardCorners ( image , patternSize , corners ,
CALIB_CB_ADAPTIVE_THRESH | CALIB_CB_FILTER_QUADS )
5.2. CALIBRADO Y RECTIFICADO DEL SISTEMA ESTEREOSCÓPICO 55
Si las esquinas son encontradas devolverá true. El argumento image, es una ma-
triz de entrada que contendrá la imagen del tablero sobre el que se quieren de-
tectar las esquinas. patternSize es el numero de esquinas interiores a buscar, en
nuestro caso patternSize = Size(9,6). corners las esquinas detectadas. El flag CA-
LIB_CB_ADAPTIVE_THRESH indica que se realizará una normalización previa
de la imagen y el otro flag CALIB_CB_FILTER_QUADS hace que se añada un
criterio adicional para descartar falsos positivos.
4. Seguido de esto se mostrarán las esquinas encontradas en las imágenes de los tableros
utilizando la función:
v o i d drawChessboardCorners ( image , patternSize , corners ,
patternWasFound )
Que tiene como argumentos: image es la imagen que contiene el tablero. patternSize
tiene el mismo significado que en el método findChessBoardCorners() y corners son
las esquinas encontradas anteriormente.
6. Una vez se tengan una cantidad de esquinas necesarias se pasará a realizar el cali-
brado del sistema utilizando la función:
d o u b l e stereoCalibrate ( objectPoints , imagePoints1 , imagePoints2 , CM1 ,
distCoeffs1 , CM2 , distCoeffs2 , imageSize , R , T , E , F , T e r m C r i t e r i a (
T e r m C r i t e r i a : : COUNT+T e r m C r i t e r i a : : EPS , 3 0 , 1e−6) ,
CV_CALIB_SAME_FOCAL_LENGTH | CV_CALIB_ZERO_TANGENT_DIST )
Con las banderas introducidas indicamos que las cámaras tienen la misma distancia
focal y que la distorsión tangencial es despreciable.
8. Por ultimo calcularemos los mapas de pixeles (map1x, map1y, map2x, map2y) ne-
cesarios para transformar cualquier imagen tomada con el sistema, en una imagen
rectificada y sin distorsión.
Una vez guardados los datos de la calibración podremos utilizarlos en nuestros progra-
mas. Es muy importante que las cámaras no se muevan, pues al moverse se descalibrarán
y los parámetros calculados dejarán de servir. Aun así, antes de ejecutar cualquier otro
programa es recomendable calibrar el sistema para evitarlo.
58 CAPÍTULO 5. SISTEMA ESTEREOSCÓPICO
Se obtendrán resultados como los vistos en las figuras 5.5 y 5.6. Se observa claramente
cómo en la primera figura las imágenes no están rectificadas pues los puntos de las lineas
epipolares no coinciden. Mientras que en la segunda puede encontrarse correspondencia
en los puntos siguiendo la línea epipolar. Puede verse claramente en la mano del muñeco.
Capítulo
6
Búsqueda de correspondencias y
estimación de distancia
59
60 CAPÍTULO 6. BÚSQ. DE CORRESPONDENCIAS Y ESTIMAR DISTANCIAS
6.1.1. Algoritmo BM
El algoritmo Block Matching trabaja con ventanas de píxeles que utiliza para buscar
correspondencias entre la imagen izquierda y derecha, y como se menciono anteriormente
se basa en las intensidades de los píxeles para encontrar correspondencias. Este método
obtiene buenos resultados en zonas con mucha textura, sin embargo en zonas sin textura
puede dar como resultado que algunos píxeles se queden sin correspondencia.
El algoritmo BM implementado en OpenCV puede dividirse en 3 pasos:
donde Ic es el centro de la ventana, que coincide con el píxel sobre el que estamos
haciendo la normalización, Icap es el limite numérico que imponemos y I es la media
de las intensidades de los píxeles de la ventana actual.
2. Búsqueda: Para ello se hace uso de SAD (Suma de Diferencias Absolutas) sobre
diferentes ventanas de píxeles. Esta técnica es muy sencilla y rápida, SAD utiliza
ventanas centradas en los píxeles sobre los que se van a calcular los costes. Para ello
se elige una ventana en la primera imagen, y para cada píxel de la linea epipolar
de la segunda imagen se crean ventanas del mismo tamaño que la primera y se
comparan. Para comparar las ventanas, primero se suman los valores de intensidad
de los píxeles de estas. Seguido de esto se restará el valor de la ventana de la primera
imagen a las de las otras ventanas guardando el resultado de la diferencia en valor
absoluto. Por ultimo, una vez procesada toda la linea epipolar, para determinar la
correspondencia se tomará la ventana cuyo resultado sea el valor más cercano a 0.
A la hora de hacer la búsqueda no se busca en toda la linea epipolar, sino que se
define una región dentro de esta. Esta región se llama horópter y esta definida por
dos parámetros limite mínimo de disparidad (punto de comienzo de la búsqueda)
y número de disparidades (número de píxeles en los que se buscan corresponden-
cias). La variación de estos parámetros implica que algunos puntos no encuentren
correspondencias.
Como se menciono anteriormente los puntos lejanos tienen valores de disparidad
bajos, mientras que los puntos cercanos altos. De esta forma si variamos el nume-
6.1. ALGORITMOS PARA LA BÚSQUEDA DE CORRESPONDENCIAS 61
Para hacer uso en OpenCV del algoritmo BM debemos de utilizar la clase StereoBM
y iniciaremos el calculo de disparidad con el siguiente operador
void StereoBM::operator()(imageUG1, imageUG2, disp, CV_32F)
Pre-procesado
Búsqueda
• SAD Window Size: Tamaño de la ventana que utilizará la técnica SAD. Valo-
res altos implicaran menos ruido, pero también un mapa de disparidad menos
preciso, además de afectar al rendimiento. Mientras que con valores pequeños
obtendremos un mapa de disparidad más detallado pero con más ruido y co-
rrespondencias erróneas. Sus valores deben ser impares e ir desde 5..255 sin ser
mayores que la anchura o altura de la imagen.
• Min Disparity: Mínimo de disparidad que indica el punto de comienzo de la
búsqueda en el horópter. Dicho de otra forma, el offset desde el punto actual a
62 CAPÍTULO 6. BÚSQ. DE CORRESPONDENCIAS Y ESTIMAR DISTANCIAS
Post-procesado
(mejor_match − siguiente_mejor_match)
uniqueness_ratio > (6.2)
siguente_mejor_match
Donde imageU1 y imageU2 son el par de imágenes rectificadas, pudiendo ser de uno
o tres canales y disp el mapa de disparidad de 16 bits con signo, por lo que será necesario
dividir cada elemento entre 16 para obtener los valores en coma flotante. También sera
necesario normalizar el mapa de disparidad a CV_8U para mostrarlo en pantalla.
64 CAPÍTULO 6. BÚSQ. DE CORRESPONDENCIAS Y ESTIMAR DISTANCIAS
Como se puede observar en la figura 6.1 las diferencias entre los dos algoritmos son no-
tables. Se observa que el algoritmo SGBM devuelve un mapa de disparidad más completo
y detallado sin obtener apenas ruido. Se aprecia que donde existen variaciones de textura,
como la caja de (a) o los bordes del mueble de (d) el algoritmo BM no tiene problemas
para encontrar correspondencia, pero donde la textura es más uniforme como la pared de
(a) o las sillas de (g) el algoritmo BM tiene dificultades para encontrar correspondencia
mientras que el SGBM la encuentra fácilmente.
En alguna de las figuras correspondientes a SGBM puede parecernos que la disparidad
del fondo es la misma, ya que no se diferencia en la figura, pero al pasarlas por una
función de umbral e ir aumentando el valor, vemos que no es así, pues lo más alejado va
desapareciendo del fondo de la imagen.
6.3. CONSIDERACIONES SOBRE LA ESTIMACIÓN DE DISTANCIA 65
Figura 6.2: Blobs obtenidos después de aplicar una función de umbral al mapa de dispa-
ridad
2. Como es posible que dos objetos que se encuentran muy cercanos en la imagen sean
detectados como una única región, lo que haremos será aplicar un filtro morfológico
de erosión. Para ello llamaremos a
66 CAPÍTULO 6. BÚSQ. DE CORRESPONDENCIAS Y ESTIMAR DISTANCIAS
3. Buscaremos los blobs y los filtramos según su área, de tal forma que si son de área
menor que un valor sean excluidos. Así nos evitamos la detección de ruido o de
objetos que son demasiado pequeños para ser de interés.
1 C B l o b R e s u l t blobs ( dst ) ;
2 C B l o b R e s u l t blobs_filtered ;
3 blobs . Filter ( blobs_filtered , F i l t e r A c t i o n : : FLT_EXCLUDE , CBlobGetArea
( ) , F i l t e r C o n d i t i o n : : FLT_LESS , min_area ) ;
4. Una vez que tenemos los blobs, los dibujaremos en la pantalla, mostraremos sus
bounding boxes y los guardaremos para usarlos posteriormente. Tal y como se ve
en la figura 6.2.
X Y Z
(X, Y, Z) = ( , , ) (6.7)
W W W
Esto ya viene implementado en OpenCV de forma que utilizando la siguiente fun-
ción ya tendremos una matriz de tres canales, cada uno con las respectivas coordenadas
(X, Y, Z) de los píxeles.
reprojectImageTo3D(roi, depth, Q)
La región roi es la región que nos interesa del mapa de disparidad (el bounding box
del blob), depth la matriz en la que se guardarán las coordenadas.
La estimación de distancia a los objetos se ha hecho de las siguientes maneras:
Moda: Igual que con la media, se toman todos los valores de distancia, pero en vez
de hacer una media elegimos el que más se repita. Igual que en la media el valor
cero no se tiene en cuenta.
Por lo que se han realizado una serie de pruebas con el algoritmo BM para ver si los
resultados devueltos por el programa desarrollado son fiables, para ello se han tomado 28
capturas de una caja a distintas distancias, 14 de ellas en un parque y las otras restantes
en el interior de una casa. De esta forma comprobaremos si distintas iluminaciones, una
con luz natural y la otra con una única luz artificial, influyen en los resultados.
Una vez realizadas las pruebas con los dos métodos, se ha obtenido los resultados
reflejados en las gráficas de la figura 6.4. En ellas se hace una comparación entre la medida
real y la estimada por el programa. Se puede observar cómo en el exterior la estimación
de distancias se comporta muy bien, pues el error máximo obtenido fue de 7, 4 cm en la
décimo segunda medida, con una distancia real de 2, 45 m. Mientras que en el interior con
68 CAPÍTULO 6. BÚSQ. DE CORRESPONDENCIAS Y ESTIMAR DISTANCIAS
Figura 6.5: Error resultante en cada muestra junto con su error medio
6.4. EXPERIMENTOS SOBRE ESTIMACIÓN DE DISTANCIA 69
7
Rendimiento de algoritmos y
plataformas
71
72 CAPÍTULO 7. RENDIMIENTO DE ALGORITMOS Y PLATAFORMAS
Algoritmos BM SGBM
Pre-Filter Size 5 –
Pre-Filter Cap 32 63
SAD Window Size 13 5
Min Disp 0 0
Num Disp 3 3
Texture Threshold 1000 –
Uniqueness Ratio 15 5
Speckle Window Size 200 50
Speckle Range 32 32
Algoritmos BM SGBM
Media (s) 0,0104 0.046
FPS 96,15 21,74
Algoritmos BM SGBM
Media (s) 0,1444 1,5452
FPS 6,93 0,65
Al realizar las pruebas con las cámaras se ha advertido que la tasa de FPS varía
dependiendo de la iluminación de la escena. Parece ser que cuando la iluminación es algo
baja, las cámaras hacen un ajuste para obtener capturas de mejor calidad sacrificando
para ello la tasa de FPS. Ejemplos de iluminaciones se pueden ver en la figura 7.1.
Teniendo en cuenta que en el peor de los casos las cámaras obtendrán imágenes a
una tasa de 15 FPS, éstas formarán un cuello de botella en el Intel, mientras que en la
Raspberry, que es donde se enfoca este trabajo, el cuello de botella lo causa el algoritmo
de búsqueda de correspondencia. De esta forma el programa completo se ejecutará a una
tasa de unos 4 FPS de promedio en la Raspberry Pi 2.
Como nos es imposible hacer que las cámaras capturen imágenes a mayor velocidad
y dado que nuestro principal cuello de botella es el algoritmo BM, se ha paralelizado el
programa de forma que mitigue estos problemas.
74 CAPÍTULO 7. RENDIMIENTO DE ALGORITMOS Y PLATAFORMAS
Mono-Hilo Multi-Hilo
Tiempo(s) FPS Tiempo(s) FPS
0,2308 4,33 0,0873 11,45
Tabla 7.6: Comparación entre el programa mono-hilo y el multi-hilo con tres tareas
Tabla 7.7: Resultados de tiempos y FPS obtenidos del programa multi-hilo, con distintas
tareas
Se puede observar como tanto con una, dos o tres tareas la tasa de FPS es mayor que
en el programa mono-hilo. Esto es debido a que las cámaras trabajan en paralelo con las
demás partes del programa, mientras que en el mono-hilo lo hacen de forma secuencial.
Parte IV
8
Desviación en la planificación
77
78 CAPÍTULO 8. DESVIACIÓN EN LA PLANIFICACIÓN
9
Conclusiones y trabajo futuro
Aunque este trabajo está enfocado a la robótica, sus aplicaciones pueden ser muy
variadas, como por ejemplo el modelado de objetos reales. Los resultados obtenidos en
la sección 7 indican que estos algoritmos pueden ser utilizados en aplicaciones en tiempo
real en equipos de sobremesa, incluso en una placa como una Raspberry Pi 2, aunque esta
ya presenta más limitaciones.
Debido a la distorsión que se causa en las imágenes al capturar un objeto que se mueve
a gran velocidad no hacen a este trabajo el perfecto para hacer seguimiento de distintos
79
80 CAPÍTULO 9. CONCLUSIONES Y TRABAJO FUTURO
objetos. Por otra parte estos métodos, tienen algunas ventajas sobre los basados en láser,
debido a que el láser solo obtiene mediciones del entorno si los objetos se encuentran en
la trayectoria del haz. Con un sistema estereoscópico el grado del entorno percibido es
mayor, por tanto es más difícil que un objeto no sea percibido.
Este trabajo se aborda mediante el paradigma de la robótica clásica SMPA. Por una
parte se ha cumplido con las dos primeras Sense y Model, pero las dificultades propias de
un trabajo de investigación como éste no permiten cumplir todos los requisitos funcionales
y por tanto hubo que modificar la planificación y se abordaron otros objetivos.
El trabajo estaba planteado de una forma completamente abierta, por lo que puede
crecer y mejorar en varios aspectos:
Si se cambian las cámaras por unas capaces de capturar a una tasa mayor de FPS,
se reducirá el cuello de botella causado por las mismas en el equipo de sobremesa.
Hacer uso de una GPU de Nvidia para calcular los mapas de disparidad. OpenCV
es compatible con CUDA para utilizar el algoritmo BM.
Hacer uso de la biblioteca de la nube de puntos. De esta forma se añade una fun-
cionalidad más al trabajo que nos permitirá modelar escenarios.
81
Compilar OpenCV con soporte para QT y crear una interfaz de usuario mas ami-
gable.
Parte V
Apéndices y bibliografía
Apéndice
A
Manual de Usuario
Este capítulo esta dedicado a cualquier persona que quiera hacer uso o modificar el
software desarrollado en este proyecto. Por ello este manual muestra una explicación sobre
cómo compilar y hacer uso del trabajo.
Un compilador de C/C++
85
86 APÉNDICE A. MANUAL DE USUARIO
calibrar es un programa que puede ser utilizado para calibrar una única cámara. No
tiene un uso en el trabajo desarrollado, pero se desarrolló al principio del trabajo y
se utilizó como base para el programa de calibración estéreo
calibrateStereo se utiliza para calibrar el sistema estéreo.
stereo_matchSGBM es el programa que ejecuta el algoritmo SGBM para calcular
los mapas de disparidad y estimar distancias
stereo_matchBM como el programa stereo_matchSGBM pero con el algoritmo BM
stereo_matchBM_threads exactamente igual que el anterior pero además es multi-
hilo
VideoCapture es el programa utilizado para hacer las pruebas de tasa de FPS con
las cámaras
surf_object_detector es el programa desarrollado con el algoritmo SURF, que final-
mente no se utilizó en el proyecto
A.4. COMO COMPILAR EL SOFTWARE 87
$ mkdir b u i l d
$ cd b u i l d
$ cmake . .
$ make
Puede que nos interese, en caso de que no queramos depurar los programas compilados,
compilar en modo release, para ello podremos indicarlo a la hora de generar los makefiles
con:
$ cmake −DCMAKE_BUILD_TYPE=RELEASE . .
1. Una vez que tenemos los datos de calibración, crearemos un objeto de la clase
SCalibData con el siguiente constructor.
SCalibData(Mat CM1, Mat CM2, Mat D1, Mat D2, Mat R, Mat T, Mat E, Mat F, Mat R1, Mat R2, Mat
P1, Mat P2, Mat Q, Rect roi1, Rect roi2, int frame_width, int frame_height);
Donde CM1 y CM2 son las matrices de calibración de las cámaras. D1 y D2 son
los coeficientes de distorsión de las lentes. R, T, E y F son respectivamente la
matriz de rotación, traslación, esencial y fundamental del conjunto binocular. R1
88 APÉNDICE A. MANUAL DE USUARIO
2. Cuando tengamos el objeto instanciado con todos sus atributos podremos guardarlo
en el disco utilizando la función write(FileStorage& fs) de la clase SCalibData. Sólo es
necesario pasar como argumento un objeto de la clase FileStorage que es la encargada
de escribir ficheros YAML o XML en OpenCV.
Los argumentos encerrados en corchetes son opcionales, de esta forma podemos añadir
la resolución deseada para la calibración. Si no la indicamos, tomara por defecto una
resolución de 640x480. Con la opción -a activamos el modo automático. Con este modo el
programa capturara las esquinas del tablero que se muestren a las cámaras, sin ninguna
intervención del usuario. Aun así este modo no se recomienda si se quiere obtener unos
buenos resultados de calibración.
Una vez ejecutado el programa se preguntará al usuario el número de esquinas tanto
horizontales como verticales del tablero, el tamaño de los cuadrados, el número de fotos
a hacer y el número de la cámara izquierda y derecha. Este ultimo variará dependiendo
de como haya detectado las cámaras nuestro sistema operativo (Ej: Para /dev/video0
indicaremos 0).
A.6. EJECUCIÓN DEL SOFTWARE 89
En cuanto indiquemos todo lo anterior nos aparecerán dos ventanas con lo que están
capturando las cámaras. Puesto que para el programa es imposible saber que cámara es la
izquierda y cual la derecha, el usuario tendrá que comprobarlo, y si no están bien, cerrar
el programa y volver a iniciarlo correctamente.
Una vez esté todo correctamente ajustado, se procede a mostrar el tablero a las cáma-
ras. El programa detectará las esquinas interiores del tablero y nos las mostrará. Cuando
las esquinas se muestren en las ventanas, es cuando podremos guardar las capturas, para
eso pulsaremos la barra espaciadora. Si se activo el modo automático no sera necesario,
pero se insiste en no usarlo, pues los resultados no serán los mejores.
Cuando se haya hecho el número de capturas indicadas por el usuario, se empezará a
calcular los parámetros intrínsecos y extrínsecos. Este proceso puede tardar, y dependerá
de el número de capturas que hayamos indicado.
Al final del programa se mostrará una ventana más en la que aparecen las dos cap-
turas de las otras ventanas rectificadas, junto con sus regiones de interés y unas lineas
horizontales. En este punto se puede pulsar la tecla r para parar la captura y congelar las
imágenes. Con las imágenes congeladas podremos comprobar mucho mejor si el proceso
de calibración ha sido bueno. También podremos pulsar la barra espaciadora para tomar
una captura de las imágenes.
Finalmente para salir pulsaremos la tecla escape. En el directorio donde se ejecutó el
programa se habrá guardado un fichero de calibración de nombre stereo_calib_<height>.yml.
siendo cuatro. Si se quisiese cambiar el número de hilos se tendrá que modificar el código
fuente del software.
Si queremos ejecutar uno de estos programas sin tener que utilizar una cámara po-
dremos cargar un par de imágenes por medio de la opción -l, el único requisito es que
las dos imágenes que vamos a cargar estén rectificadas, además será obligatorio añadir
un fichero de calibración, pues es necesario para estimar las distancias. Para cargar un
fichero de calibración lo haremos mediante la opción -c. Podemos utilizar la opción -d
para cambiar el método para estimar las distancias, si elegimos el 1 estableceremos la
media como método, si por el contrario se elige la opción 2 se utilizará la moda, si no se
especifica se elegirá el 1. La opción –test nos servirá para iniciar el modo test del programa
que ejecutará 100 ciclos de programa guardando los resultados de tiempo y calculando un
promedio como resultado.
En la ventana de blobs, nos aparecerán los objetos que se han encontrado junto con
su distancia estimada.
Si al usuario le parece molesto que se este mostrando por pantalla el tiempo que lleva
ejecutar cada ciclo, lo puede desactivar pulsando la tecla s.
Podremos capturar todas las imágenes que se muestran en las ventanas si pulsamos
la barra espaciadora. Las imágenes se guardarán en el disco en el mismo directorio en el
que se ejecuta el programa.
inmediatamente, si no que se ejecutará cien veces más guardando los resultados de tiempo
y calculando el promedio.
Será necesario pasar como primeros argumentos los números de las cámaras que que-
ramos utilizar. Como argumentos opcionales tenemos -s y -t. Con el primero indicaremos
la resolución de la grabación y con el segundo iniciaremos el modo test de forma que se
ejecuten 100 ciclos y se calcule el promedio de tiempo para cada ciclo.
Con la opción -bw iniciaremos la captura de las cámaras en blanco y negro. Con -c
se puede indicar la cámara a utilizar, si no se indica se utilizará la 0. Por ultimo con la
opción -m indicaremos el mínimo de correspondencias mínimas que tiene que haber para
que se dibuje un recuadro en el objeto detectado.
Mientras el programa esté ejecutándose, se podrá pulsar r para congelar la captura y
la barra espaciadora, para tomar una captura. Si queremos finalizar el programa bastará
con pulsar la tecla escape.
Como dato adicional, este programa no se ha podido compilar con la versión de
OpenCV que se ha utilizado en la Raspberry Pi 2, debido a que esta no dispone de
las librerías del modulo nonfree en las que se encuentra implementado el método SURF.
92 APÉNDICE A. MANUAL DE USUARIO
Apéndice
B
Pliego de condiciones
Monitor con una resolución mínima de 1024 × 768 píxeles. Pero se recomienda uno
de mayor resolución.
93
94 APÉNDICE B. PLIEGO DE CONDICIONES
Cámaras: No es necesario disponer de dos cámaras para hacer uso del proyecto, pues
puede utilizarse con imágenes que previamente hayan sido rectificadas y de las que dispon-
gamos un fichero de calibración. Aun así es muy recomendable disponer de dos cámaras
para hacer un uso total de las funcionalidades del software.
Ratón: Es recomendable su utilización para la comodidad del usuario en la ventana
de configuración, pero su uso no es necesario para el buen funcionamiento del software.
C
Actualización de la Raspberry Pi 2 a
Raspbian Jessie
Como la distribución instalada Raspbian Wheezy solo disponía en los repositorios una
versión de OpenCV menor que la usada (OpenCV 2.4.11), que no nos permitía compi-
lar los programas desarrollados en C++, se optó por actualizar a la versión Jessie, que
actualmente esta marcada como experimental.
Para iniciar la actualización, primero debemos editar las fuentes de los repositorios.
Para ello se edita el fichero que se encuentra en /etc/apt/sources.list y se cambian
todas las lineas en las que aparezca wheezy por jessie.
$ apt−g e t update
$ apt−g e t upgrade
$ apt−g e t d i s t −upgrade
95
96 APÉNDICE C. ACTUALIZACIÓN DE LA RASPBERRY PI 2 A RASPBIAN JESSIE
y esperaremos a que se termine la actualización, que terminará en unas horas. Una vez
actualizado el sistema, podemos bajarnos la version 2.4.9.1 de OpenCV de los repositorios
que sí que nos permite compilar sin ningún problema los programas.
Apéndice
D
Rosberry Pi
Esta guía explica como instalar ROS Indigo en una Raspberry Pi 2 con Raspbian
Jessie. La guía a sido adaptada y traducida de la wiki de ROS [2].
D.1. Pre-requisitos
Primero vamos a hacer unas configuraciones y instalar dependencias necesarias para
la correcta instalación de ROS.
97
98 APÉNDICE D. ROSBERRY PI
Ahora nos aseguramos de que el índice de repositorios de nuestro Debian esté actua-
lizado:
$ sudo apt−g e t update
$ sudo apt−g e t upgrade
D.2. Instalación
En este apartado vamos a descargar y compilar ROS Indigo.
Después de esto descargaremos los paquetes principales. Para ello utilizaremos wstool,
con wstool seleccionaremos la variante de ROS que queremos descargar. En un principio,
se puede instalar cualquier variante, pero las probadas en la wiki son:
ROS-Comm: (Recomendada) Contiene ROS, librerías de comunicación y compi-
lado. No tiene herramientas de interfaz de usuario.
$ r o s i n s t a l l _ g e n e r a t o r ros_comm −−r o s d i s t r o i n d i g o −−deps −−
wet−o n l y −−e x c l u d e r o s l i s p −−t a r > i n d i g o −ros_comm−wet .
rosinstall
$ w s t o o l i n i t s r c i n d i g o −ros_comm−wet . r o s i n s t a l l
D.2. INSTALACIÓN 99
$ w s t o o l update −t s r c
$ mkdir ~/ ros_catkin_ws / e x t e r n a l _ s r c
$ sudo apt−g e t i n s t a l l c h e c k i n s t a l l cmake
$ sudo sh −c ’ echo " deb−s r c ␣ http : / / m i r r o r d i r e c t o r . r a s p b i a n . or g
/ r a s p b i a n /␣ t e s t i n g ␣main␣ c o n t r i b ␣non−f r e e ␣ r p i " >> / e t c / apt /
sources . l i s t ’
$ sudo apt−g e t update
$ cd ~/ ros_catkin_ws / e x t e r n a l _ s r c
$ sudo apt−g e t i n s t a l l l i b b o o s t −f i l e s y s t e m −dev l i b x m l 2 −dev
$ wget h ttp : / / downloads . s o u r c e f o r g e . ne t / p r o j e c t / c o l l a d a −dom/
C o l l a d a %20DOM/ C o l l a d a %20DOM%202.4/ c o l l a d a −dom− 2 . 4 . 0 . t g z
$ t a r −x z f c o l l a d a −dom− 2 . 4 . 0 . t g z
$ cd c o l l a d a −dom− 2 . 4 . 0
$ cmake .
$ sudo c h e c k i n s t a l l make i n s t a l l
$ cd ~/ ros_catkin_ws
$ r o s d e p i n s t a l l −−from−paths s r c −−i g n o r e −s r c −−r o s d i s t r o
i n d i g o −y −r −−os=debian : j e s s i e
Esto buscará todos los paquetes en el directorio src y encontrará todas las dependencias
que estos tengan. Luego recursivamente instalará estas dependencias.
Puede que rosdep avise de que python-rosdep, python-catkin-pkg, python-rospkg y
python-rosdistro no se instalaron. Se puede ignorar este error, por que ya fueron instalados
anteriormente con pip.
E
Paralelización del trabajo con OpenMP
OpenMP es una API utilizada para la programación multi-hilo. Esta API puede uti-
lizarse en lenguajes como C/C++ y Fortran y esta pensada principalmente para proce-
sadores multi-núcleo. Para ello se hace uso de directivas, con las que podremos indicar
qué parte del código del programa debe ser ejecutada por varios flujos de ejecución. La
sintaxis es muy sencilla de utilizar, es de la forma:
# pragma omp <directiva [ clausula , ..]
{
// C o d i g o p a r a l e l o
}
Como puede verse en la figura E.1, OpenMP utiliza un modelo fork-join, de forma que
todo programa empieza con un único hilo llamado master que ejecutará el código hasta
encontrarse con un bloque de código especificado como paralelo. Llegados a este punto
el hilo master crea un grupo de hilos que ejecutarán ese bloque en paralelo. Cuando el
101
102 APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
bloque se haya terminado, los hilos se sincronizarán, es decir se esperarán unos a otros y
terminarán dejando solo a master ejecutar el resto del programa.
1. Primero se cargan todos los datos de la calibración, para poder rectificar las imágenes
capturadas. Y se llega al bloque paralelo del programa
Con la directiva parallel indicamos que a partir de ese punto comienza el bloque
paralelo. La clausula shared indica las variables que serán compartidas entre los
hilos. La directiva num_threads indica el numero total de hilos que se van a crear
dentro del bloque.
Los cuatro hilos se encontraran con esta directiva single, que indica que las instruc-
ciones que encierra sólo serán ejecutadas por un único hilo. Con la cláusula nowait
les decimos a los tres hilos restantes que no esperen al hilo que está trabajando y
que sigan con el flujo de instrucciones. Esto se ha hecho así porque lo que ejecuta
este hilo corresponde al primer bloque de la figura E.2, es decir, el hilo entrará en un
bucle que parará cuando queramos terminar el programa e irá capturando imágenes
y llenando el buffer.
103
3. Los tres hilos restantes siguen el flujo de ejecución del programa hasta que se en-
cuentran con una directiva más.
#pragma omp single
Al ser un programa que se ejecuta en paralelo hay partes de la memoria que son
compartidas (Ej: Buffer de imágenes). Por tanto hay que hacer uso de secciones críticas.
Una sección crítica es una porción del programa en la que se accede a una parte de la
memoria compartida, que sólo puede ser accedida por un único hilo de ejecución. Para
indicar una sección critica dentro del programa se hace uso de la directiva:
# pragma omp critical ( nombre_seccion )
{
// C o d i g o de l a s e c c i o n c r i t i c a
}
104
APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
Figura E.2: Planteamiento de la paralelización del programa para 4 hilos
GNU Free Documentation License
<http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of this license document,
but changing it is not allowed.
Preamble
The purpose of this License is to make a manual, textbook, or other functional and
useful document “free” in the sense of freedom: to assure everyone the effective freedom
105
106 APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
to copy and redistribute it, with or without modifying it, either commercially or noncom-
mercially. Secondarily, this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for modifications made by
others.
This License is a kind of “copyleft”, which means that derivative works of the document
must themselves be free in the same sense. It complements the GNU General Public
License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because
free software needs free documentation: a free program should come with manuals provi-
ding the same freedoms that the software does. But this License is not limited to software
manuals; it can be used for any textual work, regardless of subject matter or whether it
is published as a printed book. We recommend this License principally for works whose
purpose is instruction or reference.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover
Texts or Back-Cover Texts, in the notice that says that the Document is released under
this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may
be at most 25 words.
Examples of suitable formats for Transparent copies include plain ASCII without mar-
kup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available
DTD, and standard-conforming simple HTML, PostScript or PDF designed for human
modification. Examples of transparent image formats include PNG, XCF and JPG. Opa-
que formats include proprietary formats that can be read and edited only by proprietary
word processors, SGML or XML for which the DTD and/or processing tools are not gene-
rally available, and the machine-generated HTML, PostScript or PDF produced by some
word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following
pages as are needed to hold, legibly, the material this License requires to appear in the
title page. For works in formats which do not have any title page as such, “Title Page”
means the text near the most prominent appearance of the work’s title, preceding the
beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document
to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title
either is precisely XYZ or contains XYZ in parentheses following text that translates
XYZ in another language. (Here XYZ stands for a specific section name mentioned below,
such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To
“Preserve the Title” of such a section when you modify the Document means that it
remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that
this License applies to the Document. These Warranty Disclaimers are considered to be
108 APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
included by reference in this License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and has no effect on the
meaning of this License.
109
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either commercially or
noncommercially, provided that this License, the copyright notices, and the license notice
saying this License applies to the Document are reproduced in all copies, and that you
add no other conditions whatsoever to those of this License. You may not use technical
measures to obstruct or control the reading or further copying of the copies you make or
distribute. However, you may accept compensation in exchange for copies. If you distribute
a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may
publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have printed covers)
of the Document, numbering more than 100, and the Document’s license notice requires
Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all
these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the
back cover. Both covers must also clearly and legibly identify you as the publisher of
these copies. The front cover must present the full title with all words of the title equally
prominent and visible. You may add other material on the covers in addition. Copying
with changes limited to the covers, as long as they preserve the title of the Document and
satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put
the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest
onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100,
you must either include a machine-readable Transparent copy along with each Opaque
copy, or state in or with each Opaque copy a computer-network location from which
the general network-using public has access to download using public-standard network
protocols a complete Transparent copy of the Document, free of added material. If you use
the latter option, you must take reasonably prudent steps, when you begin distribution of
Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible
at the stated location until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well
before redistributing any large number of copies, to give them a chance to provide you
with an updated version of the Document.
110 APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under the conditions
of sections 2 and 3 above, provided that you release the Modified Version under precisely
this License, with the Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever possesses a copy of it.
In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the
Document, and from those of previous versions (which should, if there were any,
be listed in the History section of the Document). You may use the same title as a
previous version if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities responsible for
authorship of the modifications in the Modified Version, together with at least five
of the principal authors of the Document (all of its principal authors, if it has fewer
than five), unless they release you from this requirement.
C. State on the Title page the name of the publisher of the Modified Version, as the
publisher.
E. Add an appropriate copyright notice for your modifications adjacent to the other
copyright notices.
F. Include, immediately after the copyright notices, a license notice giving the public
permission to use the Modified Version under the terms of this License, in the form
shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections and required Cover
Texts given in the Document’s license notice.
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item
stating at least the title, year, new authors, and publisher of the Modified Version as
given on the Title Page. If there is no section Entitled “History” in the Document,
create one stating the title, year, authors, and publisher of the Document as given
on its Title Page, then add an item describing the Modified Version as stated in the
previous sentence.
111
J. Preserve the network location, if any, given in the Document for public access to
a Transparent copy of the Document, and likewise the network locations given in
the Document for previous versions it was based on. These may be placed in the
“History” section. You may omit a network location for a work that was published
at least four years before the Document itself, or if the original publisher of the
version it refers to gives permission.
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in
their titles. Section numbers or the equivalent are not considered part of the section
titles.
M. Delete any section Entitled “Endorsements”. Such a section may not be included in
the Modified Version.
If the Modified Version includes new front-matter sections or appendices that qualify
as Secondary Sections and contain no material copied from the Document, you may at
your option designate some or all of these sections as invariant. To do this, add their titles
to the list of Invariant Sections in the Modified Version’s license notice. These titles must
be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but
endorsements of your Modified Version by various parties—for example, statements of
peer review or that the text has been approved by an organization as the authoritative
definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up
to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified
Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added
by (or through arrangements made by) any one entity. If the Document already includes
a cover text for the same cover, previously added by you or by arrangement made by the
same entity you are acting on behalf of, you may not add another; but you may replace
the old one, on explicit permission from the previous publisher that added the old one.
112 APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
The author(s) and publisher(s) of the Document do not by this License give permission
to use their names for publicity for or to assert or imply endorsement of any Modified
Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this License,
under the terms defined in section 4 above for modified versions, provided that you in-
clude in the combination all of the Invariant Sections of all of the original documents,
unmodified, and list them all as Invariant Sections of your combined work in its license
notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical
Invariant Sections may be replaced with a single copy. If there are multiple Invariant
Sections with the same name but different contents, make the title of each such section
unique by adding at the end of it, in parentheses, the name of the original author or
publisher of that section if known, or else a unique number. Make the same adjustment
to the section titles in the list of Invariant Sections in the license notice of the combined
work.
In the combination, you must combine any sections Entitled “History” in the various
original documents, forming one section Entitled “History”; likewise combine any sections
Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete
all sections Entitled “Endorsements”.
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released
under this License, and replace the individual copies of this License in the various docu-
ments with a single copy that is included in the collection, provided that you follow the
rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it indivi-
dually under this License, provided you insert a copy of this License into the extracted
document, and follow this License in all other respects regarding verbatim copying of that
document.
A compilation of the Document or its derivatives with other separate and independent
documents or works, in or on a volume of a storage or distribution medium, is called an
“aggregate” if the copyright resulting from the compilation is not used to limit the legal
rights of the compilation’s users beyond what the individual works permit. When the
Document is included in an aggregate, this License does not apply to the other works in
the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document,
then if the Document is less than one half of the entire aggregate, the Document’s Cover
Texts may be placed on covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form. Otherwise they must
appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly
provided under this License. Any attempt otherwise to copy, modify, sublicense, or dis-
tribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular
copyright holder is reinstated (a) provisionally, unless and until the copyright holder
explicitly and finally terminates your license, and (b) permanently, if the copyright holder
fails to notify you of the violation by some reasonable means prior to 60 days after the
cessation.
114 APÉNDICE E. PARALELIZACIÓN DEL TRABAJO CON OPENMP
The Free Software Foundation may publish new, revised versions of the GNU Free
Documentation License from time to time. Such new versions will be similar in spirit to
the present version, but may differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document
specifies that a particular numbered version of this License “or any later version” applies
to it, you have the option of following the terms and conditions either of that specified
version or of any later version that has been published (not as a draft) by the Free Software
Foundation. If the Document does not specify a version number of this License, you may
choose any version ever published (not as a draft) by the Free Software Foundation. If
the Document specifies that a proxy can decide which future versions of this License can
be used, that proxy’s public statement of acceptance of a version permanently authorizes
you to choose that version for the Document.
11. RELICENSING
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide
Web server that publishes copyrightable works and also provides prominent facilities for
anybody to edit those works. A public wiki that anybody can edit is an example of such a
server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means
any set of copyrightable works thus published on the MMC site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license pu-
blished by Creative Commons Corporation, a not-for-profit corporation with a principal
place of business in San Francisco, California, as well as future copyleft versions of that
license published by that same organization.
115
[4] D. Calin. Fundamental guide for stereo vision cameras in robotics. http://aiweb.
techfak.uni-bielefeld.de/content/bworld-robot-control-software/, 2013.
117
118 BIBLIOGRAFÍA
[7] D. Lee. Building and calibrating a stereo camera with opencv. https://erget.
wordpress.com/2014/02/01/calibrating-a-stereo-camera-with-opencv/,
2014.
[9] D. Mery. Visión por computador. Santiago de Chile. Universidad Católica de Chile,
2004. xi, xi, xi, 32, 34, 39
[17] Z. Zhang. A flexible new technique for camera calibration. Pattern Analysis and
Machine Intelligence, IEEE Transactions on, 22(11):1330–1334, 2000. 37