Tesis de Grado Realimentacion Visual Par

JE
ESÚS MA
ARÍA GO
ONZÁLE
EZ VILL
LAGÓME
EZ
REALIIMEN
R NTACIÓÓN VIISUALL
PAR
RA EL CONNTROL L DE
UN VEHÍÍCULO
O AÉR
REO
CU
UATRIMOTO OR NOO TRIP
PULAADO
S
SEVILLAA
2010
UNIV
VERSID
DAD DE SEVIILLA
INGEN
NIERO EN INF
FORMÁ
ÁTICA
REALIIMEN
R NTACIÓÓN VIISUALL
PAR
RA EL CONNTROL L DE
UN VEHÍÍCULO
O AÉR
REO
CU
UATRIMOTO OR NOO TRIP
PULAADO
Proyeecto Final de Carreraa presentaado en:
Dptoo. de Ing
genieríaa de Sisttemas y Automáática
Escuela
E Suuperior de Ingeniero
os
POR
JE
ESÚS MA
ARÍA GO
ONZÁLE
EZ VILL
LAGÓME
EZ
TUTOR
D MA
DR. ANUEL V
VARGAS
S VILLA
ANUEVA
A
Sevilla, S
Septiembree de 2010..
i
ii
iii
A Marta, mi novia, y mi familia, por su incomensurable paciencia.
A Rafa y Ramón, entre otros, compañeros del Departamento de Ingeniería

de Sistemas y Automática de la Universidad de Sevilla, por haberme acogido
como uno más entre ellos, y por haberme dado continuas muestras de cariño.
Y en especial a Manuel Vargas, profesor del Dpto., por haber confiado en mí

habiéndome dado esta oportunidad y por estar siempre disponible para
ayudarme cada vez que llamaba a la puerta de su despacho, que no han sido
pocas.
Gracias por haber estado siempre ahí.

iv
v
El contexto en el que se desarrolla este proyecto es en el del

control de vehículos aéreos autónomos (UAV). Se afronta esta ta-
rea desde un punto de vista distinto al habitual, considerando en
primer lugar un control complementado mediante información
visual obtenida del entorno, y en segundo lugar, como posible
ampliación, se describen algunas técnicas mediante las cuales la
única información sensorial para el control sería la obtenida con
el sensor óptico. Se planteará un esquema de control basado en
visión, y se incluirán descripciones de algoritmos para el proce-
samiento de la información visual. Como conclusión a la presente
memoria, y dada la especialidad del autor, se incluirán también
posibles ampliaciones del presente trabajo más próximas a la en-
señanza recibida como Ingeniero en Informática.
vi
Índice general
1. Introducción 1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Problemas en el control visual de vehículos aéreos autónomos . 4
1.3. Objetivos y propuestas . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . 8
2. Estado del arte del control de plataformas UAV 11

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2. Control no basado en visión de vehículos aéreos autónomos . . 13
2.3. Control con información visual de vehículos aéreos autónomos 16
2.4. Aplicaciones del control visual en plataformas autónomas . . . 18
3. Técnicas de control con realimentación visual 21

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Configuraciones cámara-robot . . . . . . . . . . . . . . . . . . 22
3.2.1. Según la disposición de la cámara respecto del robot . 22
3.2.2. Según el número de cámaras . . . . . . . . . . . . . . . 24
3.3. Esquemas de control visual . . . . . . . . . . . . . . . . . . . . 25
3.3.1. En función de la estructura de control . . . . . . . . . 25
3.3.2. En función de la información visual . . . . . . . . . . 27
3.3.3. En función de los elementos requeridos en el campo visual 33
3.3.4. En función de la necesidad de modelo del objeto . . . . 34
3.3.5. En función del modelo visuo-motor . . . . . . . . . . . 35
3.4. Otros aspectos del control visual . . . . . . . . . . . . . . . . . 36
3.5. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4. Localización y seguimiento del objeto de referencia 39

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2. Representación del objeto . . . . . . . . . . . . . . . . . . . . 42
4.3. Selección de características para el seguimiento . . . . . . . . . 47
4.4. Detección del objeto . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1. Detectores de puntos . . . . . . . . . . . . . . . . . . . 49
vii
ÍNDICE GENERAL viii
4.4.2. Métodos de detección no basados en puntos . . . . . . 52

4.5. Seguimiento del objeto . . . . . . . . . . . . . . . . . . . . . . 53
4.5.1. Seguimiento basado en puntos . . . . . . . . . . . . . . 54
4.5.2. Seguimiento basado en apariencia . . . . . . . . . . . . 58
4.5.3. Seguimiento de siluetas y contornos . . . . . . . . . . . 60
5. Sensor óptico: modelado y proceso de calibración 61

5.1. Modelado de la cámara . . . . . . . . . . . . . . . . . . . . . . 61
5.1.1. Modelo pinhole . . . . . . . . . . . . . . . . . . . . . . 61
5.1.2. Parámetros extrínsecos . . . . . . . . . . . . . . . . . . 62
5.1.3. Parámetros intrínsecos . . . . . . . . . . . . . . . . . . 65
5.2. Posicionamiento 3D mediante el sistema de visión . . . . . . . 71
5.3. Proceso de calibración . . . . . . . . . . . . . . . . . . . . . . 73
5.3.1. Base teórica . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3.2. Proceso de calibración en la práctica . . . . . . . . . . 78
6. Implementación de mecanismos para la extracción de infor-

mación visual 91
6.1. Objeto de referencia tridimensional . . . . . . . . . . . . . . . 92
6.1.1. Representación, localización y seguimiento del objeto de
referencia . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.1.2. Cálculo de los parámetros extrínsecos . . . . . . . . . . 100
6.1.3. Proyección tridimensional . . . . . . . . . . . . . . . . 101
6.1.4. Comprobación de resultados . . . . . . . . . . . . . . . 104
6.1.5. Problemas durante la implementación . . . . . . . . . . 111
6.2. Objeto de referencia plano . . . . . . . . . . . . . . . . . . . . 113
6.2.1. Matriz de homografía . . . . . . . . . . . . . . . . . . . 116
6.2.2. GoodFeaturesToTrack() y flujo óptico para el seguimien-
to del objeto de referencia . . . . . . . . . . . . . . . . 128
6.2.3. SIFT - Scale Invariant Feature Transform . . . . . . . 145
6.2.4. SURF - Speeded Up Robust Features . . . . . . . . . . . 147
6.3. Otras alternativas para la realimentación visual . . . . . . . . 150
7. Fusión sensorial 151

7.1. Descripción del sensor inercial . . . . . . . . . . . . . . . . . . 151
7.2. Funciones de interfaz con la IMU . . . . . . . . . . . . . . . . 153
7.2.1. Datos de orientación . . . . . . . . . . . . . . . . . . . 153
7.2.2. “Calibrated Data” . . . . . . . . . . . . . . . . . . . . 155
7.3. Medidas incompletas de la IMU . . . . . . . . . . . . . . . . . 157
7.4. Fusión de la información . . . . . . . . . . . . . . . . . . . . . 160
7.5. Calibración IMU-Cámara . . . . . . . . . . . . . . . . . . . . . 161
7.6. Otras alternativas de realimentación sensorial . . . . . . . . . 168
ÍNDICE GENERAL ix
8. Hardware y modelado del helicóptero Quadrotor 171

8.1. Descripción del modelo del quadrotor . . . . . . . . . . . . . . 171
8.1.1. Descripción del modelo del UAV . . . . . . . . . . . . . 171
8.1.2. Planteamiento del modelo del sistema . . . . . . . . . . 172
8.2. Esquema general de control . . . . . . . . . . . . . . . . . . . 180
8.3. Descripción del equipo . . . . . . . . . . . . . . . . . . . . . . 181
9. Trabajos futuros y conclusión 184

9.1. Ampliaciones y otras alternativas para el control . . . . . . . . 184
9.1.1. Open Tracking Library . . . . . . . . . . . . . . . . . . 184
9.1.2. Lenguaje de comunicación de UAVs . . . . . . . . . . . 185
9.1.3. Ampliaciones con la librería OpenCV . . . . . . . . . . 187
9.1.4. Obtención de un controlador robusto mediante algorit-
mos genéticos . . . . . . . . . . . . . . . . . . . . . . . 188
9.1.5. Aplicación de técnicas de inteligencia artificial para el
control . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.2. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
A. Código desarrollado 194
B. OpenCV 196
B.1. Características de la versión 2.0 . . . . . . . . . . . . . . . . . 196
B.2. Configuración de OpenCV . . . . . . . . . . . . . . . . . . . . 196
B.2.1. Configuración en Ubuntu 9.10 . . . . . . . . . . . . . . 196
B.2.2. Configuración para Dev C++ en entornos Windows . . 202
B.3. Características de la versión 2.1 . . . . . . . . . . . . . . . . . 209
C. Interfaz de programación de la cámara 210
D. Diagrama temporal de Gantt. 214
E. Diagrama de clases de la aplicación 216

ÍNDICE GENERAL x
Índice de figuras
1.1. Ejemplo de esquema del diagrama de bloques para la estimación

y control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Sistema de sujeción del UAV para experimentos. . . . . . . . . 4
2.1. Ejemplo de rotor de una sola aspa. . . . . . . . . . . . . . . . 12

2.2. Ejemplo de configuración de 2 aspas por rotor. . . . . . . . . . 12
2.3. Detalle de las antenas receptoras del GPS del prototipo de la
Universidad de Standford “Hummingbird”. . . . . . . . . . . . 14
2.4. Helicóptero del proyecto AVATAR, de la Universidad de Sout-
hern California. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. Experimentos de vuelo en formación en el proyecto BEAR:
BErkeley Aerobot Research. . . . . . . . . . . . . . . . . . . . 15
2.6. Helicóptero de la Universidad Carnegie Mellon. . . . . . . . . 17
2.7. Brazo robótico del transbordador espacial. . . . . . . . . . . . 18
2.8. Titular de la revista Spectrum: “Lecciones del vertido del Golfo
para la Robótica”. . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9. Izquierda: Misiones espaciales no tripuladas. Derecha: Detalle
de UAV para aplicaciones militares. . . . . . . . . . . . . . . . 20
3.1. Ejemplo de cámara en mano. . . . . . . . . . . . . . . . . . . 22

3.2. Ejemplo de cámara fija (izquierda) embebida en parte inferior
del sistema de la derecha. . . . . . . . . . . . . . . . . . . . . 23
3.3. Eye-in-hand / Eye-to-hand cooperation. . . . . . . . . . . . . . 23
3.4. Sistema de cámaras estéreo. . . . . . . . . . . . . . . . . . . . 24
3.5. Control visual mirar y mover dinámico. . . . . . . . . . . . . . 26
3.6. Control visual directo. . . . . . . . . . . . . . . . . . . . . . . 27
3.7. Control visual basado en posición. . . . . . . . . . . . . . . . . 28
3.8. Control visual basado en imagen. . . . . . . . . . . . . . . . . 29
3.9. Control visual 2½D . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10. Control visual basado en movimiento. . . . . . . . . . . . . . . 32
3.11. Clasificación de los sistemas de control visual respecto al mo-
delo visuo-motor. . . . . . . . . . . . . . . . . . . . . . . . . . 35
xi
ÍNDICE DE FIGURAS xii
3.12. Ejemplo de detección de líneas en entornos urbanos. . . . . . . 37

3.13. Ejemplo de detección de líneas en una carretera. . . . . . . . . 37
4.1. Objeto de referencia utilizado en el presente proyecto. . . . . . 40

4.2. Representación del objeto por puntos. . . . . . . . . . . . . . . 42
4.3. Representación del objeto usando formas geométricas básicas. 43
4.4. Representación del objeto usando contornos y siluetas. . . . . 43
4.5. Representación del objeto como modelo articulado. . . . . . . 44
4.6. Representación del esqueleto de un objeto. . . . . . . . . . . . 44
4.7. Puntos de interés usando Harris. . . . . . . . . . . . . . . . . . 49
4.8. Puntos de interés usando KLT. . . . . . . . . . . . . . . . . . 50
4.9. Puntos de interés usando SIFT. . . . . . . . . . . . . . . . . . 51
4.10. Kernel Tracking. . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11. Evolución de contornos. . . . . . . . . . . . . . . . . . . . . . 54
4.12. Conjunto total de asociaciones de un punto. . . . . . . . . . . 55
4.13. Correspondencias correctas para un conjunto de puntos. . . . . 55
4.14. 1: Velocidad máxima. 2: Cambios pequeños en la velocidad. 3:
Restricciones comunes. 4: Geometría del objeto. . . . . . . . . 56
4.15. Seguimiento de características usando el algoritmo KLT tracker. 59
5.1. Modelo pinhole de la cámara. . . . . . . . . . . . . . . . . . . 62

5.2. Relación geómetrica-espacial entre el sistema de coordenadas
de la cámara y el sistema de coordenadas del objeto. . . . . . . 63
5.3. Representación de los parámetros intrínsecos de la cámara. . . 67
5.4. Ejemplo del efecto de la distorsión radial. . . . . . . . . . . . . 68
5.5. Representación vectorial ante un valor positivo de k1 . . . . . . 69
5.6. Representación vectorial ante un valor positivode p1 . . . . . . 69
5.7. Representación vectorial para un valor positivo de p2 . . . . . . 70
5.8. Distorsión tangencial. El plano de la imagen no es del todo
paralelo al de la lente. . . . . . . . . . . . . . . . . . . . . . . 70
5.9. Sistemas de coordenadas involucrados y nomenclatura. . . . . 71
5.10. Objetos de calibración planar y cúbico. . . . . . . . . . . . . . 73
5.11. Detalle de una de las capturas del objeto para la calibración. . 74
5.12. Detalle de corners en el objeto de calibración. . . . . . . . . . 79
5.13. Imágenes del tablero de ajedrez vistas desde varios puntos dis-
tintos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.14. Reconstrucción 3D teórica. . . . . . . . . . . . . . . . . . . . . 80
5.15. Reconstrucción 3D real. . . . . . . . . . . . . . . . . . . . . . 81
5.16. Cámara y plantilla de calibración con los correspondientes sis-
temas de coordenadas. . . . . . . . . . . . . . . . . . . . . . . 82
5.17. Localización automática de los puntos y origen del sistema de
referencia del objeto. . . . . . . . . . . . . . . . . . . . . . . . 84
ÍNDICE DE FIGURAS xiii
5.18. Situación de los puntos antes de realizar la corrección manual. 85

5.19. Situación de los puntos después de realizar la corrección manual. 85
5.20. Reproyección del conjunto de puntos sobre los puntos reales de
la imagen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.21. Detalle de la diferencia entre punto de la imagen real (rojo) y
punto reproyectado (azul). . . . . . . . . . . . . . . . . . . . . 87
5.22. Reproyección media del error. . . . . . . . . . . . . . . . . . . 87
5.23. Representación 3D de los parámetros extrínsecos (1). . . . . . 88
5.24. Representación 3D de los parámetros extrínsecos (2). . . . . . 88
6.1. Ejemplo de realidad aumentada. . . . . . . . . . . . . . . . . . 93

6.2. Herramienta de precisión necesaria para determinar la geome-
tría del objeto de interés. . . . . . . . . . . . . . . . . . . . . . 94
6.3. Ejemplo de localización de corners por intersección de rectas. . 95
6.4. Precisión en la localización de los corners, basado en el gradien-
te del punto en la imagen. . . . . . . . . . . . . . . . . . . . . 98
6.5. Representación de los ejes del sistema de coordenadas del objeto. 99
6.6. Reconstrucción 3D del objeto de interés. . . . . . . . . . . . . 103
6.7. Plantilla para experimentos en el laboratorio. . . . . . . . . . 104
6.9. Alineación de la cámara con la plantilla de referencia. . . . . . 105
6.8. Detalle de las marcas de medición en la plantilla. . . . . . . . 105
6.10. Situación inicial tablero (Izq). Situación final (Dcha). . . . . . 106
6.11. Centro real estimado del sistema de coordenadas de la cámara. 107
6.12. Situación inicial tablero (Izq). Situación final(Dcha).Se aprecia
desplazamiento en horizontal. . . . . . . . . . . . . . . . . . . 108
6.13. Posición inicial (Izq) y posición final (Dcha). . . . . . . . . . . 109
6.14. Marcas en la plantilla para medir la rotación. . . . . . . . . . 110
6.15. Experimentos para comprobar la rotación del tablero. . . . . . 110
6.16. Representación del objeto mediante formas geométricas básicas
para el cálculo de la homografía. . . . . . . . . . . . . . . . . . 114
6.17. Frame actual y deseado del sistema. . . . . . . . . . . . . . . . 116
6.18. Representación gráfica de la primera restricción. . . . . . . . . 120
6.19. Representación gráfica de la segunda restricción. . . . . . . . . 121
6.20. Selección manual del objeto. . . . . . . . . . . . . . . . . . . . 132
6.21. Obtención de la máscara de selección del objeto. . . . . . . . . 132
6.22. Detalle de la distorsión de la lente. . . . . . . . . . . . . . . . 134
6.23. Restricciones de un punto en Lucas Kanade. . . . . . . . . . . 135
6.24. Representación piramidal de una imagen. . . . . . . . . . . . . 136
6.25. Búsqueda piramidal con flujo óptico. . . . . . . . . . . . . . . 138
6.26. Estimación de los puntos usando la función cvCalcOpticalFlowPyrLK().139
6.27. Error en la estimación de los puntos del objeto. . . . . . . . . 139
ÍNDICE DE FIGURAS xiv
6.28. Ejemplo de la técnica template matching. Se desplaza la plan-

tilla de referencia hasta que el emparejamiento sea óptimo. . . 141
6.29. Reconstrucción parcial usando la matriz de homografía. . . . . 142
6.30. Píxeles con los que se realiza la comparación del valor de D
para encontrar máximos locales en SIFT. . . . . . . . . . . . . 145
6.31. Histogramas de orientación SIFT para el cálculo del descriptor.
En la imagen se muestra un ejemplo de tamaño 2x2 histogramas
(derecha) obtenidos a partir de una ventana de 8x8 (izquierda),
el extractor utiliza una ventana de 16x16, obteniendo 4x4 his-
togramas de descriptores. . . . . . . . . . . . . . . . . . . . . . 146
6.32. De izquierda a derecha: Las derivadas parciales de segundo or-
den de la Gaussiana en la dirección de ~y , en la dirección de
~ y las aproximaciones realizadas usando filtros de caja (box
xy
filters). Las regiones grises son igual a 0. . . . . . . . . . . . . 148
7.1. Detalle externo del sensor inercial. . . . . . . . . . . . . . . . . 152

7.2. Detalle interno del sensor inercial. . . . . . . . . . . . . . . . . 152
7.3. Diseño del acoplamiento entre la imu y la cámara. . . . . . . . 161
7.4. Acoplamiento real entre la cámara y el sensor inercial. . . . . . 162
7.5. Montaje para el proceso de calibración. . . . . . . . . . . . . . 164
7.6. Detalle del puntero láser sobre el centro de referencia. . . . . . 165
7.7. Detalle de la primera estimación para el centro de referencia
del sistema de la cámara. . . . . . . . . . . . . . . . . . . . . . 166
7.8. Detalle de la segunda estimación (definitivo) para el centro de
referencia del sistema de la cámara. . . . . . . . . . . . . . . . 167
7.9. Control de UAV mediante cámaras infrarojas. . . . . . . . . . 168
7.10. Vehículo aéreo de ala fija. . . . . . . . . . . . . . . . . . . . . 169
8.1. Esquema básico de funcionamiento del quadrotor. . . . . . . . 172

8.2. Conjunto de fuerzas sobre el modelo ideal del quadrotor. . . . 173
8.3. Detalle del helicóptero en miniatura. . . . . . . . . . . . . . . 182
8.4. Detalle de uno de los rotores integrados en el quadrotor, en fase
de pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.5. Equipo integrado on-board PC-104. . . . . . . . . . . . . . . . 183
8.6. Detalle de integración de los sensores inercial y óptico a bordo
del quadrotor. . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.1. Obtención del controlador de vuelo mediante algoritmos gené-

ticos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
9.2. Ejemplo de robots colaborativos. . . . . . . . . . . . . . . . . 190
B.1. Lista de servidores de versiones . . . . . . . . . . . . . . . . . 197

B.2. Creación del nuevo compilador. . . . . . . . . . . . . . . . . . 203
ÍNDICE DE FIGURAS xv
B.3. Inclusión de rutas en Directories→Binaries. . . . . . . . . . . 204

B.4. Inclusión de rutas en Directories→Libraries. . . . . . . . . . . 205
B.5. Inclusión de rutas en Directories→C includes. . . . . . . . . . 206
B.6. Inclusión de rutas en Directories→C++ includes. . . . . . . . 207
B.7. Optimización de código en Dev C++. . . . . . . . . . . . . . . 208
ÍNDICE DE FIGURAS xvi
Capítulo 1
Introducción
1.1. Introducción
Los vehículos aéreos autónomos, o como se conocen también por sus siglas
en inglés, UAV1.1 , han sido un área de investigación muy activa durante los
últimos años. Por ejemplo, el uso de UAVs en aplicaciones civiles de patrulla-
je, monitoreo o investigación [1] continúa en crecimiento debido en parte a la
evolución y reducción en el coste de los sistemas de visión.
La visión para el control de un UAV implica realizar un proceso de in-

vestigación en diversos campos relacionados tanto con el área de visión por
computador, como son la detección y seguimiento de objetos, estimación de
la posición, fusión sensorial de GPS1.2 y medidas inerciales, como otras áreas,
como son el modelado y control de sistemas multivariables no lineales.
Un helicóptero autónomo posee propiedades que lo convierten en la plata-

forma ideal para casi cualquier tarea. Su inherente habilidad de volar a baja
velocidad, estacionariamente, lateralmente e incluso realizar maniobras en es-
pacios reducidos [36] lo hacen el vehículo aéreo perfecto para las aplicaciones
mencionadas en el párrafo anterior.
Dichas habilidades son particularmente útiles en entornos conocidos y es-

tructurados donde las características u objetos a seguir visualmente están
definidos geométricamente, lo que facilita la estimación y el control basado en
visión.
1.1
Unmanned Aerial Vehicle, o vehículo aéreo no tripulado.
1.2
Global Positioning System o sistema de posicionamiento global.
1
1.1. Introducción 2
La realización de tareas por parte de sistemas automatizados o robotizados

en entornos estructurados con presencia de objetos cuya posición y orientación
son conocidas, es un problema que se ha tratado con profundidad durante las
últimas décadas ([15][27][28][103], entre otros). Sin embargo, si se considera el
uso futuro de los aviones no tripulados, donde la configuración del contexto
cambia continuamente, se pone de manifiesto lo vital que es la información
sensorial presente en el sistema [5].
La utilización de un sistema de visión en la realización de una tarea por

parte de un sistema automatizado, tiene la denominación genérica de Con-
trol Visual (Visual Servoing) ([20][23][39][41][51], entre otros). El sistema de
visión obtiene información visual de la escena en forma de características de
imagen, que son realimentadas al lazo de control del sistema. Un ejemplo es
el extraído de [3] y mostrado en la Figura 1.1, en el que la tarea del control
visual es realizada en un equipo en tierra (en la propuesta presentada en este
proyecto la tarea del control visual se lleva a cabo en el helicóptero).
Figura 1.1: Ejemplo de esquema del diagrama de bloques para la estimación

y control.
Los primeros estudios [70][74][75] aplicados sobre todo a procesos indus-

triales ante la presencia de sistemas robotizados, desacoplaban las acciones de
la extracción de imágenes y el control del robot, de tal manera que el contro-
lador, después de recibir la información visual y determinar la posición a la
cual moverse, ordenaba al robot a moverse a dicha posición asumiendo que no
se había producido ningún cambio en la escena, esto es, el entorno permanece
estático desde que el comando de movimiento fue ejecutado.
La ventaja de este tipo de control es su simplicidad, siendo ésta una de

las razones (entre otras) por la que tan sólo puede ser aplicable a sistemas
en los que la tarea a realizar esté determinada y no varíe (como es el caso de

un entorno industrial). En contraposición, el control visual tal y como queda
reflejado en la bibliografía ([31], entre otros), permite que el sistema de vi-
sión cierre el lazo de control: en cada ciclo la información visual del entorno o
de algún objeto de interés situado en la escena es actualizada de tal manera
que el controlador corregiría el movimiento a una nueva posición de destino.
Esta tarea se realiza bien de forma indefinida o hasta que el objeto a seguir ha-
ya desaparecido de la escena, con lo que se volvería a una posición por defecto.
Muchas publicaciones a lo largo de los últimos años muestran que las téc-
nicas de control visual1.3 incrementan la calidad (exactitud, robustez,etc) del
sistema [25][29][66]. La calidad del tracking 1.4 y del control depende del tipo
y número de características de la imagen que se utilizan, donde la redundan-
cia juega un papel muy importante [89] siendo esto habitual en las tareas de
control visual.
Otro aspecto importante es el número de cámaras utilizadas. En función

del mismo se utilizan unas técnicas para el control visual [42] u otras [22][93].
En el presente proyecto se ha optado por el uso de una única cámara, debido
principalmente a que es más fácil implementar técnicas para una configuración
monocular que una configuración de varias cámaras.
La propuesta presentada en esta memoria combina principalmente técnicas

de visión por computador, con un teórico control a bajo nivel para lograr el
control visual de un UAV por medio del seguimiento visual de características
en la imagen. El sistema de visión actúa pues como un controlador de alto
nivel enviando consignas de posición al control de vuelo, el cual es responsa-
ble de un control robusto y estable. El resultado de esta combinación es la
obtención de un algoritmo de seguimiento visual de características extraídas
de la imagen que controla los desplazamientos de un UAV, tanto en espacios
interiores como exteriores1.5 .
1.3
O por su traducción en inglés: Visual Servoing.
1.4
Equivale a la calidad del algoritmo de seguimiento.
1.5
Decir que en principio las pruebas de realizan en interiores, pero que el algoritmo es
para seguimiento de características en general.
1.2. Problemas en el control visual de vehículos aéreos autónomos 4
1.2. Problemas en el control visual de vehícu-

los aéreos autónomos
A pesar de que un UAV posee muchas ventajas para determinadas tareas,
tiene la desventaja de ser difícil de controlar. Esto se pone de manifiesto en
[32][52][54], entre otros. Los helicópteros son por naturaleza sistemas multi-
variable bastante inestables, donde el control de bajo nivel encargado de la
estabilidad debe ser capaz de afrontar esta condición. Si por algún motivo un
UAV dejara de recibir comandos de control, por pequeño que sea el período
de tiempo de esta particularidad, se volvería rápidamente inestable y se pre-
cipitaría hacia el suelo, con la correspondiente pérdida de equipo y dinero.
Esto provoca pues que el investigar con este tipo de plataformas sea una
tarea compleja y peligrosa. En numerosos estudios, para la realización de las
pruebas pertinentes del controlador, se suelen establecer medidas de seguridad
para evitar el anterior desenlace: sujeción con cables a una grúa o al techo,
sensores de infrarrojos para comprobar que la altura actual se mantiene entre
unos márgenes de seguridad, etc.
Figura 1.2: Sistema de sujeción del UAV para experimentos.
El problema del control visual sobre robots terrestres es un tema que ha

sido ampliamente estudiado durante las últimas décadas, y es un campo al
cual se han aportado numerosas contribuciones. Sin embargo, para sistemas
automatizados aéreos muchos problemas quedan aún pendientes de resolver.
Dichos problemas se acentúan si se tiene en cuenta que los vehículos aéreos
operan en un espacio tridimensional mucho más amplio que los robots terres-
tres, añadiendo que las capacidades y carga útil de los vehículos aéreos de
pequeña a media escala son mucho más limitadas que la de los robots móviles
terrestres.
Si pensamos además en que la capacidad de cómputo del sistema on-board

es directamente proporcional al peso del equipo y del consumo de éste, se
plantea la necesidad de estimar las características adecuadas para soportar
toda la lógica del controlador y del sistema de cómputo para la resolución de
algoritmos basados en visión.
En este aspecto, los sensores ópticos actuales suelen ser livianos y eficientes
en lo que se refiere al consumo de energía. Con el aumento en la miniaturi-
zación de los sensores CCD1.6 y CMOS, la visión por computador ofrece su
potencial a los MAUV (Micro Air Unmanned Vehicles). Al contrario que los
sensores de escaneado o de barrido laterales, como los láseres, las cámaras
toman muestras instantáneas del entorno, lo que es óptimo para este tipo de
plataformas dinámicas.
Pero no todo son ventajas al usar este tipo de sensores; ante cambios en las
condiciones lumínicas, la calidad de las tomas capturadas disminuye, usual-
mente hasta que el sensor se adecua a las mismas. Incluso aunque todas las
condiciones para la captura de imágenes sean las idóneas, existe el problema
subyacente de la interpretación de la escena y de la extracción de la informa-
ción relevante de ella.
La visión en humanos es considerada eficiente en su interpretación y un

mecanismo casi perfecto; incluso en condiciones extremas, el ser humano es
capaz de extraer información de la escena y darle sentido, como por ejemplo,
la profundidad o distancia a los objetos. Para un ordenador, éste no es el caso.
Aunque se haya evolucionado mucho en el tema, y la extracción de infor-

mación 3D de la escena haya alcanzado niveles de precisión y detalle más que
aceptables, siempre se puede dar el caso de que las cámaras generen datos
dispersos y propensos al ruido.
1.6
Un CCD (siglas en inglés de charge-coupled device: ‘dispositivo de carga acoplada’) es
un circuito integrado que contiene un número determinado de condensadores enlazados o
acoplados
Así pues, el problema del control visual para un vehículo aéreo autónomo
puede ser descrito como:
Desarrollo del sistema de visión : Éste a su vez puede ser subdividido en:
Configuración del hardware apropiado para acometer la tarea del

procesamiento visual a bordo del helicóptero.
Desarrollo de la arquitectura de software para comunicar la capa
de controladores con la de procesamiento visual.
Algoritmos de detección y seguimiento de características :

En el presente trabajo se han desarrollado varias propuestas, basadas en
diferentes consideraciones del objeto de control.
Fusión sensorial :
Cómo integrar la información visual y la de los demás sensores on-board,
como pueden sensores inerciales, GPS u otros, y la definición del esquema
más adecuado en el cual las referencias visuales sean integradas en el
control de vuelo.
Desarrollo del controlador adecuado :

Dadas las ecuaciones que gobiernan la dinámica del helicóptero, se trata
de diseñar un controlador robusto usando como realimentación la infor-
mación sensorial anterior con los datos de los sensores óptico e inercial,
para el seguimiento de una determinada trayectoria u objeto de interés.
1.3. Objetivos y propuestas 7
1.3. Objetivos y propuestas
En este proyecto se aborda el problema del control visual partiendo de la

premisa de la existencia de un controlador robusto a bajo nivel para el control
de estabilización del quadrotor1.7 . A dicho controlador, o a una modificación
del mismo, se introduce la información visual para controlar la trayectoria del
vehículo por medio de la detección y seguimiento de características en el plano
de la imagen.
Usando técnicas desarrolladas en posteriores capítulos, se espera que el

quadrotor sea capaz de realizar desplazamientos 2D/3D basados en visión,
siguiendo las características definidas manualmente o seleccionadas de forma
automática, y usando su ubicación en la imagen para controlar las maniobras
del mismo. Los métodos para la localización y seguimiento del objeto de refe-
rencia son vistas en detalle en el capítulo 4.
La propuesta de control visual (que se verán en detalle en el capítulo 3)

que se ha seleccionado para ser implementada es la de control visual basado en
posición (PBVS Position Based Visual Servoing). Para el esquema de control
visual basado en imagen (IBVS Image Based Visual Servoing) es necesario un
controlador distinto al existente del planteado en [52] (el cual es el controla-
dor usado para la estabilización del quadrotor), por lo que no se plantea su
implementación en el presente proyecto.
Se aborda el problema gracias a que se desacopla el control a bajo nivel

(con lo que permite un desarrollo paralelo al óptico-sensorial) del sistema vi-
sual. El control a bajo nivel mantiene el quadrotor estable, mientras que en el
controlador de alto nivel se considera al vehículo como un punto flotante en
el espacio (cuyo origen de coordenadas coincide con el centro geométrico del
quadrotor1.8 ), el cual puede ser controlado mediante referencias de velocidad,
posición y cambios de orientación.
Prácticamente la mayor parte del código desarrollado ha sido implementa-

do en el lenguaje de programación C++, usando la librería de procesamiento
de imágenes OpenCV, en su versión 2.0. La plataforma de desarrollo ha sido
Ubuntu 9.10, sistema basado en UNIX. Más información de todo lo referente
al desarrollo es dada en el Apéndice B.
1.7
Es necesario aún realizar experimentos con el controlador propuesto en la actualidad.
1.8
Más concretamente el origen del sistema de coordenadas del quadrotor será un punto
intermedio entre el origen de coordenadas del sensor óptico y del sensor inercial.
1.4. Estructura del proyecto 8
1.4. Estructura del proyecto
Dado que en el presente proyecto se han mezclado temáticas de muy diver-

sa índole, es necesario exponer de forma detallada algunas de ellas para poder
generar una memoria autocontenida y completa.
En una sola frase, se han mezclado conceptos de procesamiento digital de

imágenes (algoritmos de localización y seguimiento), con conceptos de control
de vehículos aéreos autónomos (basados o no en control visual) incluyendo
además el modelo del controlador usado para garantizar la estabilidad del
quadrotor; sin olvidar la formulación del modelo de la cámara, algoritmos pa-
ra la calibración de la misma; fusión sensorial entre los datos de la cámara con
los del sensor inercial (IMU), cuestiones relacionadas con geometría proyectiva
incluyendo además la descomposición de la matriz de homografía, y, además,
la realización de experimentos en el laboratorio. Es por esto necesario un de-
talle en profundidad de algunas de las temáticas expuestas anteriormente.
La presente memoria queda estructurada como sigue:
En el capítulo 2 se describe brevemente el estado del arte del control de

vehículos aéreos autónomos (sin usar información visual), y una breve
reseña histórica del control visual (en el que se hace uso de información
visual) aplicado a vehículos aéreos autónomos. Además se presentan apli-
caciones reales en las que la plataforma principal es un UAV con parte
de control visual.
En el capítulo 3 se describe el estado del arte del control visual para

UAV y las distintas alternativas presentes en la literatura.
En el capítulo 4 se desarrollan de forma teórica los métodos presentes en

la literatura para la localización y el seguimiento del objeto de referencia.
En el capítulo 5 se desarrolla todo el contenido relacionado con el proceso

de calibración de la cámara, necesario para los experimentos llevados a
cabo en el presente trabajo. Se exponen de forma teórica los conceptos
clave y se presentan los resultados obtenidos de dicho proceso.
En el capítulo 6 se presentan todas las propuestas para la extracción

de la información visual necesaria para cerrar el lazo del control que se
han implementado y de las cuales se han realizado experimentos en el
laboratorio. Principalmente se clasifican en dos grupos: modelando el
objeto como un objeto tridimensional y modelándolo como un objeto
plano. Se exponen también otras técnicas desarrolladas en fases iniciales

pero que finalmente fueron descartadas por diversos motivos.
Cómo fusionar información del sensor inercial con la información visual

se expone en el capítulo 7.
En el capítulo 8 se presenta el sistema de control realimentado para

el quadrotor. También se incluye una descripción de la dinámica del
sistema.
En el capítulo 9 se exponen posibles ampliaciones relacionadas tanto con

el desarrollo de nuevas metas para el controlador de vuelo de los UAVs
como del desarrollo de nuevos métodos para el control visual, incluyendo
además una sección dedicada a las conclusiones tras la realización del
presente proyecto.
En los Apéndices se presenta el código desarrollado a lo largo de la

realización del proyecto, incluyendo además algunas nociones para la
configuración de la librería para el procesamiento de imágenes OpenCV.
Se muestran también el conjunto de funciones de la librería de la cámara
utilizadas, incluyendo además un diagrama de clases de la aplicación y
un diagrama temporal de Gantt que recoge toda la planificación tempo-
ral del presente proyecto.
Capítulo 2
Estado del arte del control de

plataformas UAV
2.1. Introducción
Como se ha comentado con anterioridad y puede observarse también en el

capítulo dedicado a aplicaciones, los vehículos aéreos autónomos han sido un
área de investigación que durante los últimos años ha experimentado un gran
avance, por múltiples motivos. Las más prestigiosas universidades están ac-
tualmente investigando y desarrollando plataformas experimentales de vuelo
no tripuladas y autónomas. Este tipo de plataformas, como se puede ver en
[32][52][54] suelen ser utilizadas para el estudio de controladores no lineales,
control multivariable, navegación, detección y seguimiento visual de objetos e
incluso planificación de trayectorias.
Dentro de la amplia variedad de vehículos aéreos autónomos, cabe destacar

la maniobrabilidad de los helicópteros, y dentro de esta familia, aquellos que
poseen cuatro rotores en el mismo plano (quadrotores coplanares2.1 ). A su
vez, dentro de esta familia existen dos variantes: aquellos en cuyo rotor existe
tan solo un aspa girando en una única dirección, y aquellos equipos cuyos
rotores están equipados con dos aspas girando cada una en sentido contrario.
En el presente proyecto se trabaja bajo la suposición de la existencia de un
controlador para un helicóptero quadrotor coplanario con una única aspa por
rotor. Véanse en las Figuras 2.1 y 2.2 ejemplos de este tipo de configuraciones.
2.1
Este es el tipo de plataforma con la cual se ha experimentado en el presente proyecto.
11
Figura 2.1: Ejemplo de rotor de una sola aspa.
Así pues, su inherente capacidad de volar a bajas alturas y velocidades,

desplazarse lateralmente y longitudinalmente, realizar vuelos estacionarios2.2
y maniobrar en espacios reducidos los hacen los vehículos ideales para tales
tareas. Tareas comunes suelen ser las que requieran que el vehículo vuele a
baja altura o se mantenga en vuelo estacionario próximo a un determinado
punto u objeto de interés.
Figura 2.2: Ejemplo de configuración de 2 aspas por rotor.
Esta proximidad en el vuelo, si no consideramos la realimentación visual, se

realiza usando medidas del sensor inercial y/o medidas de GPS, lo que limita
y bastante el vuelo a un conocimiento previo de la posición global del aparato
y de la existencia de un ruta preprogramada de coordenadas. Si se añade al
control realimentación visual, en tiempo real que pueda controlar el helicópte-
ro en una trayectoria arbitraria no sujeta a restricciones, y fusionándola con el
resto de medidas, podemos aumentar la precisión en vuelos cercanos a objetos,
2.2
En lengua inglesa se refiere a este término como hoovering.
2.2. Control no basado en visión de vehículos aéreos autónomos 13
permitiendo conocer la posición relativa del vehículo respecto del objeto de

interés.
El desarrollo de un vehículo aéreo autónomo guiado por visión requiere

de diversas disciplinas de la Ingeniería; desde investigar en áreas como Teoría
del Control hasta la detección y seguimiento de objetos mediante visión por
computador.
Se presenta pues a continuación un amplio repaso del estado del arte del
control (sin realimentación visual) en UAV para posteriormente exponer el
estado del arte actual del control visual para vehículos aéreos no tripulados.
Todo lo relativo a la localización y seguimiento de objetos se presenta en pro-
fundidad en el capítulo 4.
2.2. Control no basado en visión de vehículos

aéreos autónomos
El origen del estudio del control en el campo de los helicópteros autónomos

tiene su origen varias décadas atrás. El modelo del sistema dinámico que lo
representa ha sido ampliamente documentado ([2][3][20][31][52], entre otros),
donde se presenta en detalle un estudio sobre el modelo aerodinámico y de
análisis de estabilidad. Dada la inestabilidad propia de este tipo de vehículos,
los primeros estudios se centraban en obtener un controlador para hacer esta-
ble al sistema.
En [52], por ejemplo, se documenta el diseño de un control realimentado

robusto basado en H∞ , al igual que en [1] se presenta un controlador basado
en lógica difusa para la estabilización de un SUAV (Small UAV). Otras alter-
nativas para el control pueden consultarse en [2][6][9] ó [32], entre otros.
De entre los primeros estudios, como el presentado en [37], se muestra la

particularidad de solo usar el GPS como sensor principal para la navegación
sustituyendo a la unidad de medida inercial (IMU), la cual, y por historia, es
el sensor que se había usado como principal. Este sistema estaba dotado de un
GPS con 4 receptores y 4 antenas colocadas en puntos estratégicos del apa-
rato, con lo que se conseguía su posición, velocidad, actitud2.3 e información
angular. Probablemente tuvieran algunos problemas por mantener las antenas
2.3
Se denomina actitud al ángulo de vuelo que lleva el avión con respecto al horizonte.
separadas una distancia relativamente tan pequeña (del orden de cm). En la

imagen de la Figura 2.3 se pueden observar en detalle las antenas receptoras
de la unidad de GPS.
Figura 2.3: Detalle de las antenas receptoras del GPS del prototipo de la
Universidad de Standford “Hummingbird”.
Otra configuración, la denominada proyecto AVATAR y presentada en [38],

posee una arquitectura jerárquica de módulos de control, también presentada
en [2][31][47][54] (entre otros). Los módulos de bajo nivel se encargan de tareas
de rápida respuesta como el control de los rotores o movimiento del grupo alar,
mientras que los módulos de alto nivel se encargan de tareas de planificación
y navegación. El control propuesto se ha diseñado con leyes de control lineal
usando controladores de tipo PID. Los sensores presentes en esta plataforma
son el GPS, IMU, brújula y sónar, entre otros.
Figura 2.4: Helicóptero del proyecto AVATAR, de la Universidad de Southern

California.
Otra propuesta es la presentada en [40], la cual presenta un control basado

en H∞, que usa un modelo lineal de alto orden sobre una plataforma comercial
(equipo Yamaha). El controlador consiste en un lazo interno multivariable para
la estabilización de la actitud y 4 lazos de control separados para posición y
velocidad. En [46] se presenta un sistema de control jerárquico usado en el
helicóptero BErkeley AeRobot Project (BEAR) [44] (Figura 2.5).
Figura 2.5: Experimentos de vuelo en formación en el proyecto BEAR: BEr-

keley Aerobot Research.
En primer lugar, se identifica la dinámica del sistema y posteriormente se

diseñan las leyes de estabilización. El controlador consta de tres lazos: el pri-
mero para el control de la actitud, el segundo para el control de la velocidad,
y el tercero para el control de la posición. Para mejorar la fase de navegación
y seguimiento de trayectorias se usa un control NMPTC 2.4 .
Recientes avances en el control y modelado han permitido extender las ca-

pacidades de vuelo, realizando incluso vuelos acrobáticos. Un ejemplo de este
tipo de sistema es el presentado en [36]. En este sistema, según se describe, dos
tipos de controladores son usados, dependiendo de la fase de vuelo o envolven-
te de vuelo2.5 . Un control velocidad/orientación rate/altitud se usa al inicio
y al final de la envolvente de vuelo, mientras que un control de aceleración
angular se usa para las maniobras acrobáticas.
2.4
Siglas inglesas para Nonlinear Model Predictive Trajectory Controller.
2.5
Todos los aviones tienen limitaciones físicas: no pueden volar demasiado despacio, o
entrarían en pérdida; ni demasiado rápido, ya que, o maniobran dentro de sus parámetros
específicos o se volverían inestables e imposible de maniobrar.
2.3. Control con información visual de vehícu-

los aéreos autónomos
Se puede decir que la visión por computador es una de las áreas más im-
portantes en el mundo actual de la robótica. Hace relativamente pocos años,
las capacidades hardware de los equipos empotrados no permitían la puesta
en marcha de aplicaciones visuales sofisticadas. Éste era el principal obstáculo
que evitaba que el control visual tuviera el desarrollo que ha tenido estos años
atrás. Pero tras la introducción de nuevas arquitecturas hardware y de proce-
sadores más rápidos y con soporte para programación paralela, y de cámaras
cuyas características crecen exponencialmente con coste lineal, la potencial
ubicuidad del control visual se ha hecho una realidad.
Cuando se presentan términos como control visual aplicados a vehículos

aéreos autónomos, se hace referencia al uso de la información visual del proce-
samiento de imágenes para el control de velocidad, posición absoluta o relativa,
o para el control de la orientación. Al igual que la literatura sobre el control
visual contempla el término cámara-en-mano (eye-in-hand) para ciertas confi-
guraciones en robots articulados, para el caso de vehículos aéreos robotizados
el término adecuado sería el de cámara a bordo (on-board camera) [20][63].
Uno de los primeros experimentos (Figura 2.6) en los que se describe un

helicóptero guiado por visión se describe en [47]. Este vehículo autónomo fu-
siona las lecturas GPS con un sistema de visión, con la finalidad de aumentar
la precisión de la estimación del estado para la navegación.
El sistema de visión consiste en un procesador DSP2.6 que proporciona me-

didas de posición, velocidad y actitud a frecuencias de 10ms, lo que combinán-
dolo con las lecturas del GPS y la IMU aumenta la precisión en la estimación
de la actitud y de la posición del helicóptero.
2.6
O por sus siglas en español Procesador Digital de Señales.
Figura 2.6: Helicóptero de la Universidad Carnegie Mellon.
En [59] se enfoca el uso de una cámara como sensor adicional para la nave-
gación del helicóptero autónomo para el caso particular del aterrizaje. Dada
una secuencia de imágenes tomadas por la cámara se consigue una estimación
del movimiento tridimensional de la misma, la cual se fusiona con la informa-
ción inercial.
El control visual también se ha aplicado a vehículos en miniatura, en el

caso del helicóptero HMX-4 o Draganflyer de cuatro rotores coplanarios [31],
donde la visión se usa para determinar la disposición del helicóptero y para la
detección de objetos en tierra. Existen muchas propuestas presentadas en la
literatura sobre el control basado en visión.
La más interesante, desde el punto de vista del redactor del presente docu-
mento, es el caso de navegación tridimensional presentado en [48], en la cual
se propone una técnica que combina flujo óptico con visión estereoscópica. Si
se combina esta técnica con mapas probabilísticos y un planificador de trayec-
torias, y según demuestran en varios experimentos, es posible la navegación
de un UAV en entornos urbanos de forma completamente autónoma.
2.4. Aplicaciones del control visual en plataformas autónomas 18
2.4. Aplicaciones del control visual en plata-

formas autónomas
En este proyecto tan solo se han considerado alternativas que vuelan, o

al menos, lo intentan. Todas las técnicas relativas al control visual pueden
aplicarse a otro tipo de plataformas, como por ejemplo, los brazos robóticos
que operan en el transbordador espacial (Figura 2.7), robots móviles, o incluso
a robots sumergibles que se encarguen de tareas de rescate o reparaciones a
grandes profundidades.
Figura 2.7: Brazo robótico del transbordador espacial.
En el número de Septiembre de 2010 de la revista Spectrum (Figura 2.8),

publicada por el IEEE (Institute of Electrical and Electronic Engineers), ante
la reciente tragedia medioambiental del Golfo de México, en el que una es-
tación de extracción de crudo en alta mar explosionó, provocando la mayor
catástrofe medioambiental de la historia de los EEUU, se ha puesto de mani-
fiesto la necesidad de técnicas más avanzadas de robótica autónoma.
Esto es debido a que la profundidad a la que se encontraba una tubería

que continuamente expulsaba crudo era imposible de sellar in situ por ningún
sumergible tripulado. Si se hubieran dado las circunstancias en las que, un
posible conjunto de vehículos sumergibles autónomos se hubieran coordinado
para poder sellar la fuga, probablemente no se hubieran puesto en peligro ni
Figura 2.8: Titular de la revista Spectrum: “Lecciones del vertido del Golfo
para la Robótica”.
vidas humanas ni tantos kilómetros de litoral norteamericano.
La lista de aplicaciones es bastante larga, pero en esta sección se van a dar

algunos ejemplos de desarrollos ya construidos y en funcionamiento.
Vehículo Áereo Áutónomo para investigación polar :

Presentado en [1], en este artículo se presenta una aplicación no menos
curiosa en la que un UAV puede ser muy útil. Debido a que la clima-
tología en los polos de la Tierra impide, la mayor parte del año, que
equipos de investigación sobre el terreno puedan recoger muestras, se
propone un vehículo autónomo para la investigación polar. Para obte-
ner precisión de altitud, fusionan información sensorial del GPS con la
de un algoritmo de filtro adaptativo de Kalman. Implementan un tipo
de controlador que permite que la aeronave pueda sobrevolar cualquier
zona incluso en situaciones en las que el viento sea un grave problema.
Inspección de líneas e instalaciones eléctricas :

Normalmente, para este tipo de tareas, se suele utilizar un helicóptero
con personal humano a bordo, para documentar in situ el estado de las
líneas eléctricas. Pero debido a que las propias líneas eléctricas son un
peligro para el vuelo de estas aeronaves, en los últimos años las compa-
ñías eléctricas están aunando esfuerzos con el mundo universitario para
investigar y desarrollar plataformas aéreas no tripuladas para este tipo
de funciones. El seguimiento visual sería relativamente sencillo, aplican-
do por ejemplo como detector de segmentos o líneas rectas, también
aplicado en [112], para el seguimiento de una carretera por parte de un
UAV.
Misiones espaciales no tripuladas :

Este pudiera ser el ejemplo más llamativo de todos (Figura 2.9 izquier-
da). De sobra es conocido las misiones de la NASA2.7 hacia el planeta
Marte, en la que actualmente disponen de dos vehículos terrestres de in-
vestigación. Dichos vehículos son completamente autónomos, en el sen-
tido de que no son operados desde Tierra, debido principalmente a los
problemas de las comunicaciones. Por ello, es de suponer que disponen
de técnicas de control visual relativamente complejas para la localización
de obstáculos.
Misiones militares :
Otra de las aplicaciones de vehículos aéreos no tripulados tienen carác-
ter militar. Situaciones en las que se desea simplemente determinar el
estado del terreno; aquéllas en las que no se desean pérdidas de vidas hu-
manas, etc. Últimamente los ejércitos de los países más avanzados están
equipando a sus plataformas UAV con misiles de corto y largo alcance,
para misiones tácticas o de destrucción de infraestructuras estratégicas.
Simplemente al iniciar el explorador web, e introducir en cualquier bus-
cador la palabra UAV y buscar por imágenes, las primeras obtenidas de
la búsqueda son como la mostrada en la Figura 2.9 derecha.
Figura 2.9: Izquierda: Misiones espaciales no tripuladas. Derecha: Detalle de

UAV para aplicaciones militares.
Aplicaciones desde el campo de la medicina y técnicas quirúrgicas, hasta

el campo de la tele-asistencia, pasando por control del tráfico rodado,... Los
campos de aplicación de técnicas de control visual son amplios y muy variados.
2.7
National Aeronautics and Space Administration.
Capítulo 3
Técnicas de control con

realimentación visual
3.1. Introducción
El término control visual se introdujo en el artículo [75] en 1979 para re-

emplazar al término de “Realimentación Visual” que era más específico y de
uso muy generalizado. A partir de 1980 se introducen las primeras descripcio-
nes del control visual, y en publicaciones de años posteriores, se consolida la
diferencia entre los dos principales y grandes esquemas de control visual como
son el control visual basado en posición (PVBS) y el control visual basado en
imagen (IBVS).
Desde principios de los años 90 hasta la presente década los avances en el

control visual se han incrementado enormemente cumpliendo con los requisitos
de tiempo real que exigen las aplicaciones, superando los problemas de retardo
y la comunicación entre procesos. Las principales razones de este adelanto han
sido entre otras las siguientes:
La potencia y bajo coste de las unidades de cálculo.
La disponibilidad de sensores ópticos de elevadas prestaciones.
El desarrollo de las librerías de procesamiento de imágenes digitales.
A continuación se detalla el estado del arte del control visual en general, co-
menzando por las diversas configuraciones entre la cámara y el robot y luego
por los esquemas de control propuestos.
21
3.2. Configuraciones cámara-robot 22
3.2. Configuraciones cámara-robot
Esta configuración está dividida según dos criterios: la posición de la cá-

mara con respecto al robot y el número de cámaras.
3.2.1. Según la disposición de la cámara respecto del

robot
Cámara en mano :
En este caso la cámara está montada en el brazo del robot (Figura 3.1) y
se mueve a la par del movimiento del mismo. En esta configuración existe
una relación constante entre el sistema de coordenadas de la cámara y el
sistema del efector final del robot. Algunas aplicaciones requieren más
de una cámara como en [78]. Una característica de esta configuración es
que se pueden obtener imágenes de regiones particulares de la escena, es
decir imágenes de carácter parcial [71] donde la resolución efectiva de la
escena puede ser incrementada, siempre que sea necesario.
Figura 3.1: Ejemplo de cámara en mano.
Cámara fija :
En esta segunda disposición (Figura 3.2) se tiene una o varias cámaras
fijas en algún punto del espacio de trabajo de tal manera que la escena
es observada desde el sistema de la cámara. La relación entre el sistema
de coordenadas de la cámara y de la base del robot es constante, de tal
manera que la posición de la cámara es independiente del movimiento
que el brazo del robot pueda efectuar.
Figura 3.2: Ejemplo de cámara fija (izquierda) embebida en parte inferior del
sistema de la derecha.
Al contrario que la configuración anterior, de cámara en mano, en esta

configuración se obtienen imágenes de casi toda la escena, aunque con
menor precisión. En esta opción se pueden realizar operaciones propias
de una cámara fija motorizada tales como son el pan3.1 , tilt3.2 o el zoom,
conocidas también como función PTZ3.3 .
Modelo Híbrido :
Es una combinación de las anteriores configuraciones donde se aprovecha
la información de la imagen local que da la configuración cámara en
mano y la información de la imagen global de la cámara en configuración
cámara fija. En algunos ejemplos, como en [70][71] se realizan dos tareas:
una de posicionamiento y otra de seguimiento y en [73] se implementa
un sistema donde la cámara fija es sostenida por otro robot.
Figura 3.3: Eye-in-hand / Eye-to-hand cooperation.
3.1
Hacer girar la cámara en todo el plano panorámico.
3.2
Inclinación de la cámara.
3.3
Por sus siglas en inglés, Pan Tilt Zoom.
3.2.2. Según el número de cámaras
Sistema de cámara única :

Se utiliza una sola cámara en el sistema, de esta manera se minimiza la
tarea del procesamiento visual requerida, pero la pérdida de información
para la profundidad complica el diseño del control. Dicho parámetro de
profundidad puede ser estimado con anterioridad [70], adaptativamente
[74], o a través de alguna información métrica del objeto a controlar. La
configuración cámara en mano es la más utilizada, debido principalmente
a la sencillez en su implementación y su bajo costo.
Sistema de dos cámaras :
Conocido también como sistema estéreo, se tienen dos vistas simultáneas
de la escena [79] (Figura 3.4). Esta técnica tiene la principal ventaja de
que se puede obtener cierta percepción tridimensional, además de poder
utilizarse las propiedades de la geometría epipolar [78].
Figura 3.4: Sistema de cámaras estéreo.
Sistema de cámaras redundantes :

Para esta configuración se tienen más de dos cámaras. Se aprovecha pues
la ventaja de tener redundancia de características visuales que añade
robustez al sistema, aunque se incrementa el tiempo de procesamiento.
Una aplicación con tres cámaras se presenta en [84] donde se demuestra
su eficacia ante oclusiones parciales en una tarea de seguimiento3.4 del
objeto de referencia.
3.4
También denominado “tracking” de un objeto. Se profundiza en el presente capítulo.
3.3. Esquemas de control visual 25
3.3. Esquemas de control visual
En función del enfoque desde el cual se mire, se tienen distintas clasifica-

ciones :
La estructura de control del sistema electromecánico.
La información visual.
La observación de las características en la cámara.
Modelo 3D del objeto.
3.3.1. En función de la estructura de control
“Mirar y mover” estático :

En este esquema de control la extracción de información visual y el con-
trol del robot son dos tareas desacopladas, donde en primer lugar se
extraen y procesan las características de la imagen, perteneciendo esta
tarea a un bucle externo más lento, y después se ejecuta la tarea de
control del robot, estando esta tarea integrada en un bucle interno de
control más rápido. El robot posteriormente ejecuta el movimiento, asu-
miendo que el entorno permanece estático.
Al no existir realimentación visual dinámica, este esquema de control

se dice que no pertenece al control visual. También suele denominarse
control visual indirecto estático siempre y cuando los bucles de control
y extracción de información operen de forma secuencial.
“Mirar y mover” dinámico :

En este esquema de control el resultado de la realimentación visual ali-
menta al controlador interno que se encarga de posicionar el robot. Tam-
bién se suele denominar como control visual indirecto dinámico en el caso
particular de que las dos tareas desacopladas trabajen en paralelo ( la
información está presente en todo momento ). El controlador del robot
trabaja a bajo nivel por lo que su ciclo de control (menor que 10 ms.)
deberá ser mayor que el del controlador visual (del orden de 40 ó 50 ms.).
Tanto el controlador del robot como el controlador visual están desaco-

plados, lo que simplifica mucho el diseño del control, aliviando de este
modo al controlador visual de tener que afrontar las parte no lineal y la
parte dinámica del robot. Muchos robots poseen su propio controlador
que aceptan coordenadas cartesianas o posiciones incrementales. Como
consecuencia, la mayoría de los sistemas implementados en la actualidad
son del tipo mirar y mover dinámico.
Figura 3.5: Control visual mirar y mover dinámico.
Experimentalmente se demuestra que la integración de la realimenta-

ción visual dentro del controlador permite una operación eficiente y de
convergencia rápida, a pesar de errores en la calibración de la cámara o
del modelo de movimiento.
Control visual directo :

En este esquema el controlador (con un ciclo de control muy rápido, infe-
rior a 10 ms.) convierte directamente la información visual en consignas
de control a los actuadores en forma de pares aplicados a las articulacio-
nes del robot. A este control comúnmente se le suele llamar como control
servo visual.
Figura 3.6: Control visual directo.
3.3.2. En función de la información visual

También conocida como clasificación en función de la definición del error.
Control visual basado en posición :

También llamado control visual 3D (PBVS Position Based Visual Ser-
voing), las características visuales de la imagen son utilizadas para calcu-
lar la posición y orientación del objeto de control en el espacio cartesiano,
donde se considera el modelo geométrico del objeto (dimensiones reales),
el modelo de la cámara (representado por la matriz de parametros in-
trinsecos de la cámara3.5 ) y la relación geométrica cámara robot, lo que
provoca que sea muy sensible a perturbaciones [83].
La función de error (función de error cinemático [82]), que es la dife-

rencia entre la posición y orientación actual del objeto y su posición
3.5
Obtenido del proceso de calibración de la cámara. Presentado en el capítulo 5.
y orientación deseada, se define en un espacio cartesiano 3D [42], por

lo que la trayectoria del objeto se controla directamente en un espacio
tridimensional [24]. En este esquema de control se asume que el modelo
considerado del objeto de referencia es ideal; en caso contrario el control
se deteriora.
Figura 3.7: Control visual basado en posición.
Puesto que la inexactitud en la estimación de la posición y orientación

del objeto no pueden ser calculadas analíticamente en función de los
errores de calibración y de las perturbaciones de las medidas, es comple-
jo demostrar analíticamente la estabilidad del sistema en presencia de
errores en el modelo.
Dadas las condiciones para la reconstrucción tridimensional, existen mu-

chas propuestas de implementación del PBVS en sistemas estéreo de dos
cámaras. Incluso con más cámaras, como en [81], donde se usan tres
cámaras fijas junto con el filtro de Kalman extendido para estimar la
posición y orientación del objeto.
Control visual basado en imagen :

También conocido como control visual basado en características (IBVS
Imagen Based Visual Servoing [42]), o control visual 2D. En esta estra-
tegia de control la función de error y la ley de control están definidas
directamente en el plano 2D de la imagen y no es necesario un conoci-
miento previo del modelo tridimensional del objeto [111]. Básicamente
la tarea de control trata de reducir una medida de distancia entre la

posición actual y deseada del objetivo en la imagen. Esta técnica es muy
robusta ante los posibles errores en la definición del modelo de los obje-
tos, además de reducirse el tiempo de ciclo de control.
Figura 3.8: Control visual basado en imagen.
En muchos artículos consultados, como en [85], se comprueba experi-

mentalmente que este esquema de control es robusto frente a errores
tanto de la calibración interna de la cámara como de la posición relativa
del objeto. El control visual puede realizarse estimando [86] el jacobiano
de la imagen o calculándolo analíticamente [51].
Si se opta por el cálculo analítico, será necesario, en primer lugar realizar

la calibración de la cámara fuera de línea; en segundo lugar estimar la
relación geométrica cámara-robot, y por último estimar la profundidad
(la coordenada Z) a la que se encuentra la característica considerada en
el espacio tridimensional. Por el contrario, si se opta por una estimación
en línea, ya no será necesario conocer ninguno de estos parámetros, por
lo que será robusto tanto a errores de calibración de la cámara como de
la calibración del robot [42].
Un esquema de control IBVS posee estabilidad asintótica local cuando

el número de características en la imagen es al menos 6, como queda de-
mostrado en [51]. En [27][111] y otros se presenta un control visual 2D
basado en homografías, en el que no se necesita ninguna medida de la
estructura 3D del objeto observado, y utiliza el principio de isomorfismo

con la imagen de referencia para el cálculo de la posición y orientación
de la cámara. Además, se comprueba en la práctica la estabilidad local
de la ley de control propuesta, no pudiéndose garantizar la estabilidad
asintótica global. Otro ejemplo es el dado en [87], donde se realiza con-
trol visual basado en imagen utilizando coordenadas cilíndricas de los
puntos en la imagen.
Control visual híbrido :

En este esquema de control se aprovechan las ventajas de los métodos
basados en imagen y de los basados en posición, seleccionando adecuada-
mente las características visuales. Existe por lo tanto una combinación
entre los esquemas de control PBVS e IBVS, en el que se desacoplan
además las componentes de traslación y rotación. La ley de control está
descrita en función de las características de la imagen y de algunos pa-
rámetros de la posición y la orientación del objeto (o de la cámara).
Figura 3.9: Control visual 2½D
El esquema más representativo es el control visual 2½D con el cual se

consigue una estabilidad asintótica global en presencia de posibles erro-
res de calibración, y no es necesario el conocimiento previo del modelo
tridimensional del objeto [26]. En [89] la información 3D obtenida a par-
tir de una reconstrucción proyectiva es utilizada para regular el error
de rotación mientras que la información en el plano 2D de la imagen es
utilizada para regular el error en traslación. La principal desventaja de

esta técnica radica en ser relativamente sensible a errores en la medición
[88] y ser muy sensible al ruido presente en la imagen [24].
En [24] además de analizar los posibles problemas del control visual ba-
sado en imagen, como son las singularidades y los mínimos locales, se
presentan dos leyes de control para el control visual 2½D, y se comen-
ta brevemente las condiciones para obtener una estabilidad global del
sistema. En [90] se presenta un controlador adaptivo para un esquema
de control 2½D, y se comprueba su estabilidad mediante Lyapunov. En
[28] también se utiliza la reconstrucción proyectiva para realizar control
2½D pero aplicado a objetos planos para un sistema monocular cámara
en mano. En [91] se implementa un nuevo controlador y se compara con
otro basado en la descomposición a partir de la geometría epipolar.
Hay otras propuestas de control híbrido como la de Hutchinson [92], que

propone un esquema de control dinámico (2D & 3D switched dynamic)
que según el comportamiento del sistema, se intercambia entre control
2D y 3D, por unas reglas de tipo determinístico y probabilístico. Los
resultados presentados son solo a nivel de simulación. En varios artícu-
los se presenta un sistema de control desacoplado (entre movimientos
traslacionales y rotacionales) utilizando momentos de la imagen.
En [93] se presenta una propuesta llamada control visual 2D/3D donde

se minimiza la suma de los errores tanto en 2D como en 3D multiplicados
cada uno por un factor de peso, que indicará la influencia de cada tipo
de error. Los resultados de simulación indican una mejora en el espacio
cartesiano frente al control visual 2½D.
Control visual particionado :

Propuesto por Corke y Hutchinson [94] y detallado en [41], es una va-
riación del control basado en imagen (IBVS), donde se desacopla el mo-
vimiento traslacional y rotacional sobre el eje óptico de la cámara (eje
Z) del movimiento en los otros dos ejes (ejes X e Y). La matriz de inter-
acción se divide en dos submatrices, la primera que depende de los ejes
X e Y, y la segunda que depende solamente del eje Z.
Esta última matriz depende tan solo de dos nuevas características vi-
suales fácilmente computables a partir de las originales. En las pruebas
realizadas se observa que con este esquema se evitan los movimientos
complicados en el espacio 3D para conseguir la persistencia de las ca-

racterísticas visuales en el plano de la imagen.
Control visual basado en movimiento :

En esta estrategia lo que se mide es el llamado flujo óptico, el cual es
una medida del movimiento de un objeto en la imagen [98]. Hay varios
artículos que usan esta estrategia: en [95] se controla un sistema cáma-
ra en mano para posicionar el plano de la imagen paralelo al plano del
objeto; y un ejemplo de tarea con seguimiento de contornos se puede
consultar en [96].
Figura 3.10: Control visual basado en movimiento.

3.3.3. En función de los elementos requeridos en el cam-

po visual
Terminal en lazo abierto EOL :

En esta configuración se observa tan solo al objeto a controlar. En un
sistema cámara en mano, si se tiene la tarea de posicionar el robot con
respecto a un objeto, esta es llevada a cabo de forma indirecta a través
del conocimiento de la relación cinemática entre la cámara y el robot, cu-
yos errores pueden llevar a errores de posicionamiento ya que no pueden
ser observados por el sistema. En este aspecto, si se observase también
el robot se podrían corregir estos errores. En general no se puede garan-
tizar la exactitud del posicionamiento del sistema a menos que, ambos,
el objeto y el robot sean observados al mismo tiempo.
Terminal en lazo cerrado ECL :

En este esquema de control tanto el efector final y el objeto de con-
trol son observados, por lo que, tanto los errores de posicionamiento
del objeto de control y del efector final se corrigen al mismo tiempo.
Parece pues conveniente usar una configuración ECL, pero aparte de
utilizarse una configuración cámara fija, se requerirían mayores recursos
de computación. En [97] utiliza un sistema monocular con cámara fija
para una tarea de posicionamiento de planos con buenos resultados aun
en presencia de errores del modelo cinemático y errores de calibración
del sistema de visión.
3.3.4. En función de la necesidad de modelo del objeto

Extraída de [99], esta clasificación se basa en el conocimiento a priori del
modelo tridimensional del objeto de control. Esta estrategia se divide en dos
grupos:
Control visual basado en modelo :

Se denomina así cuando se conoce el modelo tridimensional del objeto
de control, que junto con el conocimiento exacto de la calibración de la
cámara y del robot se estima la posición y la orientación actual del obje-
to. Para el caso particular en que las características visuales a reconocer
sean puntos en la imagen, se necesitan al menos 4 puntos para reali-
zar una estimación exacta de la posición y orientación del objeto [103];
si más de cuatro puntos pueden ser localizados y extraidos, es posible
prescindir de los parámetros de la cámara y trabajar con un sistema no
calibrado [19][86].
Control visual libre de modelo :

Aquí no se necesita un conocimiento a priori del modelo tridimensional
del objeto. Las características correspondientes a las posiciones deseadas
se consiguen en una etapa previa fuera de línea, conocida como teach-by-
showing [42]. En esta técnica el robot es movido a la posición deseada,
la cámara toma la imagen del objeto, extrae sus características visuales
y las almacena en memoria. Estas características visuales representarán
en la etapa de control a las características de referencia.
Como en los otros esquemas de control, este paso es muy importante

para el éxito de la tarea del control. En este proceso, la diferencia entre
las características visuales del momento actual y las de referencia cons-
tituirá el error a minimizar en el espacio de la imagen. Un error menor
a un umbral determinado significará que se ha alcanzado la posición de
referencia deseada con una exactitud en la cual no se tienen en cuenta
los errores de calibración.
También hay esquemas de control libres del modelo que realizan control
visual 3D donde la rotación y la traslación son determinadas a partir
de la matriz esencial, la cual es estimada a partir de las imágenes de la
posición actual y de la posición de referencia.
3.3.5. En función del modelo visuo-motor
Esta clasificación fue propuesta por Kragic [105]. En éste se considera co-
mo elemento de clasificación el modelo visuo-motor del sistema, es decir, la
relación entre la parte motora del sistema y las características en la imagen.
Se dice que es conocido a priori si se dispone de los modelos de los diferentes
componentes del sistema. En caso contrario habría que realizar una estimación.
En esta clasificación se distinguen dos alternativas:
Modelo visuo-motor conocido a priori :

Se conocen los parámetros de calibración de la cámara, la transforma-
ción entre sistemas robot-cámara, la calibración del robot y el modelo
del objeto. Dentro de esta clasificación se pueden encuadrar al control
basado en posición, control basado en imagen y el control visual híbrido.
Modelo visuo-motor estimado :

Dado que no se dispone de ninguno de los parámetros anteriores, es
necesario realizar un proceso de estimación de los mismos. Este proceso
se realiza fuera de línea, utilizando métodos de aprendizaje por redes
neuronales [10][11], redes borrosas [102] o neuro-borrosas [100]. Otros
métodos usados suelen ser recursivos o incluso realizando movimientos
linealmente independientes [104].
Figura 3.11: Clasificación de los sistemas de control visual respecto al modelo

visuo-motor.
3.4. Otros aspectos del control visual 36
3.4. Otros aspectos del control visual
Para la clasificación de las técnicas de control visual se pueden utilizar otro

tipo de criterios, además de los mostrados anteriormente. La ley de control a
utilizar, la interpretación de la escena o incluso los algoritmos de visión utili-
zados, pueden ser otro tipo de criterios de clasificación válidos en este contexto.
Un campo de investigación en control visual es la planificación de trayec-

torias: útil cuando la distancia en la imagen entre la posición inicial y deseada
del objeto es muy grande. Lo que se busca es que con una función de error
en el plano de la imagen se consiga una trayectoria óptima del objeto (o de la
cámara) en el espacio de trabajo a fin de mantener las características visuales
en la imagen, evitando oclusiones u obstáculos.
En [101] se presenta una estrategia que genera una trayectoria en el es-

pacio de la imagen correspondiente a un movimiento óptimo de la cámara
para el caso cuando la distancia entre la posición de inicio y deseada es gran-
de, asumiendo desconocidos los parámetros de calibración de la cámara y el
modelo del objeto. De forma experimental se verifica que es posible seguir la
trayectoria generada mediante este tipo de algoritmos con un control basado
en posición.
Existen también muchas investigaciones respecto a la robustez del contro-

lador basado en información visual frente a posibles errores de modelado o
a perturbaciones, para conseguir un control óptimo en escenarios reales. En
[107] se usa un esquema PBVS, y se aplica el filtro de Kalman para predecir la
posición relativa del objeto utilizándose una base de datos con características
visuales adecuadas que son utilizadas para realizar una trayectoria óptima con
técnicas de fusión sensorial con información de varias cámaras.
En [106] se presenta un controlador robusto frente a errores de calibración

en un sistema estéreo basado en la disparidad y mediciones del flujo óptico.
Para evitar que las características visuales salgan de la imagen, en [108] se
presenta una estrategia denominada control visual independiente de los pa-
rámetros intrínsecos, donde se utiliza una cámara con enfoque variable, y el
controlador propuesto puede aumentar el campo de visión de la escena si el
objeto intenta salir fuera de la imagen.
Otro campo es el del control visual en sistemas de alta velocidad, como por
ejemplo el sistema estéreo para seguir y golpear una pelota de ping-pong [109].
En [113] se describe una propuesta basada en una estructura con configura-
3.4. Otros aspectos del control visual 37
ción de multiprocesador paralela y un sistema de visión activa masivamente

paralelizada, con la cual se consigue un sistema de fusión motor-sensorial con
velocidad de realimentación visual de 1 ms. para interactuar con cambios muy
rápidos en el entorno.
A diferencia del uso de puntos en la imagen, pocos trabajos han sido de-
dicados al control visual a partir de líneas (Figura 3.12). La razón principal
es la dificultad de manejar las características de las líneas en la imagen, las
cuales representan en geometría proyectiva la proyección de un plano 3D que
pasa por el centro óptico de la cámara.
Figura 3.12: Ejemplo de detección de líneas en entornos urbanos.
Un ejemplo de aplicación en sistemas monocámara se tiene en [110], donde

la tarea es posicionar la cámara con respecto a una autopista representada
por tres líneas paralelas que están en un plano, y se calcula el jacobiano de
la imagen considerando constante la altura a la que se encuentra la cámara
sobre la autopista. Otro ejemplo de aplicación es el dado en [112], tratando el
alineamiento de un UAV con las líneas de una carretera, donde la matriz de
interacción calculada a partir de las características desacopladas de las líneas
es integrada en las leyes de control lateral y longitudinal.
Figura 3.13: Ejemplo de detección de líneas en una carretera.

3.5. Conclusión 38
3.5. Conclusión
La realización de tareas de índole robótico con un quadrotor requiere de

estructuras de control en tiempo real. Además la dinámica no lineal y acoplada
del quadrotor impide que pueda ser incluida en las leyes de control visual. Se
considera pues a éste como un robot con un bucle interno (rápido) al cual se
le introducen referencias generadas en todo momento desde un lazo externo,
generalmente a una frecuencia menor.
Se encuentra por consiguiente su similitud con el control mirar y mover

dinámico basado en posición y en imagen. Con respecto a la posición de la
cámara, la alternativa seleccionada en el presente proyecto se basa en colocar
una cámara a bordo del quadrotor (configuración de cámara en mano), reali-
zando el procesado de la información visual a bordo del mismo.
En el presente proyecto se han implementado las técnicas de control ba-

sado en posición y control basado en imagen. Para el control visual basado
en posición, como anteriormente se mencionó, se requiere a priori del conoci-
miento de ciertos parámetros del objeto de referencia (modelo 3D), así como
de los parámetros internos de la cámara, lo que supone ciertos problemas a la
hora de ser utilizados para el control visual de un quadrotor autónomo.
En la primera propuesta implementada y presentada en el capítulo 6, se

han superado los siguientes requisitos:
Necesidad de la reconstrucción 3D del objeto: el modelo del objeto es

conocido.
Proceso de calibración de la cámara: explicado en el capítulo 5.
Alto coste computacional: optimización de las rutinas de captura y tra-

tamiento de las imágenes.
Para una información más completa y detallada acerca de todos los elementos
presentados en este capítulo, se refiere al lector a consultar [41] y [51].
Capítulo 4
Localización y seguimiento del

objeto de referencia
4.1. Introducción
Para el control visual es imprescindible la presencia de un determinado ob-

jeto, denominado objeto de referencia o interés. De la localización y posterior
seguimiento de éste se extraerá la información necesaria para cerrar el lazo
de realimentación visual para el control del quadrotor. Es por ello necesaria
una clasificación del conjunto de algoritmos para las tareas de localización y
seguimiento de objetos.
Existen otras propuestas [50] en las que se propone una clasificación distin-
ta a la presentada en este capítulo, enfocándose de distinta forma el conjunto
de algoritmos presentes en la literatura. Así pues, en el presente capítulo se
expone de forma amplia y detallada conceptos relacionados con:
Representación del objeto de referencia (Figura 4.1).
Métodos de detección basados en la representación escogida.
Selección de características para el seguimiento, basado en la técnica

usada para representar al objeto.
Métodos de seguimiento de características.

Con los últimos avances en las librerías de procesamiento digital, el aba-
ratamiento de los componentes hardware y el aumento de la capacidad de
cómputo de éstos, la tarea de localización y seguimiento de objetos ha ex-
perimentado un gran desarrollo durante los últimos años. Producto de este
39
Figura 4.1: Objeto de referencia utilizado en el presente proyecto.
desarrollo, se muestran algunos ejemplos de la funcionalidad y amplio campo

de aplicación de éste tipo de técnicas:
Reconocimiento basado en el movimiento: Por ejemplo, reconocimien-

to de personas mediante la identificación de la forma característica de
andar.
Vigilancia automatizada: Monitorización de una zona para la deteccción

de posibles intrusos o actividades no programadas.
Interacción persona - ordenador: Reconocimiento de gestos, identifica-

ción mediante iris, etc.
Monitorización del tráfico: Recolección en tiempo real de estadísticas de

autopistas o carreteras basadas en información visual, por ejemplo.
Navegación de vehículos: Generación de trayectorias y capacidad para

evitar obstáculos.
Una definición relativamente simple que se puede realizar para la tarea del
seguimiento de objetos, puede ser como el “problema de la estimación de la
trayectoria de un objeto determinado con movimiento en el plano de la ima-
gen”. Pero esta tarea, por “liviana” que pudiera parecer su definición, conlleva
una serie de problemas:
Posible pérdida de información visual, debida a la proyección del mundo

tridimensional a una escena 2- dimensional.
Ruido en las imágenes: Posibles obstáculos que se crucen entre la cámara

y el objeto de referencia.
Posibilidad de que el movimiento del objeto de control sea relativamente

rápido o abrupto.
La naturaleza no rígida o articulada de algunos objetos conlleva a posi-

bles cambios en la geometría del objeto de control.
Posibles cambios en la iluminación de la escena, que provoquen pérdida

parcial/temporal de la localización del objeto de referencia.
El procesamiento de extracción de información visual debe ser en tiempo

real.
Posibles oclusiones o pérdida parcial del objeto.
La tarea del seguimiento se puede simplificar imponiendo algunas restricciones

en el movimiento del objeto. Por ejemplo, muchos de los algoritmos de segui-
miento estudiados consideran que el movimiento del objeto no es abrupto ni
caótico, y que mantiene cierta linealidad. Otra de las restricciones considera-
das es que la geometría del objeto, la forma del mismo, es invariante.
Como conclusión a ésta introducción, el conjunto de propuestas para la lo-

calización y seguimiento de objetos se pueden encuadrar en preguntas del tipo:
¿Qué características de la imagen deben ser usadas?;

¿Qué representación del objeto es la mejor para el seguimiento?;
¿Cómo deben modelarse el movimiento, la apariencia y la figura del objeto?
las cuales son resueltas en los apartados expuestos a continuación.

4.2. Representación del objeto 42
4.2. Representación del objeto
Si se desea localizar un determinado objeto en una escena para su posterior

seguimiento, en primer lugar es necesario definir qué se entiende por objeto.
O dicho de otra forma, cómo se puede codificar la información que represen-
ta a un objeto. A continuación se presentan algunas de las propuestas más
extendidas en la actualidad.
Puntos :
El objeto de referencia se puede representar como un único punto, lo que
se correspondería con el centroide del objeto (Figura 4.2.Izquierda), o
bien como un conjunto de varios puntos (Figura 4.2.Derecha). En gene-
ral, la representación por puntos es adecuada en situaciones en las que
el objeto de referencia ocupa pequeñas regiones en la imagen.
Figura 4.2: Representación del objeto por puntos.
Formas geométricas :
El objeto puede ser representado bien como un rectángulo (Figura 4.3)
o como una elipse. El movimiento del objeto en este tipo de aproxima-
ciones y en las basadas en puntos pueden modelarse por su traslación
respecto a un origen determinado o por una transformación proyectiva
(homografia). Este tipo de técnicas son usadas tanto para el seguimien-
to de objetos rígidos como para el seguimiento de objetos de geometría
variable.
Figura 4.3: Representación del objeto usando formas geométricas básicas.
Siluetas y contornos :
La representación por contornos (Figura 4.4. Izquierda) de un objeto de-
fine las “fronteras” del mismo. La región contenida dentro del contorno
se denomina silueta del objeto (Figura 4.4. Derecha). Tanto la repre-
sentación por siluetas como por contornos son buenas técnicas para el
seguimiento de formas complejas no rígidas.
Figura 4.4: Representación del objeto usando contornos y siluetas.
Modelos articulados :
Los objetos de referencia articulados están compuestos, en general, por
un conjunto de partes que unidas conforman al objeto. Por ejemplo, el
cuerpo humano se puede considerar como un objeto articulado, formado
por el torso, los brazos, las manos, la cabeza y los pies. La relación entre
las distintas partes está regida por modelos cinemáticos de movimiento.
Para la representación de las distintas partes del cuerpo se pueden usar

tanto formas geométricas básicas como siluetas o contornos.
Figura 4.5: Representación del objeto como modelo articulado.
Modelos basados en el esqueleto del objeto :

El esqueleto de un objeto de referencia puede ser calculado usando una
transformación aritmética, considerando la media de la distancia entre
las fronteras del objeto. Esta representación suele ser la más amplia-
mente utilizada para modelar tanto objetos rígidos como de geometría
variable.
Figura 4.6: Representación del esqueleto de un objeto.

En las anteriores técnicas tan sólo se representaba la localización del objeto

en la escena, mediante puntos, contornos, siluetas o formas geométricas, en-
tre otros. Pero existen otras formas para localizar un objeto de referencia en
una escena, y éstas se basan en la apariencia del mismo. Elementos tales co-
mo el color o la textura del objeto son los utilizados para representar al objeto.
A continuación se exponen varias técnicas para representar la apariencia

de un objeto determinado:
Densidad de probabilidad :
La estimación de densidad de probabilidad de la apariencia del objeto
puede ser paramétrica, como el Gausiano de una imagen4.1 , o no pa-
ramétrica, como un histograma . Se basan en clasificar mediante algún
tipo de función las características del objeto, tales como el color o la
textura.
Plantillas :
Las plantillas se componen usando formas geométricas simples o silue-
tas. Una de las ventajas del uso de plantillas es que se codifican tanto la
apariencia del objeto, como sus dimensiones. Sin embargo, la informa-
ción visual para la apariencia es extraída tan sólo de una única vista.
Por lo tanto, las plantillas sólo son adecuadas para el seguimiento de

objetos cuya posición no varíe considerablemente. Pero como se verá
más adelante, existen algunas propuestas en la literatura que presentan
soluciones para convertir esta técnica en invariante ante cambios en la
escala y rotación, lo que la hacen una técnica más robusta.
Modelos activos :
Estos modelos son generados considerando al mismo tiempo la aparien-
cia y la forma del objeto. En general, la forma del objeto se define por un
conjunto de puntos de referencia que pueden pertenecer a la frontera del
objeto o, alternativamente, pueden estar contenidos dentro de la región
del mismo.
Para cada punto se almacena un vector de apariencia, el cual contiene

información acerca del color, textura, o magnitud del gradiente. Estos
modelos requieren de una fase de entrenamiento, donde se aprenden
4.1
El Gausiano de una imagen es un tipo de distribución que asocia a cada píxel el valor
promedio de sus vecinos.
tanto la forma del objeto como la apariencia asociada, a partir de un

conjunto de vistas diferentes del mismo objeto de referencia.
Modelos de apariencia multivistas :

Estos modelos codifican diferentes puntos de vista de un objeto. Una
aproximación para este tipo de representación es generar un subespacio
para el conjunto total de vistas. Un ejemplo es el Análisis de Componen-
tes Principales (PCA) y Análisis de Componentes Independientes (ICA),
los cuales se han utilizado tanto para la representación de la forma como
de la apariencia.
En general, existe una relación directa entre la representación del objeto y los
algoritmos de seguimiento asociados. Normalmente, en función de las condi-
ciones de la aplicación, se elige una representación u otra para el objeto.
4.3. Selección de características para el seguimiento 47
4.3. Selección de características para el segui-

miento
Un pilar fundamental en los algoritmos de seguimiento o tracking es la

selección de características en la imagen. En general, lo más deseable de una
característica visual es que sea única, para poder ser distinguida del resto de
posibles características candidatas . Como se determinó en el apartado an-
terior, la selección de características está relacionada con la representación
elegida para el objeto.
Por ejemplo, el color suele usarse como una característica cuando se usan
métodos de localización basados en histogramas; de igual modo también son
usados los contornos para métodos basados en contornos, donde el color no se
considera.
En general, muchos de los algoritmos presentes en la literatura no se basan

en una determinada caracterísica, sino que hacen uso de una combinación de
ellas. A continuación se exponen en detalle algunas de ellas:
Color :
Para la codificación del color de una imagen existen dos grandes méto-
dos: la codificación RGB4.2 y la codificación HSV4.3 . Cada método tiene
sus ventajas e inconvenientes. Por ejemplo, las diferencias entre los co-
lores en el modelo RGB no se corresponden con las diferencias de color
percibidas por el ojo humano, y ambos modelos son sensibles a ruidos
en la imagen.
Bordes :
Normalmente los cambios en la intensidad de las imágenes son mayores
ante la presencia de bordes. Una propiedad importante de los bordes
es que son relativamente más robustos que los basados en color ante
cambios de iluminación. La propuesta más conocida que usa esta técnica
es la del detector de bordes de Canny.
Flujo Óptico :
El flujo óptico se puede considerar como un campo de vectores que re-
presentan el desplazamiento de cada punto, el cual define la traslación
de cada píxel en una región. Se calcula usando una restricción sobre
4.2
Toda imagen queda codificada como una combinación de los colores Red Green Blue.
4.3
Del inglés Hue, Saturation, Value – Tonalidad, Saturación, Valor.
4.3. Selección de características para el seguimiento 48
el contraste de la imagen, donde se supone un valor constante para un

determinado píxel en imágenes consecutivas. El flujo óptico se utiliza
comúnmente como una característica para la segmentación basada en
movimiento.
Texturas :
La textura se puede considerar como una medida de la variación de la
intensidad de una superficie, la cual codifica propiedades como regulari-
dad y suavidad en los valores de los píxeles. Al contrario que el color, la
textura precisa de un pre-procesado para generar unas estructuras deno-
minadas descriptores. Al igual que los modelos basados en bordes, este
método es menos sensible a los cambios de iluminación que el color.
Según se ha podido observar tras consultar la bibliografía existente, general-

mente el color es una de las características más utilizadas para algoritmos de
seguimiento, a pesar de los problemas que presenta ante cambios en las con-
diciones de luz.
4.4. Detección del objeto 49
4.4. Detección del objeto
En esta sección se muestran con un mayor nivel de detalle los métodos para
la localización del objeto de interés en la escena. Se divide en dos apartados:
métodos para la detección de puntos característicos en la escena y métodos
basados en otras representaciones. Esta distinción es necesaria, puesto que
en el presente proyecto todas las propuestas implementadas se basan en una
representación por puntos del objeto de referencia.
4.4.1. Detectores de puntos
Este tipo de métodos son usados para encontrar puntos que presenten cier-
tas singularidades respecto al área en la que están integrados. Una propiedad
deseable de un punto de interés (o corner, como se indica en [120]), debe ser
su invarianza ante cambios de iluminación en la escena desde el punto de vista
de la cámara. En la literatura, los métodos más usados siguiendo este esquema
son el operador de Moravec [114], la técnica de Harris [45], el detector KLT
[117] y el detector de características SIFT [115].
Figura 4.7: Puntos de interés usando Harris.
El detector de Harris (Figura 4.7) calcula las derivadas de primer orden de

la imagen, (Ix ,Iy ), en las direcciones de →
−
x e→
−
y para realzar las variaciones de
las intensidades direccionales. Posteriormente, se calcula una matriz con las
derivadas de segundo orden, la cual codifica estas variaciones, y es evaluada
para cada pixel en una pequeña región de vecindad:
P 2 P !
I Ix Iy
M= P x P 2 (4.1)
Ix Iy Iy
El primer paso para obtener un punto característico candidato consiste en

usar el determinante y la traza de la matriz M, la cual mide la variación en
un pequeño entorno de vecindad R = det(M)−k tr(M)2 , donde k es constante.
Los puntos de interés son finalmente seleccionados tras aplicar un deter-

minado umbral sobre R. La misma matriz de momentos M dada en 4.1 es
usada en el paso de detección de puntos de interés del método KLT. La rela-
ción R se calcula usando el mínimo de los autovalores de M, λmin . Los puntos
candidatos son posteriormente seleccionados usando el umbral R. El método
KLT elimina los puntos que están relativamente cerca unos de otros (Figura
4.8).
Figura 4.8: Puntos de interés usando KLT.
Cuantitativamente, los métodos de KLT y Harris enfatizan las variaciones

de la intensidad usando medidas similares. Por ejemplo, la matriz R en el
método de Harris está relacionada con el polinomio característico usado para
encontrar los autovalores de M ,λ2 + det(M) − λ tr(M) = 0, mientras que
en el método KLT se calculan los autovalores directamente. En la práctica,
ambos métodos encuentran casi los mismos puntos de interés.
La única diferencia es pues que el método de KLT incluye un criterio para

distinguir entre puntos separados una cierta distancia. En teoría, la matriz M
es invariante tanto a rotación como a traslación; sin embargo, no es invariante
a transformaciones proyectivas o afines.
Para introducir un método robusto para la detección de buenos puntos de

interés, en [115] se introduce el método denominado como SIFT (Scale Inva-
riant Feature Transformation, Figura 4.9), el cual está compuesto por 4 pasos.
Figura 4.9: Puntos de interés usando SIFT.
El primero de ellos consiste en construir un espacio a escala mediante la

convolución de la imagen con filtros Gausianos usando diferentes escalas. A
continuación se lleva a cabo un proceso de actualización de la localización de
cada candidato mediante la interpolación de los valores del color, usando para
ello los píxeles vecinos.
Posteriormente, tanto los candidatos con un bajo contraste como los que
están incluidos en los bordes, son eliminados. Por último, a los puntos res-
tantes se les asignan orientaciones basándose en los picos del histograma en
la dirección del gradiente, en un pequeño entorno de vecindad alrededor de
cada punto candidato. Para más información, se detalla en profundidad este
método en la sección 7.2.4.
El detector SIFT genera un mayor número de candidatos, si se compara

con los otros dos métodos. Esto es debido al hecho de que se consideran puntos
a diferentes escalas y diferentes resoluciones (piramidal). Empíricamente, se
muestra en [116] que el método de SIFT es más robusto ante deformaciones en
el objeto. Pero no todo son ventajas: el coste computacional de este método es
relativamente importante, y para aplicaciones en tiempo real es prácticamente
inviable en la actualidad.
4.4.2. Métodos de detección no basados en puntos
Dado que tan solo se han usado implementaciones de alguno de los métodos
propuestos en el apartado anterior, cualquier método no basado en detección
de puntos no será tratado en el resto del documento.
Sin embargo, y con carácter meramente ilustrativo, se presenta a continua-

ción una tabla que recoge el conjunto de métodos más relevantes relacionados
con la detección no basados en puntos presentes en la literatura.
Categorias Trabajos más relevantes

Segmentación Mean Shift
Graph-Cut
Contornos Activos
Modelado del fondo Mixture of Gaussians
Eigenbackground
Wall flower
Dynamic texture background
Clasificadores Supervisados Support Vector Machines
Neural Networks
Adaptive Boosting
4.5. Seguimiento del objeto 53
4.5. Seguimiento del objeto
El objetivo de los algoritmos de seguimiento es poder inferir la trayectoria

que el objeto sigue a lo largo de una secuencia de imágenes. La tarea de encon-
trar el objeto y de establecer las correspondencias entre los puntos del frame
anterior y el siguiente puede ser llevada a cabo de forma conjunta, o separada.
Si se realiza de forma conjunta, las regiones donde es posible que el objeto
se encuentre son obtenidas mediante un algoritmo de detección de objetos, y
posteriormente se le asignarían las correspondencias para los puntos de interés.
En el segundo caso, si se realizan las dos tareas de forma conjunta, tan-

to la región del espacio como las correspondencias son calculadas al mismo
tiempo, actualizando la posición del objeto de forma iterativa a partir de las
características del movimiento del mismo en los frames anteriores.
En cualquiera de las dos técnicas anteriores, el objeto puede ser repre-

sentado bien por formas (puntos, formas geométricas, etc.) o por apariencia
(texturas, color, etc.). En función pues del modelo de representación, el mé-
todo de seguimiento o tracking será distinto. A continuación se exponen las
diferentes categorias para los algoritmos de seguimiento presentes en la lite-
ratura clasificados en función de la representación del objeto de referencia.
Seguimiento de puntos :
El objeto de interés, el cual es localizado en frames consecutivos, es re-
presentado como un conjunto de puntos, y la asociación de los mismos
se basa en los estados previos del objeto, los cuales incluyen información
tanto de la posición como del movimiento. Con esta aproximación es ne-
cesario el uso de un método externo para la detección del objeto en cada
frame. En el apartado 4.5.1 se detallan varias técnicas pertenecientes a
esta categoria.
Kernel Tracking :
En este contexto, kernel se refiere a la forma o apariencia del objeto de
referencia. Por ejemplo, la representación del objeto en este apartado
puede ser bien un rectángulo, o bien una elipse, ambos con un histogra-
ma asociado. El objeto es seguido en frames consecutivos calculando el
movimiento de la forma que engloba al mismo, lo cual se puede observar
en la Figura 4.10. Este movimiento normalmente se suele describir en
términos de traslación, rotación y transformación afin.
Figura 4.10: Kernel Tracking.
Seguimiento de siluetas :
Este tipo de métodos usan la información contenida dentro de la región
del objeto, lo que se ha denominado anteriormente como apariencia, pa-
ra calcular los bordes o extremos de la propia región. Esta información
se representa bien como mapas de vectores, o como densidad de probabi-
lidad, entre otros. Dados los modelos de los objetos, las siluetas pueden
ser seguidas bien por técnicas de matching 4.4 de formas o por el método
de evolución de contornos.
Figura 4.11: Evolución de contornos.
4.5.1. Seguimiento basado en puntos
Como se expuso en el apartado anterior, el seguimiento consiste en la es-

timación de la correspondencia de unos puntos entre un frame y el siguiente.
Pero esta correspondencia es un problema relativamente complejo cuando se
tienen, por ejemplo, oclusiones, falsos positivos, o movimientos erráticos del
objeto que provoquen la pérdida de posibles emparejamientos.
Los métodos encuadrados en esta categoria se pueden clasificar en dos

grandes grupos: los métodos deterministas y los métodos probabilísticos. Los
4.4
Equivale al cálculo de las correspondencias.
métodos deterministas usan heurísticas cualitativas para el movimiento, para

el planteamiento de las restricciones sobre el problema de la correspondencia.
Sin embargo, en la otra clase de métodos se toman de forma explícita medidas
del objeto y se tienen en cuenta algunos valores desconocidos (incertidumbre
en el modelo) para hallar las correspondencias.
4.5.1.1. Métodos deterministas
En este tipo de métodos, se define un coste, asociado a la correspondencia

de un punto entre un frame y el siguiente. Así, lo que se intenta es una mi-
nimización del coste global para las correspondencias, y este problema queda
formulado como un problema de optimización combinatorial.
La solución, que consiste en una asociación 1-a-1 de todos los puntos de

un frame con los puntos del siguiente (Figura 4.13) de entre todas las posibles
soluciones (Figura 4.12), puede ser obtenida mediante métodos de asignación
óptima, como por ejemplo algoritmos de búsqueda voraces.
Figura 4.12: Conjunto total de asociaciones de un punto.
Figura 4.13: Correspondencias correctas para un conjunto de puntos.

Para el cálculo del coste, se tienen en cuenta las siguientes restricciones:
Proximidad: Se considera que el objeto no realiza cambios bruscos de

posición entre frames consecutivos.
Velocidad acotada: Se estima la velocidad máxima a partir de la cual

es imposible que el objeto se mueva, y marca un entorno de vecindad
donde es posible hallar la correspondencia del punto (Figura 4.14, 1).
Smooth Motion: Se asume que tanto la dirección como la velocidad del

objeto no cambian de forma drástica (Figura 4.14, 2).
Restricciones comunes de movimiento: La velocidad del objeto en una

pequeña región es la misma para todos los puntos. Esta consideración
es muy importante cuando se representa al objeto como, precisamente,
un conjunto de puntos en la imagen (Figura 4.14, 3).
Rigidez: Se asume que los objetos en el mundo real, tridimensional, son

rígidos, y además se cumple que la distancia entre dos puntos cuales-
quiera del objeto permanecerá constante en el mundo tridimensional,
aunque no así en la imagen (Figura 4.14, 4).
Figura 4.14: 1: Velocidad máxima. 2: Cambios pequeños en la velocidad. 3:

Restricciones comunes. 4: Geometría del objeto.
Estas restricciones no son exclusivas de los métodos deterministas; también

pueder ser consideradas en los métodos probabilísticos o estadísticos.
4.5.1.2. Métodos estadísticos
Para hallar las correspondencias entre los puntos en este tipo de métodos,
se tienen en cuenta posibles incertidumbres o errores en el modelo para es-
timar la posición del objeto. Estos errores pueden ser debidos a oclusiones o
cambios de las condiciones lumínicas, entre otros.
Si se considera un determinado objeto móvil observado desde un pun-

to de vista, y se representa parte de la información del mismo, como por
ejemplo, la localización, ésta se puede definir como una secuencia de estados
X t : t = 1, 2, ..
Los cambios entre los estados del objeto quedan reflejados en la siguiente
ecuación:
X t = f t (X t−1 ) + W t
donde W t es el denominado ruido blanco4.5 .
La relación entre la medición y el estado se especifica por la ecuación

Z = ht (X t, N t ), donde N t es el ruido blanco y es independiente de W t . El
t
objetivo de los algoritmos de seguimiento consiste en estimar el estado X t

dadas todas las mediciones obtenidas hasta el momento, que se traduciría en
construir la distribución de probabilidad p(X t | Z 1,...,t ) que rige la dinámica
del movimiento del objeto.
Una solución óptima a nivel teórico es usar un filtro recursivo Bayesiano,

el cual provee una solución en dos pasos. El primero de ellos, la predicción,
usa una ecuación de carácter dinámico y la distribución de probabilidad ya
calculada del estado en el instante t − 1 para obtener la distribución de proba-
bilidad del estado actual, p(X t | Z 1,..,t−1 ). En el segundo paso, de corrección,
se emplea una función de similitud p(Z t | X t ) de la medición del estado actual
para calcular la siguiente distribución de probabilidad p(X t | Z 1,..,t ).
En el caso donde el conjunto de mediciones obtenidas sean debidas a la

existencia de un único objeto, entonces con los dos pasos expuestos anterior-
mente es más que suficiente para estimar el estado actual. Pero si existen
varios objetos en la escena, existen otros casos de estudio que no son vistos en
la presente sección. Para más información de este tipo de métodos, se refiere
al lector a consultar [50].
4.5
Ruido que no se corresponde con ninguna distribución estadística.
4.5.2. Seguimiento basado en apariencia
La propuesta más generalizada de esta categoria es la denominada tem-

plate matching. Este método se puede considerar como de búsqueda usando
fuerza bruta, intentando localizar en una imagen Iw una región similar a la
que contiene el objeto, denominada Ot , definida en algún frame anterior. La
posición de la plantilla puede ser calculada, de entre otras formas [120], usando
el método de correlación cruzada:
× Iw (x + dx + dy))
P P
x y (Ot (x, y)
arg maxdx,dy qP P
x y Ot2 (x, y)
donde (dx,dy) especifica la posición del centro de la plantilla candidata.
Normalmente, tanto las intensidades de la imagen como el color son usa-

das para construir la plantilla. Pero dado que la intensidad de la imagen es
muy sensible a cambios en la iluminación, los gradientes de la misma también
pueden ser usados como características de la imagen. La principal limitación
que posee el método de template matching es el coste computacional que ca-
racteriza a los algoritmos de fuerza bruta.
Existen varias propuestas usando otra representación del objeto; desde cal-
cular la media de los valores del histograma para los píxeles que representan
al objeto, hasta ponderar los valores digitales que tienen dichos píxeles en el
histograma. Esta segunda técnica se conoce como mean-shift. Para más infor-
mación, consúltese [120], capítulo relacionado con tracking.
Otras alternativas para realizar el seguimiento de una región definida por

una forma geométrica básica es la de calcular la traslación usando un método
de flujo óptico. Esta clase de métodos son usados para generar una especie
de campo de vectores, calculando el vector de flujo para cada píxel bajo la
restricción de brillo constante, I(x, y, t) − I(x + dx, y + dy, t + dt) = 0. Este
procedimiento, el cual es llevado a cabo en un entorno de vecindad alrededor
del píxel, se puede realizar de dos maneras: de forma algebraica (Lucas and
Kanade, 1981) o geométricamente (Schunk).
En 1994, Shi y Tomasi propusieron el denominado KLT tracker, el cual es

usado en la implementación propuesta en este proyecto bajo el nombre de la
función cvCalcOpticalFlowPyrLK(), y en el que de forma iterativa se calcula
la traslación (du,dv) de una región (se admite como parámetro de entrada al
algoritmo) centrada en un punto de interés:
P 2 P ! ! !
I Ix Iy
P
du Ix It
P x P 2 =
Ix Iy Iy
P
dv Iy It
Una vez que se ha obtenido la nueva localización del punto de interés, el

algoritmo KLT tracker evalua la calidad de la zona estimada calculando la
transformación afin:
! ! ! !
x0 a b x tx
= +
y0 c d y ty
entre las zonas correspondientes en los siguientes frames (los coeficientes

a,b,c,d se verán en capítulos posteriores).
Si la suma de la diferencia de cuadrados entre la zona actual y la estimada

es menor que un cierto umbral, entonces se sigue estimando la posición del
punto característico; en caso contrario, se deshecha. Un ejemplo de uso del
algoritmo KLT tracker es el mostrado en la Figura 4.15.
Figura 4.15: Seguimiento de características usando el algoritmo KLT tracker.

4.5.3. Seguimiento de siluetas y contornos
Dado que los algoritmos presentados en este apartado no han sido estu-
diados a lo largo del desarrollo del presente proyecto, se propone una relación
esquemática con las principales técnicas y algoritmos, para concluir la clasifi-
cación del estado del arte de la localización y seguimiento de objetos.
Categoría Trabajo más relevante Grupo

Modelo de espacios de estados Métodos de
(Isard , Blake, 1998). Espacio de Estados
Evolución de Métodos variacionales
contornos (Bertalmio y otros, 2000) Minimización
Métodos heurísticos directa
(Ronfard, 2004)
Dist. de Hausdorff
(Huttenlocher y otros, 1993)
Emparejamiento Transformada de Hough
de formas (Sato y Aggarwal, 2004)
(Matching shapes) Histogramas
(Kang y otros, 2004)
Para un mayor nivel de detalle de todas las técnicas mostradas en esta

sección, se refiere al lector a consultar [50] y [120], entre otros.
Capítulo 5
Sensor óptico: modelado y

proceso de calibración
Se puede considerar al sensor óptico como a uno de los elementos más im-
portantes de todo el proyecto. Es por ello que se necesita de todo un capítulo
para desarrollar el modelo de cámara usado, el proceso de calibración, y la
base teórica que subyace en todo el proceso. Se presenta pues todo lo relacio-
nado con la cámara que ha sido necesario estudiar para poder llevar a cabo la
implementación presentada en el capítulo 6.
5.1. Modelado de la cámara

5.1.1. Modelo pinhole
La modelización del sistema de la cámara usada en el presente proyecto se

basa en el modelo pinhole. En este modelo, la cámara realiza una proyección
en perspectiva de un punto espacial M a un punto m en el plano de la imagen
a través del centro óptico de la cámara {C}.
El punto espacial M con coordenadas (Xc , Yc , Zc ) con referencia al sistema

de coordenadas de la cámara, queda representado en el plano de la imagen
por un punto m con coordenadas (u, v), o también denominadas coordenadas
centrales, con referencia al punto central de la imagen (u0 , v0 )(Figura 5.1),
donde el punto principal de la cámara se encuentra en el eje óptico de la
misma a una distancia focal f de su centro (sensor).
61
5.1. Modelado de la cámara 62
Figura 5.1: Modelo pinhole de la cámara.
En el modelo presentado se verifica que:

u v f
= = (5.1)
Xc Yc Zc
La expresión anterior se denomina transformación en perspectiva, donde se

ha supuesto un modelo libre de distorsión óptica. En las siguientes secciones
se presentan los tipos de distorsiones que están presentes en este modelo.
5.1.2. Parámetros extrínsecos
La superficie de los puntos de la escena se corresponde con el sistema de

coordenadas, podríamos decir, del mundo real, con un origen {W}, y un sis-
tema de ejes de la forma (Xw , Yw , Zw ). Dado un punto de un objeto, P, éste
queda expresado en el sistema de coordenadas respecto a {W} de la forma
(P xw , P yw , P zw ).
Supongamos ahora que se establece otro sistema de referencia, por ejemplo,

en el origen {C}, y cuyos ejes quedan etiquetados como (Xc , Yc , Zc ), situado
en el centro del eje óptico de la cámara, tal y como se muestra en la Figura 5.2.
Figura 5.2: Relación geómetrica-espacial entre el sistema de coordenadas de

la cámara y el sistema de coordenadas del objeto.
Gracias a esta relación geométrica se pueden definir cuáles son los paráme-
tros extrínsecos5.1 del modelo, los que determinarán la posición y orientación
del sistema de coordenadas de la cámara respecto del sistema de coordenadas
del mundo real o del objeto5.2 .
La posición del centro óptico {C} respecto a {W} se da mediante el vector

de traslación t mostrado a continuación:
 
tx
t =  ty 

 (5.2)
tz
La orientación de los ejes del sistema de la cámara respecto al sistema de

ejes del objeto de referencia viene dado por lo que se conoce como matriz de
rotación R, una matriz cuadrada de orden 3. Esta matriz puede ser obtenida
a partir del producto de matrices de las tres rotaciones simples en cada eje.
5.1
También denominada como técnica de calibración externa.
5.2
La definición puede ser al revés, considerando el sistema de referencia de la cámara
como el origen.
En esta situación, una rotación de φ grados alrededor del eje = se expre-

sará como Rot(=, φ). Se definen éstas rotaciones como sigue:
 
1 0 0
 0 cosφx −senφx 
Rot(X, φx ) =  (5.3)

0 senφx −cosφx
 
cosφy 0 senφy
Rot(Y, φy ) = 

0 1 0   (5.4)
−senφy 0 cosφy
 
cosφz −senφz 0
Rot(Z, φz ) = 
 senφ z cosφz 0 
 (5.5)
0 0 1
Existen otras formas de representar la rotación respecto a cada eje por

separado, que son mostradas a continuación.
Representación RPY :
R = RP Y (φx φy φz ) = Rot(Z, φz ) · Rot(Y, φy ) · Rot(X, φx ).
Representación de Euler :
R = Euler(φ, θ, ψ) = Rot(Z, φ) · Rot(Y, θ) · Rot(Z, ψ).
En esta representación, la matriz R puede quedar expresada de la si-

guiente forma:
R = Euler(φ, θ, ψ) = RP Y (ψ, θ, φ) =
 
cosφcosψ − senφcosθcosψ −cosφsenψ − senφcosθcosψ senφsenθ
 cosφcosψ + cosφcosθsenψ −senφsenψ + cosφcosθcosψ −cosφsenθ 
 
senθsenψ senθcosψ cosθ

(5.6)
Así pues, ambos sistemas quedan relacionados cumpliendo la siguiente
expresión:
   
Xc Xw

Y
 c 

= R  Yw  + t
 
(5.7)
Zc Zw
Por lo que usando lo anterior, para un punto cualquiera, P, con com-

ponentes (P xw , P yw , P zw ) respecto al sistema de coordenadas {W}, se
puede obtener su representación respecto al sistema de coordenadas {C},
quedando sus componentes como (P xc , P yc , P zc ) usando 5.7 como sigue:
   
P xc P xw

 P y 
c  = R  P yw  + t
 
P zc P zw
La ecuación anterior se suele representar también como una única matriz

cuadrada de dimensión 4, expresada en forma de coordenadas homoge-
neas:
" # " #
Pc c Pw
= Tw (5.8)
1 1
donde la matriz c Tw indica la matriz respecto del sistema de coordena-

das de la cámara, teniendo la forma:
" #
R3x3 t3x1
T= (5.9)
01x3 1
5.1.3. Parámetros intrínsecos
El punto m también puede referirse con respecto al borde superior iz-

quierdo de la imagen que se da en coordenadas (x, y) en píxeles, o también
denominadas como coordenadas laterales, realizando la siguiente transforma-
ción:
x = u0 + fx u (5.10)
y = v0 + fy v (5.11)
que de forma matricial puede también escribirse como:
        
x fx γ u0 u x u
 y  =  0 fy v0   v  ó  y  = K  v  (5.12)
        
1 0 0 1 1 1 1
donde la matriz K 5.3 es la denominada matriz de parámetros intrínsecos,

siendo ésta una matriz de 3x3 que describe tanto la geometría como la óptica
de la cámara:
 
fx 0 u0
K =  0 fy v0 

 (5.13)
0 0 1
Se tiene además que fx y fy son las denominadas distancias focales5.4 en

las direcciones ~x e ~y respectivamente. Otra forma de expresar estas distancias
focales es la siguiente:
fx = kx f (5.14)
fy = ky f (5.15)
donde kx y ky son los factores de escala, que relacionan el tamaño del píxel
con la distancia real. Estos resultados son calculados experimentalmente en el
capítulo 7.
Si se asume que f = 1, las coordenadas del punto m se denominan coor-

denadas normalizadas (representan coordenadas pertenecientes a un plano
imagen ideal ubicado a una distancia del centro óptico igual a la unidad, y
está representado por q), a partir de la ecuación (5.1) se tiene que:
 
X
1  c  T
q̃ =  Yc  = (u, v, 1) (5.16)
Zc
Zc
donde el símbolo ~ representa que el punto se expresa en coordenadas pro-

yectivas. Las coordenadas normalizadas se pueden conseguir a partir de las
5.3
El coeficiente γ representa la pérdida de perpendicularidad entre los ejes de la imagen.
Se asume cero, puesto que prácticamente no afecta para los cálculos posteriores.
5.4
Se puede considerar como la distancia del sensor hasta el origen del sistema de referencia
del plano de la imagen.
Figura 5.3: Representación de los parámetros intrínsecos de la cámara.
coordenadas en píxeles m̃ a través de la matriz de parámetros intrínsecos K

despejando q̃ de la relación m̃ = Kq̃ .
5.1.3.1. Coeficientes de distorsión de la lente
En teoria es posible definir una lente perfecta, pero en la práctica es impo-

sible. Esto es debido principalmente al proceso de fabricación de las mismas:
por ejemplo, es mucho más fácil realizar una lente esférica que un modelo
matemáticamente perfecto de lente parabólica.
También resulta complicado el proceso de alineación de la lente con el

sensor. Por ello, se necesitan ciertos parámetros para identificar estas imper-
fecciones en la lente: son los denominados parámetros de distorsión radial y
distorsión tangencial. La distorsión radial suele ser producto de la forma de la
lente, mientras que la distorsión tangencial suele ser el resultado del proceso
de ensamblaje de la cámara durante la fabricación de la misma.
En el caso de la distorsión radial, se tiene que las lentes de cámaras reales

normalmente suelen “modificar” los píxeles cerca de los bordes de la imagen.
Este fenómeno se puede observar en la Figura 5.4. ; es como si se produjera
un efecto de “doblado” en las esquinas. La distorsión radial suele ser 0 en
el centro de la imagen, incrementándose en módulo a medida que nos vamos
distanciando del centro hacia los bordes.
En la práctica, esta distorsión suele ser pequeña y puede ser caracterizada

como los primeros términos de una serie de Taylor alrededor de r = 05.5 . Estos
términos, por convención suelen denominarse k1 y k2 , y para lentes corrientes,
el uso de dos parámetros es más que suficientes. Para lentes más baratas o con
mayor distorsión radial es necesario usar hasta el tercer término de la serie,
k3 .
Figura 5.4: Ejemplo del efecto de la distorsión radial.
En general, para recuperar la posición original de un punto en una ima-

gen obtenida a través de una lente con distorsión radial, se sigue la siguiente
ecuación:
xcorregido = x(1 + k1 r2 + k2 r4 + k3 r6 ) (5.17)

ycorregido = y(1 + k1 r2 + k2 r4 + k3 r6 ) (5.18)
En la expresión anterior, x e y indican las coordenadas de la posición

original del punto distorsionado en el plano de la imagen, y xcorregido e ycorregido
es la nueva localización del punto tras el proceso de corrección. En las figuras
5.5, 5.6 y 5.7 se muestra el efecto de estos parámetros en una lente.
5.5
Básicamente consiste en la expansión de la función de distorsión como un polinomio de
la forma f (r) = a0 + a1 r + a2 r2 + ... alrededor de un determinado factor r.
Figura 5.5: Representación vectorial ante un valor positivo de k1 .
El segundo coeficiente de distorsión es el denominado de distorsión tan-

gencial. Al igual que en el caso anterior, esta distorsión también puede ser
caracterizada por dos parámetros, denominados p1 y p2 . Para corregir la lo-
calización de un punto debido a la distorsión tangencial, se tiene que:
xcorregido = x + [2p1 y + p2 (r2 + 2x2 )] (5.19)

ycorregido = y + [p1 (r2 + 2y 2 ) + 2p2 x] (5.20)
Figura 5.6: Representación vectorial ante un valor positivode p1 .

Figura 5.7: Representación vectorial para un valor positivo de p2 .
Así pues, en total existen cinco parámetros5.6 de distorsión identificables y

cuantificables. El proceso de calibración consiste precisamente en la obtención
de estos parámetros.
Figura 5.8: Distorsión tangencial. El plano de la imagen no es del todo paralelo

al de la lente.
5.6
En nuestro caso tan solo consideramos 4 (2 de distorsión radial y 2 de distorsión tan-
gencial), pero en otras situaciones es necesario el uso del conjunto total.
5.2. Posicionamiento 3D mediante el sistema de visión 71
5.2. Posicionamiento 3D mediante el sistema

de visión
El sistema completo estará formado por la cámara del sistema acoplada

rígidamente a la IMU y un objeto de control apropiado para la tarea a reali-
zar. Se denomina al sistema de coordenadas ligado a la cámara como {C}. Por
otro lado, se tiene que el objeto visualizado por la cámara será una plantilla
plana que se corresponde con el objeto de calibración usado para la calibración
interna, es decir, el denominado tablero de ajedrez. El sistema ligado al mismo
se denomina {O}.
En la Figura 5.9 se muestran todos los elementos mencionados junto al

sistema de coordenadas de la IMU, {G} , y el sistema de coordenadas inercial,
{W}.
Figura 5.9: Sistemas de coordenadas involucrados y nomenclatura.
En general, tal y como se ha expresado en la fórmula 5.9, la posición y

orientación de un sistema cualquiera {B} respecto a otro sistema {A} podría
expresarse mediante la matriz de transformación homogénea a Tb :
5.2. Posicionamiento 3D mediante el sistema de visión 72
" #
a a
a Rb tb
Tb =
01x3 1
Si se plantea la posición y orientación de {G} respecto de {W}:
" #
w w
w Rg tg
Tg =
01x3 1
Si bien la matriz de rotación anterior es fácilmente extraíble del vector ω θg ,

no se podrá disponer de la matriz w Tg completa, dado el desconocimiento de
w
tg . Ésta es la principal deficiencia que se intenta paliar con la introducción
del sistema de visión.
Como se ha explicado en capítulos anteriores, uno de los principales moti-

vos para la puesta en marcha del sistema de visión es conseguir un seguimiento
tridimensional de algún objeto (es una de las alternativas implementadas), y
la consiguiente estimación de la posición y orientación del mismo respecto de
la cámara (o de forma equivalente, la posición y orientación de la cámara res-
pecto del sistema de coordenadas del objeto). A este proceso se le denomina
también como calibración externa, y en cada instante nos proporciona una
estimación de la matriz c To (o de forma equivalente, o Tc =c T−1
o ).
Por otro lado, se supone conocida la transformación existente entre los

sistemas de coordenadas {C} y {G} mediante 5.9, g Tc . Esta matriz se habrá
calculado a partir de un proceso de calibración fuera de línea conocido como
calibración IMU-cámara. Una vez que se haya establecido esta relación, será
constante, puesto que se establece un acoplamiento rígido mecánico entre am-
bos sensores. Dada esta matriz, es posible obtener la posición y orientación
de la IMU respecto al sistema de coordenadas del objeto:
o
Tg =o Tc ·g T−1
c
De esta forma se tiene completamente posicionada la IMU, y en conse-

cuencia el quadrotor respecto al sistema de coordenadas del objeto, {O}. En el
capítulo 8 se detalla con mayor profundidad la relación final entre los distintos
sistemas de referencia.
5.3. Proceso de calibración 73
5.3. Proceso de calibración

5.3.1. Base teórica
En la calibración de la cámara se estiman los parámetros intrínsecos y ex-

trínsecos. Su precisión es importante pues a partir de ellos se obtiene informa-
ción métrica de la escena tal como dimensiones reales del objeto, profundidad,
movimiento a partir de imágenes, posiciones, orientaciones, etc. También en la
calibración de la cámara se determinan las distorsiones geométricas producto
de las imperfecciones de la cámara (distorsiones radial y tangencial).
La calibración de la cámara es llevada a cabo al observar un objeto de cali-

bración cuya geometría en el espacio 3D es conocida con muy buena precisión.
Usualmente el objeto de calibración consiste en uno o varios planos (si hay
varios planos, suelen establecerse perpendiculares entre sí) en los cuales se ha
impreso un determinado patrón de calibración (Figura 5.10).
Los parámetros de la cámara son recuperados a partir de la relación entre

las coordenadas tridimensionales del objeto con sus correspondientes proyec-
ciones bidimensionales en la imagen, como por ejemplo en el método de trans-
formación lineal directa (DLT).
En el método utilizado en el presente proyecto se utiliza simplemente un

único plano con un patrón de calibración impreso, denominado afectuosamen-
te como tablero de ajedrez, y usando un método basado en el algoritmo de
Zhang, en el cual los parámetros de la cámara son obtenidos a partir de la
transformación 2D entre el plano del patrón y el plano de la imagen.
Figura 5.10: Objetos de calibración planar y cúbico.

Figura 5.11: Detalle de una de las capturas del objeto para la calibración.
Este tipo de objetos son muy buenos para procesos de calibración por va-
rios motivos: se conoce perfectamente el modelo del objeto, y además el punto
característico se encuentra con una precisión bastante buena, porque es un
punto en el que el cambio de la intensidad del color es máximo.
Existen también métodos de autocalibración, en los cuales no se utiliza nin-

gún objeto de calibración; éstos se basan en un conjunto de imágenes tomadas
por la cámara en diferentes posiciones y orientaciones sobre una escena estáti-
ca. En estos casos, la rigidez de la escena genera un conjunto de restricciones
sobre los parámetros intrínsecos de la cámara que son recuperados a partir de
varias imágenes.
En la literatura se presentan diversas propuestas tanto para alternativas

donde no es necesario una calibración propia de la cámara como aquellas don-
de sí lo es, como por ejemplo, métodos basados en propiedades de los puntos
de fuga, entre otros, que no se detallan por no ser uno de los objetivos del
presente proyecto.
A continuación se describe el método de Zhang, base teórica del método

usado para la calibración de la cámara. Se eligió este método por la flexibilidad
en su aplicación pues no necesita del conocimiento de la posición y orientación
del patrón en el espacio de trabajo. La calibración en este método parte de
tomar la imagen del patrón ubicado en diferentes posiciones y orientaciones
de tal manera que abarque el mayor conjunto posible de alternativas, para
asegurar una gran riqueza en la información visual del patrón.
Además de este método existen otras aproximaciones, en función del ca-

rácter del sistema de ecuaciones que se planteen: bien puede ser un sistema
lineal (como es este caso) o no lineal. Dado que no es objetivo de esta memoria
discernir entre estos dos métodos, se refiere al lector a consultar [13],[19],[15]
y [23] para más información.
5.3.1.1. Método de Zhang
Si se considera 5.8, la relación entre un punto tridimensional P̃ = [Xw Yw Zw 1]

en el sistema de coordenadas del mundo, y su proyección en la imagen p̃ =
(x, y, 1)T puede ser escrita como:
λp̃ = K[R t] P̃
donde λ es un factor de escala, R y t son los parámetros extrínsecos y K es

la matriz de parámetros intrinsecos de la cámara. Si se asume que el patrón
de calibración “descansa” en la coordenada Zw = 0 en el sistema del mundo,
la anterior expresión puede ser escrita como:
Xw
 
   
x Xw
 Yw 
λ y 

 = K [ r1 r2 r3 t ] 

 = K[ r1 r2 t]  Yw 

(5.21)
 
 0 
1 1
1
donde se ha representado a la matriz de rotación por medio de sus columnas

ri . Como todos los puntos del patrón de calibración “descansan” sobre el
mismo plano, se puede asumir que P̃ = [Xw Yw 1] el cual está relacionado con
el punto p̃ en la imagen a través de una homografia H (ver sección 8.2.1.1):
λm̃ = HM̃ (5.22)

Comparando las dos expresiones anteriores y expresando la homografia en
base a sus columnas se tiene que :
H = [h1 h2 h3 ] = K[r1 r2 t] (5.23)

Por las propiedades de la matriz de rotación R, sus dos primeras columnas
cumplen con la condición de ortonormalidad:
rT1 r1 = rT2 r2
rT1 r2 = 0 (5.24)
Considerando 5.23 se puede volver a escribir la ecuación anterior como:
h1T K−T K−1 h1 = h2T K−T K−1 h2

h1T K−T K−1 h2 = 0 (5.25)
A partir de estas dos restricciones, se encuentran los elementos de la matriz

K . Para hallarlos se propone una solución analítica seguida de una optimiza-
ción no lineal.
Si la matriz K−T K−1 se expresa de la forma:

 
B11 B12 B13
K−T K−1 = B =  B21 B22 B23  (5.26)
 
B31 B32 B33

donde B es una matriz simétrica (u0 y v0 son los coordenadas del punto
principal de la imagen ), y equivale a:
 1 −γ γv0 −fy u0 
fx2 fx2 fy fx2 fy
−γ γ2 −γ(γv0 −fy u0 )
 
B=

fx2 fy fx2 fy2
+ f12 fx2 fy2
− fv02 
 (5.27)
y y
(γv0 −fy u0 )2 v02
 
γv0 −fy u0 −γ(γv0 −fy u0 )
fx2 fy2 fx2 fy2
− fv02 fx2 fy2
+ f2 + 1
y y
puede ser fácilmente representable como un vector de seis elementos
b = [B11 B12 B22 B13 B23 B33 ]T
Sea hi = [hi1 hi2 hi3 ]T la i-ésima columna de la matriz de homografía H;

entonces se verifica que:
hiT Bhj = vij

T
b (5.28)
donde vij = [hi1 hj1 , hi1 hj2 +hi2 hj1 , hi2 hi2 , hi3 hj1 +hi1 hj3 , hi3 hj2 +hi2 hj3 , hi3 hj3 ]T .
Por lo tanto las restricciones planteadas en 5.25 pueden ser re-escritas como
una ecuación homogénea en b de la forma:
" #
T
v12
b=0 (5.29)
(v11 − v12 )T
donde se tendrán tantas ecuaciones como imágenes del plano se tengan;
las cuales se pueden apilar para formar un sistema de la forma:
Vb = 0 (5.30)
donde V es una matriz de 2n × 6, siendo n el número de imágenes, y al
menos debe cumplirse que n ≥ 3 para obtener una solución única para b . Se
sabe que la solución a un sistema como el anterior es el vector propio de VT V
asociado a su valor propio más pequeño.
Una vez que se consigue estimar b , se obtienen a partir de éste todos los
parámetros intrínsecos:
2
v0 = (B12 B13 − B11 B23 )/(B11 B22 − B12 )
0 2
λ = B33 − [B13 + v0 (B12 B13 − B11 B23 )]/B11
q
fx = λ0 /B11
q
2
fy = λ0 B11 /(B11 B22 − B12 ) (5.31)
γ = −B12 fx2 fy /λ0
u0 = γv0 /[fy − (B13 fx2 /λ0 )]
Tras obtener una estimación de la matriz K, los parámetros extrínsecos se

calculan a partir de la expresión 5.23 por:
r1 = λK−1 h1
r2 = λK−1 h2 (5.32)
r3 = λK−1 h3
donde λ = 1/ k K−1 h1 k= 1/ k K−1 h2 k .
Una vez obtenidos estos datos, sirven como datos iniciales para una etapa
de refinamiento a través de técnicas iterativas, donde además se estiman las
distorsiones radial y tangencial.
5.3.2. Proceso de calibración en la práctica
Durante el desarrollo del proyecto, dado que hasta el momento todo lo que
se había implementado había sido usando la libreria OpenCV en su versión
2.0, se propuso en una primera aproximación usar las funciones para calibra-
ción propias de esta librería.
Sin embargo, tras los primeros resultados en los que la reconstrucción par-
cial de los puntos de la imagen no se correspondían con los puntos reales
tridimensionales, y los parámetros intrínsecos contenían algunos errores, se
optó por una calibración externa, fuera de línea, basada en el mismo algorit-
mo que el expuesto en la sección anterior, pero usando para ello la plataforma
de Matlab.
Se usó un toolbox de calibración para Matlab, cuya documentación necesa-

ria se encuentra en [14]. Tras realizar unas primeras pruebas con este método
se concluyó que era el ideal para realizar el proceso de calibración final sobre
la cámara. Para una visión global, en primer lugar se detallan los pasos pa-
ra la calibración que se siguieron usando [120] y posteriormente se detalla el
proceso de calibración usando el toolbox de Matlab.
5.3.2.1. Calibración con OpenCV
Tal y como se ha expuesto en las secciones anteriores, para el proceso de

calibración es necesario disponer de un objeto con un patrón determinado y
realizar múltiples vistas del mismo. El número de imágenes influye en la pre-
cisión de los parámetros a estimar, por lo que se intenta que sea un número
relativamente grande (entre 10 y 15) con vistas relativamente distintas del
objeto de calibración.
En este caso, se disponía de una plantilla estilo tablero de ajedrez, cuya

geometría era conocida (ancho y alto de cada cuadrado de 22.3 mm) y cuyo pa-
trón de puntos era también conocido; esto es, se definía una matriz con tantas
columnas como corners 5.7 tuviera a lo ancho y tantas filas como corners tuvie-
ra a lo alto. En la Figura 5.12 se puede ver con detalle un corner en el tablero.
5.7
También denominado como punto característico.
Figura 5.12: Detalle de corners en el objeto de calibración.
Para extraer las coordenadas de los puntos del objeto en el plano de la

imagen se utilizaba la función cvFindChessboardCorners(). Esta función reci-
bía como parámetros la imagen captada por la cámara, el ancho y alto del
objeto patrón, y unas máscaras de comportamiento.
Los resultados devueltos por esta función eran, ordenados por filas y colum-
nas, las coordenadas de los corners en el plano de la imagen. Posteriormente
se aplicaba una función para obtener una mejor precisión en las coordenadas
extraídas, cvFindCornerSubPix().Una vez que se tenían suficientes puntos del
mismo objeto visto desde varios puntos de vista (Figura 5.13), el siguiente
paso consistía en calcular los parámetros intrínsecos de la cámara.
Figura 5.13: Imágenes del tablero de ajedrez vistas desde varios puntos dis-
tintos.
Para ello, se usaba la función cvCalibrateCamera2(), la cual realizaba la

correspondencia de los puntos bidimensionales a los tridimensionales, obte-
niendo como resultado la matriz de parámetros intrínsecos, K, y los paráme-
tros correspondientes a las distorsiones radial y tangencial, como un vector de
5 posiciones: k1 , k2 , p1 , p2 y k3 .
Calculados los parámetros intrínsecos, el siguiente paso era calcular la posi-

ble reconstrucción 3D a partir de una imagen de partida (Figura 5.14), usando
para ello la función cvFindExtrinsicCameraParams2().
Figura 5.14: Reconstrucción 3D teórica.
Extraídos la matriz R y el vector t como resultados devueltos de la ante-

rior función, la idea era que dada la imagen del objeto, estática, y desplazando
el sistema de coordenadas de la cámara, fuera posible una reconstrucción par-
cial a partir de la fórmula 5.8, usando para ello la función cvProjectPoints2(),
obteniendo un resultado como el mostrado en la Figura 5.15.
Figura 5.15: Reconstrucción 3D real.
Dado que los resultados eran difíciles de interpretar y no se correspondían

con errores identificables en los parámetros, se concluyó que el proceso de ca-
libración se había realizado con errores, por lo que se optó por usar un método
más robusto, y con cierta popularidad, como el usado en [14], y explicado a
continuación.
5.3.2.2. Calibración con el toolbox de Matlab
La cámara sobre la cual se ha realizado el proceso de calibración es una

cámara monocromo de resolución (HxV ) 752x480 pixels, con sensor CMOS
de 1/3” (pixel cuadrado de 6µm de ancho y alto), en concreto el modelo uEye
UI-1220-M de IDS, a la que se le ha acoplado una óptica fija estándar COS-
MICAR/PENTAX de 12mm de distancia focal nominal.
En la Figura 5.16, se muestra en detalle la cámara con una indicación de

la ubicación estimada del origen de su sistema de coordenadas, así como la
plantilla empleada para la calibración, también con su sistema de coordenadas
asociado.
Figura 5.16: Cámara y plantilla de calibración con los correspondientes siste-

mas de coordenadas.
Para realizar el proceso de calibración con este toolbox, se siguieron las

instrucciones dadas en el primer ejemplo de [14]. Los pasos a seguir para
conseguir una buena calibración de la cámara son los siguientes:
Paso 1:
Iniciamos Matlab y tecleamos el comando calib_gui. Aparecerá un diá-
logo en el cual podremos establecer si queremos “cargar” todas las imá-
genes a la vez, o si de lo contrario, estimamos mejor una por una. En
nuestro caso se eligió la segunda opción:
Paso 2:
Cargamos el conjunto de imágenes que hayamos estimado necesarias
para la calibración (en este caso, el total de imágenes son 17):
Paso 3 :
En este paso se extraen bien de forma manual o automática los corners
de las diferentes imágenes consideradas. Además, para cada imagen (se
puede evitar modificando un archivo de configuración) es necesario in-
troducir:
- Tamaño de la ventana de búsqueda del corner: por defecto suele ser una
ventana de 11x11 píxeles alrededor de cada punto (propio píxel 1x1,y
ventana de 5 alrededor, implica que por cada componente: 5+1+5 = 11
píxeles).
- Tamaño en cm. del alto y ancho de cada cuadrado del tablero.
Una vez que se han introducido los parámetros anteriores, se opta por
una localización automática de los puntos, pero previamente definiendo
las 4 esquinas del tablero. En este aspecto, es muy importante resaltar
que el orden en el que se seleccionen los 4 puntos afecta a la posterior
representación del sistema de coordenadas del objeto, por lo que ayu-

dándonos de una pequeña marca en el tablero, se puede definir siempre
el orden de los 4 puntos en sentido horario a partir del punto considerado
como origen del sistema de referencia. Este hecho se puede observar en
la Figura 5.17.
Figura 5.17: Localización automática de los puntos y origen del sistema de

referencia del objeto.
En algunas situaciones, la localización automática de los puntos no de-

vuelve las coordenadas precisas de algunos corners. Es en este punto
donde se identifican los parámetros de distorsión de la lente. La idea
es sencilla: se traza una recta entre los puntos de los extremos de cada
esquina, y se espera que los puntos intermedios caigan en dicha recta.
Por lo que si hay algunos puntos que no pertenecen a dicha recta, habrá
que curvar a ésta ligeramente para que los puntos caigan en la misma.
Es el efecto visto en la Figura 5.4.
A continuación se muestra cómo antes de la modificación del parámetro

kc algunos puntos están lejos de la recta de intersección; y tras modifi-
car este parámetro a un valor entorno a -0.5 de media para todas las
imágenes, el resultado es más satisfactorio.
Figura 5.18: Situación de los puntos antes de realizar la corrección manual.
Figura 5.19: Situación de los puntos después de realizar la corrección manual.

Estas correcciones se realizaron para todas y cada una de la imágenes.

Después de realizar un proceso de optimización, los resultados iniciales
son los mostrados en la siguiente tabla:
Parámetro Valor
Distancia Focal [ 2043.22731 2044.63891 ] ± [ 2.60624 2.53574 ]
Punto Principal [ 354.84891 240.45905 ] ± [ 5.42588 3.96191 ]
γ alpha_c = [ 0.00000 ] ± [ 0.00000 ]
Distorsión [ -0.36695 0.93446 0.00009 -0.00052 0.00000 ] ±
(k1 , k2 , p1 , p2 , k3 ) [ 0.02283 0.91265 0.00038 0.00025 0.00000 ]
Píxel Error [ 0.09024 0.09061 ]
Paso 4 :
Tras la obtención de los resultados anteriores, a continuación es posible
calcular los parámetros extrínsecos respecto a las distintas imágenes de
entrada, y calcular la reproyección de los puntos (Figura 5.20) y el error
asociado.
El cálculo de la reproyección del error (esto es, la diferencia de posición

entre el punto en la imagen real y el punto en la imagen estimado, Fi-
gura 5.21) es muy útil para determinar si se ha realizado correctamente
el proceso de calibración. Si el error es del orden de décimas de píxel
(Figura 5.22), entonces se ha realizado la calibración con éxito.
Figura 5.20: Reproyección del conjunto de puntos sobre los puntos reales de
la imagen.
Figura 5.21: Detalle de la diferencia entre punto de la imagen real (rojo) y

punto reproyectado (azul).
Si de lo contrario, la media del error varia hasta varias unidades de píxel,

es necesario o bien realizar todo el proceso de calibración de nuevo o
bien recalcular tan solo los puntos en aquella imagen que haya dado
problemas.
Figura 5.22: Reproyección media del error.

En las Figuras 5.23 y 5.24 se muestra una representación del conjunto

de imágenes tomadas del tablero, respecto del origen de coordenadas del
mundo (cámara).
Figura 5.23: Representación 3D de los parámetros extrínsecos (1).
Figura 5.24: Representación 3D de los parámetros extrínsecos (2).

Paso 5 :
Si se han realizado modificaciones en la posición inicial de puntos en
la imagen, sería necesario volver al paso 3 y recalcular de nuevo todos
los parámetros intrínsecos de la cámara. En el presente proceso de ca-
libración, para afinar al máximo la calidad de estos parámetros, dicho
proceso se tuvo que realizar varias veces.
Finalmente, los resultados obtenidos y verificados con Matlab tras el

proceso de calibración para la cámara indicada al comienzo de la sec-
ción , son los siguientes:
Parámetro Estimación (px) Comentarios

fx 2043.2402 Sabiendo que la anchura efectiva del pixel es
de 6µm, esto es equivalente a 12.259442mm.
fy 2044.6518 Sabiendo que la altura efectiva del pixel es
de 6µm, esto es equivalente a 12.267911mm.
cx 354.8575 Coordenada x del punto principal en la imagen.
cy 240.4531 Coordenada y del punto principal en la imagen.
p1 −0.3668
p2 0.9305 Coeficientes de distorsión radial de la lente.
p3 0.00008
t1 −0.0005 Coeficientes de distorsión tangencial de la lente.
t2 0.0000
Capítulo 6
Implementación de mecanismos
para la extracción de
información visual
En el presente capítulo se presentan el conjunto de propuestas implemen-

tadas para la extracción de la información visual necesaria para cerrar el lazo
de control visual del quadrotor. Se proponen también posibles mejoras y al-
ternativas al control visual. Según lo presentado en el capítulo 4, en función
de cómo se considerase al objeto de interés, tridimensional o plano, se podían
aplicar diferentes métodos para la detección y seguimiento.
En la primera propuesta se considera al objeto en todas sus dimensiones,

conociendo además perfectamente su geometría. Sin embargo, para la segun-
da alternativa se ha considerado al objeto de referencia (se continúa haciendo
pruebas con el tablero de ajedrez) plano, sin ninguna información sobre su
geometría.
Al final del capítulo se exponen posibles alternativas y ampliaciones para

esta tarea. Se presenta además la primera técnica que se desarrolló, el segui-
miento basado en plantillas, o template matching. Éste método fue rápida-
mente descartado debido a los problemas que son expuestos en esta sección.
El código correspondiente a todas las propuestas se puede consultar en el
Apéndice A, si bien alguna de las funciones utilizadas son detalladas en este
capítulo.
91
6.1. Objeto de referencia tridimensional 92
6.1. Objeto de referencia tridimensional
La información visual que se extrae con el conjunto de propuestas im-

plementadas en este capítulo sirve para obtener los parámetros de rotación y
traslación, de manera que fusionándolos con los datos provenientes de la IMU,
se cierra el lazo de control en la técnica denominada control visual basado en
posición (PBVS - Position Based Visual Servo), en la que es necesario conocer
tanto la geometría de la cámara como la del objeto. En esta propuesta se tra-
ta de localizar al objeto de referencia con la cámara, estimar los parámetros
extrínsecos (esto es, rotación y traslación del objeto respecto del sistema de
coordenadas de la cámara) y realizar un seguimiento de las características del
objeto en una secuencia de imágenes.
El resultado final, presentado en la Figura 5.15, desde el punto de vista del

autor, es bastante interesante. Principalmente por varios motivos: el quizás
más llamativo pudiera ser el que, si se considerara otro objeto de interés, por
ejemplo, una figura de dinosaurio, y se definiera al completo toda su geome-
tría, una de las aplicaciones directas de este tipo de técnicas es la de la realidad
aumentada o, incluso, realidad virtual.
La realidad aumentada es el término que se usa para definir una visión

directa o indirecta de un entorno físico del mundo real, cuyos elementos se
combinan con elementos virtuales para la creación de una realidad mixta a
tiempo real. Consiste en un conjunto de dispositivos que añaden información
virtual a la información física ya existente. Esta es la principal diferencia con
la realidad virtual, puesto que no sustituye la realidad física, sino que sobre-
imprime los datos calculados al mundo real.
La razón principal por la cual se escogió el tablero de ajedrez como objeto

de interés es obvia; aparte de porque había sido el objeto para la realización
de la calibración interna de la cámara, es porque su geometría (puntos por
filas y por columnas) es sencilla de implementar.
Se podría haber considerado otro objeto, como por ejemplo, el dinosaurio

de la imagen; pero la definición de su geometría hubiera sido relativamente
más compleja. Una vez que se hayan calculado la rotación y traslación del
objeto respecto de la cámara (o viceversa) en cada escena, estos parámetros
serán introducidos al controlador para conseguir, con un control robusto, que
el quadrotor sea capaz de seguir al objeto de referencia.
Figura 6.1: Ejemplo de realidad aumentada.
Así pues, se supone que se dispone de los siguientes elementos en el labo-

ratorio:
Cámara: Cámara calibrada, o al menos se dispone de los parámetros

intrínsecos obtenidos con el proceso de calibración interna, visto en el
capítulo 5. Correctamente conectada al ordenador, y transmitiendo en
modo contínuo6.1 .
Objeto de interés: Se dispone de la plantilla del tablero de ajedrez, co-

nociendo perfectamente su geometría (midiendo el alto y ancho de sus
cuadrados con un calibre como el de la Figura 6.2, por ejemplo).
El algoritmo básico que resume los pasos a seguir para lograr el objetivo es el
expuesto en Algoritmo 6.1.
6.1
Más adelante se presentan los problemas relativos a este modo de captura.
Algorithm 6.1 Algoritmo general para la extracción de información visual

para el esquema de control PBVS.
Inicio ControlPBVS_Propuesta_I
ReservaEstructurasMemoria(...)
InicializacionCamara(camara)
[MatrizIntrinseca,ParametrosDistorsion]:=
CalibracionInterna(camara)
PuntosObjeto :=
DefiniciónGeometriaObjeto(tablero_ajedrez)
mientras (cierto):
imagen := CapturaImagen(camara)
PuntosImagen := LocalizarObjetoControl(imagen)
[Rotacion,traslacion]:=
CalculaCalibracionExterna(PuntosImagen,PuntosObjeto)
imagenColor :=
ProyectaPuntos(PuntosObjeto,
Rotacion,traslacion,
MatrizIntrinseca,ParametrosDistorsion,..)
fin mientras
LiberaRecursosMemoria(..)
LiberaCamara(camara)
Fin Algoritmo
Figura 6.2: Herramienta de precisión necesaria para determinar la geometría

del objeto de interés.
6.1.1. Representación, localización y seguimiento del

objeto de referencia
Era relativamente sencillo localizar los puntos característicos o corners

de un tablero de ajedrez después de consultar la documentación de OpenCV
[120],[33] y [67]. Dado que la función cvFindChessboardCorners() fue utilizada
en una implementación anterior para el proceso de calibración interna de la
cámara, fue fácil adaptarla al nuevo código para la obtención de las coorde-
nadas de los puntos característicos en el plano de la imagen. Además, dichos
corners de la parrilla interior de puntos del tablero de ajedrez presentan unas
propiedades muy buenas para la localización y seguimiento, no tanto como
pudiera tener otro objeto de interés.
Figura 6.3: Ejemplo de localización de corners por intersección de rectas.
Existen muchas propuestas para la localización de dichos puntos: detector

de corners de Harris; intersección entre rectas interiores al tablero usando al-
goritmos de detección de bordes, como Canny, etc. Incluso existen propuestas,
como la mostrada en [67], en las que se muestran situaciones donde el tablero
se deforma y algoritmos como los anteriores fracasarían en la localización de
los puntos.
No existe en la literatura ninguna referencia a cómo se ha implementado

la función cvFindChessboardCorners(), pero se puede suponer que bien podría

haber sido implementada siguiendo una combinación de las propuestas ante-
riores. Eso sí, cabe resaltar que esta función no es útil en situaciones en las
que el tablero se deforme considerablemente.
En cada toma, para la localización de los puntos interiores al tablero, se

usa la función de OpenCV cvFindChessboardCorners(), cuyo prototipo es el
siguiente:
int cvFindChessboardCorners(
const void* image,
CvSize pattern_size,
CvPoint2D32f* corners,
int* corner_count = NULL,
flags = CV_CALIB_CB_ADAPTIVE_THRESH );
Descripción de los parámetros:
image :
Imagen de entrada capturada por la cámara, donde se supone que está
presente el tablero. Es necesario que la imagen esté en formato de 8 bits
monocromo.
pattern_size :
Estructura para la definición de tamaño en OpenCV. Se indican el nú-
mero de filas y columnas, especificados por el número de corners internos
a lo ancho y número de corners internos a lo alto del tablero.
corners :
Estructura tipo array de OpenCV en la que se almacenan las coordena-
das (del plano de la imagen) correspondientes a los puntos extraídos del
tablero.
corner_count :
Puntero a entero, en el cual se indica el número de corners del tablero
encontrados.
Máscaras de comportamiento :
CV_CALIB_CB_ADAPTIVE_THRESH: Se usará un umbral adap-

tativo para el contraste en la imagen para la localización de los
corners.
CV_CALIB_CB_FILTER_QUADS: Conjunto de restricciones son

aplicadas para rechazar posibles falsos corners.
Una limitación que presenta esta función es que si el tablero completo no está
contenido dentro de la escena, y no se detecta, por ejemplo, una fila o colum-
na, no devuelve el conjunto de puntos de la parte del tablero visible, dado que
no cumple con los parámetros de entrada indicados.
En la propuesta indicada en la sección 6.2, se implementa un método dis-

tinto el cual sí devuelve los puntos del objeto en la escena, incluso aún cuando
aquel esté parcialmente fuera de la misma.
Una vez que se han extraído de la imagen las coordenadas donde se supone
que están presentes los puntos característicos internos del tablero, el siguiente
paso es aplicar un proceso de refinamiento sobre el conjunto de coordenadas,
para precisar aún más la localización de los puntos característicos o corners
obtenidas en el primer paso.
Esta tarea se realiza con la función cvFindCornerSubPix():
void cvFindCornerSubPix(
const CvArr* image,
int count,
CvSize win,
CvSize zero_zone,
CvTermCriteria criteria );
Descripción de los parámetros:
image,corners y count :
Igual que en el caso anterior, salvo que se supone que en image están
presentes los corners pasados como argumento de entrada.
win :
Estructura en OpenCV para especificar el tamaño de la ventana de bús-
queda del punto característico, en píxeles. En el presente trabajo, se
considera una ventana de 5x5 de radio desde la posición del punto. Con
lo que sumando el tamaño del píxel en horizontal y vertical queda una
ventana de CvSize(11,11) (ventana de tamaño 11x11).
Figura 6.4: Precisión en la localización de los corners, basado en el gradiente

del punto en la imagen.
zero_zone :
Parámetro opcional de la función. Establecido al valor CvSize(-1,-1). No
relevante para el caso actual.
criteria :
Se establecen el número de iteraciones máximo en el proceso de búsque-
da. En nuestro caso:
cvT ermCriteria(CV _T ERM CRI_T P S | CV _T ERM CRIT _IER, 30, 0,1).
El algoritmo iterará un número máximo de iteraciones que se establece
en 30 ó cuando se haya alcanzado una precisión del 10 %.
Tras guardar las coordenadas de los puntos en estructuras de memoria in-

termedias, y obtenidas las coordenadas precisas de la localización de los puntos
del tablero, queda realizar la representación de la geometría del objeto, defi-
niendo los puntos del objeto, y calcular los parámetros extrínsecos del sistema.
Esto es, realizar el cálculo de la rotación y traslación de los puntos del

objeto respecto del sistema de coordenadas de la cámara, asumiendo que tanto
la cámara como el objeto pueden desplazarse en cualquier momento. El objeto
se ha definido como una malla de puntos, ordenados por filas y columnas, cuya
distancia de separación es exactamente 22.30 mm (Algoritmo 6.2).
La tercera coordenada se establece a 0, puesto que se supone que el objeto
descansa sobre el plano que contiene al sistema de referencia propio. Cabe
Algorithm 6.2 Representación virtual del objeto.

// Bucle externo a lo largo del eje X
desde i = 0 hasta i < numCornersEjeX
paso: i++
{
// Bucle interno a lo largo del eje Y
numCorner = i*numCornersEjeY;
desde j = 0 hasta j < numCornersEjeY:
paso: j++, numCorner++
{
Objeto.PuntosObjeto[numCorner, 0] = i*tamCuadradoMm;
Objeto.PuntosObjeto[numCorner, 1] = j*tamCuadradoMm;
Objeto.PuntosObjeto[numCorner, 2] = 0.0f;
}
}
destacar que la función de extracción de puntos de la imagen devuelve los

puntos primero por filas, y después por columnas; este es el motivo por el cual
se haya definido del mismo modo para los puntos del objeto.
Un último detalle es indicar qué se considera eje X y eje Y respecto del

sistema de coordenadas del objeto. En la siguiente imagen se representan los
tres ejes de coordenadas, considerando el origen del sistema la esquina superior
izquierda del tablero, opuesta a la “marquita” de posición (se puede apreciar
en la Figura 6.5 parte inferior derecha un punto negro).
Figura 6.5: Representación de los ejes del sistema de coordenadas del objeto.
6.1.2. Cálculo de los parámetros extrínsecos
En OpenCV existe una función que permite calcular los parámetros in-
trínsecos y extrínsecos al mismo tiempo: cvCalibrateCamera2(). Ésta fue la
primera opción que se propuso para el cálculo de la matriz de rotación y el
vector de traslación. Sin embargo, durante los experimentos se comprobó que
el tiempo consumido por esta función era excesivo, con lo que se propuso una
segunda alternativa, la cual dió resultados bastante buenos. Esta función es la
denominada cvFindExtrinsicCameraParam2(), la cual se detalla a continua-
ción:
void cvFindExtrinsicCameraParams2(
const CvMat* object_points,
const CvMat* image_points,
const CvMat* intrinsic_matrix,
const CvMat* distortion_coeffs,
CvMat* rotation_vector,
CvMat* translation_vector );
La descripción de los parámetros es la siguiente:
object_points :
Representación virtual de la geometría del objeto. Presentada en el Algo-
ritmo 6.2. Coordenadas tridimensionales respecto al sistema del objeto.
image_points :
Coordenadas bidimensionales respecto al plano de la imagen de los pun-
tos extraídos con la función cvFindChessboardCorners().
intrinsic_matrix :
Función de parámetros intrínsecos de la cámara K .
distortion_coeffs :
Vector de coeficientes de distorsión radial y tangencial. Expresado de
la forma: k1 , k2 , p1 , p2 y k3 (donde ki indican coeficientes de distorsión
radial y pi coeficientes de distorsión tangencial).
rotation_vector :
Vector de rotación, en el que se devuelve, por cada eje, el vector unitario
asociado y el ángulo de giro sobre el mismo. Para obtener la matriz
de orden 3 necesaria para la aplicación, se puede usar la función de
OpenCV cvRodrigues2(), aunque en el presente caso se ha hecho uso de

una función definida en el archivo matrix.hpp (veáse Apéndice A para
más detalles). Esta función se basa en la siguiente relación:
θ ← norm(r)
r ← r/θ
 
0 −rz ry
T
R = cosθI − (1 − cosθ)rr + sinθ  rz

0 −rx 

−ry rx 0
donde la matriz R es de orden 3 y el vector r es un vector de 1 fila y 3

columnas.
translation_vector :
Vector de traslación del sistema. Los valores devueltos están expresados
en mm.
6.1.3. Proyección tridimensional
El siguiente paso es en el se puede verificar con total seguridad:
Si la calibración interna de la cámara se ha realizado correctamente.
Si se ha definido correctamente al objeto tridimensional.
Si se ha realizado correctamente la extracción de los parámetros extrín-

secos del sistema.
Si alguna de las tres etapas anteriores se ha superado con algún tipo de error,
la reproyección de la estimación de los puntos del objeto no será adecuada, y
por lo tanto, la reconstrucción 3D del mismo contendrá errores. Esto es, dada
una localización en el espacio tridimensional respecto del sistema de coorde-
nadas de la cámara, es posible reconstruir de forma unívoca donde debería
aparecer en el plano de la imagen en coordenadas expresadas en píxeles, el
punto externo tridimensional.
Esta transformación se realiza usando la función de OpenCV denominada

cvProjectPoints2(), descrita a continuación:
void cvProjectPoints2(
const CvMat* object_points,
const CvMat* rotation_vector,
const CvMat* translation_vector,
const CvMat* intrinsic_matrix,
const CvMat* distortion_coeffs,
CvMat* image_points,
..);
object_points :
Representación virtual de la geometría del objeto. Presentada en el Algo-
ritmo 6.2. Coordenadas tridimensionales respecto al sistema del objeto.
rotation_vector :
Vector de rotación, representado como rotación respecto a cada eje.
translation_vector :
Vector de traslación del sistema. Los valores devueltos están expresados
en mm.
intrinsic_matrix :
Función de parámetros intrínsecos de la cámara, K. Junto con los coefi-
cientes de distorsión, es usada para corregir geométricamente la imagen.
distortion_coeffs :
Vector de coeficientes de distorsión. Expresado de la forma: k1 , k2 , p1 , p2
y k3 (donde ki indican coeficientes de distorsión radial y pi coeficientes de
distorsión tangencial).
image_points :
Parámetro de salida; contendrá las coordenadas tridimensionales de la
localización del objeto, respecto del sistema de coordenadas de la ima-
gen. Posteriormente será usado para dibujar los puntos reproyectados.
Tras la ejecución de la anterior función, era posible dibujar la reproyección de

los puntos calculados sobre el tablero, consiguiéndose una precisión bastante
buena. Pero el último paso consistía en dibujar el eje Z sobre el tablero. Se
puede calcular fácilmente aplicando la fórmula (indicada en 5.1):
u v f
= =
Xc Yc Zc
Figura 6.6: Reconstrucción 3D del objeto de interés.
la cual indica que para conseguir la reconstrucción parcial completa es ne-

cesario dividir esa pequeña cantidad por la reproyección del eje Z.
Una vez subsanado el defecto, los resultados obtenidos se pueden observar

en la Figura 6.6, donde se observa una “reproyección del objeto tridimensio-
nal” del objeto de interés a partir de los parámetros extrínsecos del sistema.
6.1.4. Comprobación de resultados
El paso complementario para garantizar que los resultados devueltos de

rotación y traslación eran buenos era realizar un conjunto de pruebas, en las
que en cada momento se comprobaba cada componente por separado de am-
bos vectores. Así, en el laboratorio se dispuso de una plantilla, instalada sobre
la superficie de una mesa larga (de al menos 1.70 m), sobre la cual se habían
pintado marcas separadas a intervalos de 10 cm en sentido longitudinal e in-
tervalos de 1cm en sentido transversal.
Cabe resaltar que, durante el experimento, la cámara se había fijado a una

estructura la cual facilitaba enormente la tarea de garantizar que solamen-
te se desplazaba en la dirección que en ese momento se estaba midiendo. A
continuación se exponen tanto imágenes de la plantilla con la que se realizó
el conjunto de pruebas como las condiciones de cada prueba individual, y los
resultados experimentales obtenidos.
Figura 6.7: Plantilla para experimentos en el laboratorio.

Figura 6.9: Alineación de la cámara con la plantilla de referencia.
Figura 6.8: Detalle de las marcas de medición en la plantilla.

Con la implementación de esta primera propuesta, el lazo de control re-

alimentado con información visual tiene una velocidad de 10 fps, estimada
a partir de los experimentos en el laboratorio. Un último comentario acer-
ca de esta primera implementación (Apéndice A, clase CSensorCamara.hpp)
es que permite que el origen de la imagen sobre la que se extrae la informa-
ción bien pueda ser del flujo de la cámara, o de un archivo local en la máquina.
6.1.4.1. Experimentos
Cálculo de la profundidad :
En este experimento se establecía una posición fija para la cámara, y se
desplazaba el tablero o objeto de interés sobre la plantilla una distancia
determinada. Se realizaron varias combinaciones variando la profundi-
dad. Un ejemplo de las imágenes consideradas son las mostradas en la
Figura 6.10.
Figura 6.10: Situación inicial tablero (Izq). Situación final (Dcha).
El objetivo de este experimento era, sabiendo lo que se había desplazado

el tablero en profundidad, ver qué resultados se obtenían tras extraer
rotación y traslación por separado de cada una de las imágenes. Los
resultados obtenidos son los siguientes:
Imagen 1. Distancia: 150 cm.
Rotacion Obtenida: 2.226382 2.206937 0.003168

Traslación Obtenida: -152.037033 -96.652985 1475.505737
Imagen 2. Distancia: 120 cm.
Rotacion Obtenida: 2.226527 2.208627 -0.001606

Traslación Obtenida: -150.829361
-100.066978 1174.485474
Desplazamiento estimado: 1475 − 1174 = 301mm. Resultado con una

precisión bastante buena, si consideramos que el desplazamiento físico
realizado ideal, y de unos 30 cm.
En este caso, se observa que, aunque se haya establecido el tablero a 150

cm del centro del sistema de la cámara, la distancia calculada en Z (pro-
fundidad) es de 147,5mm. Esto es debido a que en primeras estimaciones
se consideró que el origen del sistema de la cámara estaba en un punto
del juego de lentes; pero tras comprobar que asumiendo esta posición la
distancia en Z no era correcta, se recalculó usando para ello las técnicas
mostradas en el capítulo anterior, y se obtuvo un nuevo punto para el
centro de este sistema, mostrado en la Figura 6.11.
Figura 6.11: Centro real estimado del sistema de coordenadas de la cámara.

Cálculo del desplazamiento Eje X :

De nuevo se establece la posición de la cámara fija, y se desplaza el
tablero sobre la plantilla una distancia determinada, pero esta vez en
sentido transversal de la plantilla, lo que se correspondería con eje Y del
sistema de coordenadas del tablero (eje X respecto del sistema de coor-
denadas de la cámara). Se realizaron varias combinaciones variando este
parámetro. Un ejemplo de las imágenes consideradas son las mostradas
en la Figura 6.12.
Figura 6.12: Situación inicial tablero (Izq). Situación final(Dcha).Se aprecia

desplazamiento en horizontal.
El objetivo de este experimento era, sabiendo lo que se había desplaza-

do el tablero en horizontal, ver qué resultados se obtenían tras extraer
rotación y traslación por separado de cada una de las imágenes. Los
resultados obtenidos son los siguientes:
Imagen 1. Distancia: 170 cm. Posición en x = 0.
Rotacion Obtenida: -2.213006 -2.228312 0.010414

Imagen 2. Distancia: 170 cm. Posición en x = 5.
Rotacion Obtenida: -2.207929 -2.225694 -0.009675

Traslación Obtenida: -146.946869
-123.890236 1695.04883
Desplazamiento estimado en X: 198,53 − 146,94 = 51,59mm . Resultado
con una precisión bastante buena, si consideramos que el desplazamiento
físico realizado es ideal, y de magintud unos 5 cm.
Cálculo del desplazamiento Eje Vertical :

En este caso, se mantiene en la misma posición al tablero, y es la cámara
la que desplazamos verticalmente para comprobar el desplazamiento en
el eje X del tablero (lo que importa no es la posición del tablero respecto
del sistema de coordendas del mundo, sino la posición relativa entre los
sistemas de la cámara y del tablero). Se realizaron algunas combinacio-
nes variando este parámetro. Un ejemplo de las imágenes consideradas
son las mostradas en la Figura 6.13.
Figura 6.13: Posición inicial (Izq) y posición final (Dcha).
El objetivo de este experimento era, sabiendo lo que se había despla-

zado la cámara en vertical, ver qué resultados se obtenían tras extraer
rotación y traslación por separado de cada una de las imágenes. El eje
Y de la cámara se corresponde con el eje X del tablero. Los resultados
obtenidos son los siguientes:
Imagen 1. Distancia: 160 cm. Posición en y = 14cm (cámara).

Rotacion nula.
Imagen 2. Distancia: 160 cm. Posición en y = 22cm (cámara)
Rotacion nula.
Traslación Obtenida: -159.771011 -69.654335
1605.76050
Además del vertical se han intentado minimizar el resto de componentes

del movimiento (evitar que la cámara se desplazara en horizontal, por
ejemplo). Desplazamiento estimado en Y: | 140,09 − 69,65 |= 70,44mm .

Si el desplazamiento en vertical había sido de 8cm, en este experimento
se puede asumir este error a pequeños errores en el conjunto de medi-
ciones en el planteamiento del experimento (por ejemplo, que la cámara
se hubiera desplazado ligeramente en sentido horizontal).
También se realizaron pruebas para medir la rotación del tablero respecto al

sistema de coordenadas de la cámara. Se puede observar en la Figura 6.14
las marcas en la plantilla para medir la rotación del tablero respecto a su
eje Y. En la Figura 6.15 se muestra un ejemplo de los experimentos de este
parámetro y se verifica que los resultados son relativamente precisos, tras
varias comprobaciones usando la plataforma Matlab.
Figura 6.14: Marcas en la plantilla para medir la rotación.
Figura 6.15: Experimentos para comprobar la rotación del tablero.

6.1.5. Problemas durante la implementación
Los problemas que surgieron en esta primera propuesta estuvieron relacio-

nados tanto con el proceso de implementación como el de la asimilación de
conceptos teóricos. El autor del presente proyecto nunca había trabajado en
este campo, y en un primer momento no veía cómo podían estar relacionados
un “simple” tablero de ajedrez, con la reconstrucción tridimensional del mis-
mo desde el plano de la imagen.
En mi Titulación no se ven este tipo de conceptos, y la última vez que éste

alumno vió geometría y sistemas de referencias fue en asignaturas de primer
curso. Así pues, esta complejidad ha ido en paralelo con algunos problemas
relacionados con la implementación, los cuales se detallan a continuación:
Plataformas de desarrollo: En las primeras fases del proyecto se comenzó

la implementación de código en la plataforma Microsoft Visual Studio
2008, con la versión de la libreria de OpenCV 1.6. Inicialmente, dado
que aún no se había determinado la extensión del proyecto, se comenzó
la implementación de una interfaz de usuario, como la presentada en
[16]. La idea era que ésta albergara posibles controles relacionados con la
estabilidad del vehículo aéreo, tales como posición GPS o aceleración. Se
descartó rápidamente, dado que la idea del proyecto no era la realización
de este tipo de interfaces.
Debido a que la mayor parte del código relacionado con el sensor inercial
se estaba desarrollando con otra plataforma de desarrollo, Dev C++, se
optó por migrar todo el código hacia esta alternativa. Si la configuración
de OpenCV sobre Visual Studio fue relativamente sencilla, en esta pla-
taforma no lo fue tanto. En el Apéndice B se propone una configuración
para esta plataforma.
De nuevo, se produjo un cambio, tanto en la plataforma de desarrollo

como en el sistema operativo. Se migró todo el código a Ubuntu 8.04,
usando como herramienta de compilación gcc (the GNU Compiler Co-
llection). Configurar la la versión 2.0 de la librería de OpenCV en esta
plataforma fue aún más complejo si cabe, puesto que el autor tenía ex-
periencia en programación en Windows; pero en Linux se tuvieron que
adquirir conocimientos medios y avanzados del sistema para poder con-
figurar con éxito esta librería. Así, una vez configurada la plataforma
final de desarrollo, se comenzó con la implementación de la presente
propuesta. En el Apéndice B se indica cómo se configuraría la librería
de OpenCV para Linux.
En OpenCV existe una función denominada cvCreateCameraCapture(),

la cual, y pasándole un identificador de dispositivo de captura de ima-
gen, es capaz de devolver un flujo contínuo del cual se pueden extraer
imágenes a una frecuencia dada. Pero al instalar el dispositivo de imagen
utilizado, se comprobó que éste no se identificaba en el sistema como de
captura de imágenes, sino como dispositivo de tipo uEye. Se tuvo pues
que acudir al manual de usuario de la cámara [118], e implementar toda
la lógica de inicialización, configuración, captura de imagen y finaliza-
ción. Esto supuso varias jornadas, puesto que la documentación de la
cámara era compleja y extensa.
Existen dos grandes funciones en la librería de programación del dis-

positivo de imagen para la captura de imágenes a partir del flujo de
imágenes. Éstas son : is_CaptureVideo (..) y is_FreezeVideo (..). La
principal diferencia entre ambas funciones es que la primera vuelca de
forma contínua a la tasa determinada de fps configurada imágenes en
el buffer de la cámara, mientras que la segunda rellena el buffer de la
cámara cada vez que es llamada. Al principio se optó por utilizar la
primera de las funciones, puesto que podíamos capturar a una tasa de
hasta 40 fps.
Pero surgió un problema; y éste era que en el tiempo en que se había
extraído una imagen del buffer, y se había procesado para la obtención
de los parámetros extrínsecos, la siguiente imagen extraída del buffer
no era la que en el instante de tiempo inmediatamente anterior se ha-
bía capturado, sino la siguiente a la procesada que había en el buffer.
Esto daba lugar a situaciones en las que era posible que el tablero se
hubiera desplazado, y no lo detectásemos hasta pasados unos segundos.
La documentación del manual de la cámara indica que el buffer se va
actualizando continuamente; situación que se ha comprobado que no es
del todo cierta.
6.2. Objeto de referencia plano 113
6.2. Objeto de referencia plano
En esta propuesta se intenta implementar una nueva versión del código,

de forma que ya no se considera ni la geometría del objeto de referencia ni
el modelo de la cámara. Un propuesta similar a la presente se encuentra en
[39] y [3]. En este caso, se considera al objeto de interés plano, y el esquema
de control visual sigue siendo el denominado control visual basado en posición
(PBVS Position Based Visual Servo). El código es completamente distinto al
anterior, aunque la idea que subyace es la misma: se trata de extraer a partir
de la información visual la rotación y traslación del objeto respecto del sistema
de coordenadas de la cámara.
Para la localización del objeto se ha implementado una búsqueda de carac-

terísticas, o corners, en una región del espacio delimitada por una máscara, y
para el seguimiento se ha hecho uso de las funciones que proporciona OpenCV
para el tracking de puntos: algoritmo de Lucas-Kanade, o flujo óptico. Dentro
de esta misma sección se plantea también otro método para la localización y
seguimiento del objeto de interés: algoritmos de SURF6.2 y SIFT6.3 . Se propor-
cionará una base teórica de ambos métodos y los resultados experimentales
obtenidos.
Ya no se calculan los parámetros extrínsecos del sistema tal cual. En este

modelo no existen plano de la imagen, y plano del objeto. Tan solo existe el
plano de la imagen, y el conjunto de puntos extraídos del mismo es lo que
se intenta seguir en una secuencia de imágenes. Se plantea una relación de
transformación proyectiva, en la que se toma la primera imagen del objeto
(imagen de referencia) y se calcula en cada toma la matriz de homografía
con la nueva imagen del objeto capturada, de forma que en cada instante de
tiempo tenemos una matriz H, cuyos coeficientes transformarían la posición
actual del objeto a la posición de referencia.
Una vez calculada la matriz de homografía entre cada par de imágenes

(referencia y actual), se plantean dos técnicas para la extracción de la rota-
ción y traslación: mediante descomposición analítica y numérica. En [30] se
propone otro tipo de descomposición, se refiere al lector para más información
a consultar dicho artículo. En el presente proyecto se aportan en el Apéndice
A las implementaciones de ambos métodos.
La obtención de la matriz de rotación y el vector de traslación respecto de

6.2
SURF: Speeded Up Robust Features.
6.3
Scale-Invariant Feature Transform.
la primera propuesta es también distinta, e incluye además un problema: el

vector de traslación no viene dado en unidades métricas como en la primera
propuesta, sino que viene escalado y determinado por un factor α descono-
cido. En la literatura existen varios artículos en los que no es necesario la
determinación de dicho factor; mientras que en otras propuestas se determina
que es sencillo de extraer. Más adelante, en la sección 6.2.2.5 se expondrán
todos estos aspectos. Así pues, y como visión general, se puede proporcionar
un algoritmo genérico que englobe a toda la lógica relacionada con la consi-
deración plana del objeto. Este algoritmo viene dado en Algoritmo 6.3.
En la bibliografía se pueden encontrar muchos títulos en los cuales se usa

la matriz de homografía para el control visual basado en imagen (IBVS). Éstos
son, entre otros: [27][62][63][64] y [66]. Existen otras propuestas distintas tam-
bién basadas en IBVS, como la presentada en [17], en la cual, usan momentos
de primer orden de imágenes esféricas para el control visual.
Otra alternativa no considerada en la implementación, es, tal y como se

detalla en la Sección 4.2., en lugar de representar al objeto de interés como un
conjunto de puntos, representarlo como una figura geométrica, un rectángulo,
por ejemplo. En [27] se muestra esta técnica para el cálculo de la matriz de
homografía entre vistas, y un ejemplo de esta representación es la mostrada
en la Figura 6.16.
Figura 6.16: Representación del objeto mediante formas geométricas básicas

para el cálculo de la homografía.
A continuación se expone de forma teórica en qué consiste la matriz de

homografía utilizada en esta segunda propuesta, y posteriormente se detallan
el conjunto de métodos implementados.
Algorithm 6.3 Algoritmo de extracción de información visual para Control

Visual Basado en Imagen. Propuesta 1.
Inicio Control_IBVS
ReservaEstructurasMemoria(...)
imagenReferencia := CapturaImagenInicial(tablero_ajedrez)
puntosObjetoReferencia := extraePuntosObjeto(imagenReferencia)
mientras (cierto):
// El objeto se mueve en la escena
imagenActual := CapturaImagen(camara)
// Se localizan los puntos del objeto en cada imagen
puntosObjetoActual := extraePuntosObjeto(imagenActual)
matrizHomografia :=
calculaHomografia(puntosObjetoReferencia,
puntosObjetoActual)
DescomposicionHomografia(matrizHomografia)
// Cualquier operación con la matriz de homografia
TransformacionPerspectiva(imagenActual,matrizHomografia,...)
fin mientras
Fin Algoritmo
6.2.1. Matriz de homografía
6.2.1.1. Definición
Sea P ∗ el vector de 3x1 que contiene a las coordenadas homogéneas de un

punto en la imagen de referencia (Figura 6.17), expresado en un sistema {C ∗ },
y P, expresado en {C}, el vector que contiene las coordenadas homogéneas de
un punto en la imagen actual. Se verifica que:
P =C TC ∗ P ∗ = RP ∗ +t
Si llamamos d∗ a la distancia entre el plano de la cámara y el plano de
la imagen en la imagen de referencia, puede verificarse que : nT P ∗ = d∗ . Es
T ∗
decir, n d∗P = 1. Se tiene pues la siguiente relación:
nT P ∗ nT ∗
P = RP ∗ + t = (R + t )P
d∗ d∗
Figura 6.17: Frame actual y deseado del sistema.
Si expresamos las coordenadas de los puntos P ∗ y P como coordenadas

proyectivas dividiendo por su respectiva tercera coordenada, se tiene que:
P P∗
m= , m∗ = ∗
Z Z
donde m∗ = (u∗ , v ∗ , 1) es el vector que contiene a las coordenadas proyec-

tivas normalizadas de un punto visto desde la posición de referencia respecto
del sistema de coordenadas de la cámara, y m = (u, v, 1) es el vector que
contiene las coordenadas proyectivas normalizadas de la posición actual del
mismo punto.
Se verifica que:
nT
mZ = (R + t )m∗ Z ∗
d∗
nT Z
αH m = (R + t )m∗ , siendo αH = ∗
d∗ Z
En conclusión, podemos escribir:
αH m = Hm∗
donde H es la matriz de homografía en el espacio Euclídeo. Como se puede

observar, se establece una relación multiplicativa entre los puntos tridimen-
sionales (expresados en coordenadas proyectivas) de un frame con el deseado.
En el espacio de la imagen, también se puede establecer una relación similar

entre los puntos p y p∗ , de forma:
αG p = Gp∗
Esta matriz G es la que se puede estimar a partir de la correspondencia
entre un conjunto de puntos para una secuencia de imágenes. Una vez ob-
tenida, la matriz H puede ser deducida teniendo en cuenta que p = Km y
p∗ = Km∗ , siendo K la matriz de parámetros intrínsecos de la cámara, de
forma que:
αG Km = GKm∗ ⇒ αG m = K−1 GKm∗
por lo que la matriz H se define como:
H = K−1 GK
En resumen, a partir de la matriz G y conociendo K se puede obtener la

matriz H. A partir de ésta, se podrá realizar una descomposición para obtener
los elementos R, t y n. A éste último paso se le denomina reconstrucción
euclídea a partir de la matriz de homografía H.
6.2.1.2. Descomposición de la matriz de homografía en valores sin-

gulares
Propuesto por Faugeras, en [123] se detalla el método seguido para la

implementación en el presente proyecto. Si se realiza una descomposición de
valores singulares de la matriz de homografía:
H = U Λ VT
se obtienen las matrices ortogonales U y V y la matriz diagonal Λ, la
cual contiene los valores singulares de la matriz H. Se puede considerar esta
matriz diagonal como una matriz de homografía tal cual, y aplicar la relación
siguiente:
Λ = RΛ + tΛ nΛT
El cálculo anterior es simple cuando la matriz a ser descompuesta es diago-
nal. Realizando cálculos sobre la anterior ecuación y planteando un sistema de
ecuaciones lineal (8 grados de libertad), se pueden obtener hasta 8 soluciones
diferentes para la tripleta {RΛ , tΛ , nΛ }.
Así pues, asumiendo que la descomposición de la matriz diagonal se ha

calculado, para calcular la descomposición final de los elementos, es necesario
recurrir a las siguientes expresiones:
R = URΛ VT
t = U tΛ
n = V nΛ
Para garantizar que la solución seleccionada es la correcta, es necesario

aplicar un conjunto de restricciones (mostradas a continuación), que son ge-
néricas a cualquier técnica de descomposición.
Restricciones
Una de ellas consiste en que en ambas imágenes, el origen de cada sis-

tema de coordenadas debe estar en el mismo lado del objeto plano (Figura
6.18). Esto genera una restricción tal que:
1 + nT R T t > 0
Figura 6.18: Representación gráfica de la primera restricción.
Tras aplicar esta restricción, de ocho posibles soluciones se ha pasado a un

total de cuatro. La segunda restricción consiste en que para todos los puntos de
referencia posibles, todos deben estar situados enfrente de la cámara (Figura
6.19). Expresado en la actual notación:
mT (R n) > 0
Donde m son las coordenadas de los puntos de referencia. Tras esta segunda
restricción, se consigue reducir el número de soluciones posibles a dos.
Figura 6.19: Representación gráfica de la segunda restricción.

6.2.1.3. Descomposición analítica
En [123] se proponen dos métodos para este apartado: calculando en primer

lugar el vector normal, o calculando en primer lugar el vector de traslación.
Dado que es el primero de ellos del cual se ha generado una implementación
compatible para OpenCV, es el que se describe a continuación. Se refiere al
lector a consultar [123] para más información.
Se pueden obtener diferentes formas para las expresiones analíticas intro-

duciendo una matriz simétrica, S, obtenida a partir de la matriz de homografía
H como:
 
s11 s12 s13
T
S = H H − I =  s21 s22 s23 


s31 s32 s33
Se representa como Msij , i, i = 1.,3, las expresiones Menores de la matriz
−S. Por ejemplo:
s22 s23
Ms11 = − | |= s223 − s22 s33 ≥ 0
s23 s33
En general, existen tres alternativas diferentes para obtener las expresiones
de los vectores normales ne (y a partir de éste te y Re ) a partir de la des-
composición de la matriz de homografía de los componentes de S. Así pues,
se escribirá como:
ne0 (sii )
ne (sii ) = ; e = {a, b}, i = {1, 2, 3}
k ne0 (sii ) k
Donde ne (sii ) significa ne desarrollado usando sii . Así, los tres casos posi-
bles son los siguientes:
   
s√
11 s√
11
0 0
na (s11 ) =  s12 + √

Ms33 
; nb (s11 ) =  s12 + √

Ms33 
; (6.1)
s13 + 23 Ms22 s13 + 23 Ms22
 √   √ 
s12 + Ms33 s12 − Ms33
na0 (s22 ) =  s22√ ; nb0 (s22 ) =  s22√ (6.2)
   

s23 − 13 Ms11 s23 + 13 Ms11
 √   √ 
s13 + 12
√ Ms22 s13 − 12
√ Ms22
na0 (s33 ) =  s23 + Ms11  ; nb0 (s33 ) =  s23 − Ms11  (6.3)
   
s33 s33
donde ij = sign(Msij ).
Todas estas fórmulas devuelven el mismo resultado. Sin embargo, no todas

ellas pueden ser aplicadas en cada caso, al igual que el cálculo de ne (sii ), el
cual implica una división por sii . Esto significa que dicha fórmula no puede ser
aplicada cuando la división es entre cero (esto ocurre cuando la componente
i-ésima de n es nula).
El procedimiento correcto consiste en calcular na y nb usando la alternati-

va de entre las tres correspondencias establecidas con el mayor valor absoluto
para sii . Ésta será la opción mejor condicionada. El único caso a tener en cuan-
ta es cuando solamente tenemos rotación pura; justamente cuando la matriz
H es la matriz de rotación. En este caso, todos los componentes de la matriz
S serán nulos. Éste será pues el caso base, en el que no es necesario aplicar
ninguna fórmula.
Cabe destacar que las cuatro soluciones obtenidas con estas fórmulas son
todas las mismas (esto es, {na , −na , nb , −nb }), pero no siempre son devueltas
en el mismo orden; esto significa que, por ejemplo, na (s11 ) se pudiera co-
rresponder con cualquiera de las 4 soluciones anteriores, incluso en lugar de
corresponderse con na (s11 ).
Las expresiones para el vector de traslación en el marco de referencia,

t∗e= ReT te , pueden obtenerse a partir de las expresiones para los vectores
normales:
   
s√ s√
k ne0 (s11 ) k 11
k t e k2 11
t∗e (s11 ) =  s12 ∓ √ −
Ms33  s ± Ms33 

12 √
2s11 2 k ne0 (s11 ) k
 
s13 ∓ 23 Ms22 s13 ± 23 Ms22
 √   √ 
s12 ∓ Ms33 s12 ± Ms33
k ne0 (s22 ) k k te k 2
t∗e (s22 ) = s22√ − s22√
  
2s22 0
2 k ne (s22 ) k
  
s23 ∓ 13 Ms11 s23 ± 13 Ms11
 √   √ 
s13 ∓ 12 Ms s ± Ms
k ne0 (s33 ) k √ 22
k te k 2 13 12
√ 22
t∗e (s33 ) =  s23 ∓ Ms11  −  s23 ± Ms11 
  
2s33 0
2 k ne (s33 ) k
s33 s33
Para e = a el mayor operador en los simbolos ±, es decir, ∓, debe ser
elegido, y para e = b, seleccionar el operador menor. EL vector t∗e puede
también en una forma más compacta de na y nb :
k te k
t∗a (sii ) = [sii ρnb (sii )− k te k na (sii )] (6.4)
2
k te k
t∗b (sii ) = [sii ρna (sii )− k te k nb (sii )] (6.5)
2
siendo:
sii = sign(sii )
ρ2 = 2 + trace(S) + ν
k te k2 = 2 + trace(S) − ν
Donde ν puede ser obtenida a partir de:
q q
ν= 2[(1 + trace(S))2 + 1 − trace(S2 )] = 2 1 + trace(S) − Ms11 − Ms22 − Ms33
La expresión para la matriz de rotación quedaría tal que:

2
Re = H(I − t∗e neT )
ν
y el vector de traslación:
te = Re t∗e
Éste es el método implementado en la clase HomographyDecomposition.hpp,

junto con el método de descomposición de Faugeras explicado en el apartado
anterior. Se refiere al lector a consultar la referencia [30] de la bibliografía para
más información.
6.2.1.4. Cálculo de la matriz de homografía
Una vez determinados los conjuntos de puntos que representan al objeto

entre la imagen inicial y la actual, el siguiente paso consiste en calcular la
matriz de homografía del sistema. En la implementación se han usado dos
métodos para la obtención de dicha matriz; éstos son el método RANSAC y
el método LMEDS. En OpenCV existe una función para esta tarea, denomi-
nada cvFindHomography(). Una descripción más detallada de esta función se
presenta a continuación:
void cvFindHomography(
const CvMat* srcPoints,
const CvMat* dstPoints,
CvMat* H,
int method=0,
double ransacReprojThreshold=0,
CvMat* status=NULL)
Descripción del prototipo de la función:
srcPoints,dstPoints :
Son, respectivamente, el conjunto de puntos del objeto de la imagen
inicial y el conjunto de puntos del objeto de la imagen actual. Cabe
resaltar que en los experimentos se demostró que los puntos deben estar
en orden; es decir, que la posición i-ésima del array srcPoints contenga
al punto i-ésimo, siendo el mismo encontrado en la posición i-ésima del
array dstPoints.
H:
Matriz de homografía de orden 3 devuelta por el método.
method :
0 : Método común usando todos los puntos. Sin ningún tipo de

optimización.
CV_RANSAC : Cálculo de la matriz de homografía usando el mé-
todo RANSAC.
CV_LMEDS : Cálculo de la matriz de homografía usando el mé-
todo LMedS.
ransacReprojThreshold :
Solo válido si el método usado es RANSAC. Indica el máximo error de
reproyección permitido para considerar a un punto como válido.
status :
No usado en esta implementación.
A continuación se exponen de forma breve las diferencias entre los métodos

de RANSAC y LMeds.
Método RANSAC :
El método RANSAC (RANdom SAmple Consensus) es un método de

emparejamiento robusto que da como resultado la solución más votada
de entre unas cuantas, calculadas a partir de conjuntos mínimos obte-
nidos aleatoriamente. Para calcular una homografía en tres dimensiones
se necesitan un mínimo de cuatro emparejamientos. La idea del método
RANSAC consiste en seleccionar un número de subconjuntos de cuatro
emparejamientos elegidos aleatoriamente dentro del total, que garanti-
ce que, con una probabilidad superior al 99 %, al menos uno de dichos
subconjuntos contendrá sus cuatro emparejamientos correctos, es decir,
que ninguno de ellos es un falso emparejamiento.
Para cada uno de los subconjuntos formados se calcula la matriz de ho-

mografía. Esta matriz se valora mediante un sistema de votaciones. Para
ello, se fija un umbral que separe los emparejamientos buenos de los ma-
los para esta homografía. Un emparejamiento se considerará bueno si y
sólo si la homografía lleva una característica a la otra con un error menor
que el umbral considerado. Se contabiliza el número de emparejamientos
buenos (votos favorables), quedándonos al final con la homografía que
más votos haya tenido.
Una vez que se ha elegido la homografía más votada como solución, se

consideran emparejamientos buenos aquellos que hayan votado a dicha
solución, mientras que los falsos emparejamientos serán los que no la ha-
yan votado. Para reducir el coste computacional, en el momento en que
una homografía recibe más del 95 % de los votos, esta se considera solu-
ción definitiva. De esta forma en conjuntos con un porcentaje pequeño
de falsos emparejamientos el cálculo de la solución es casi inmediato.
Método LMedS :
LMedS proviene de las palabras inglesas Least Median of Squares (míni-

mo error de la mediana). La idea de este método probabilístico es similar
a la que emplea RANSAC: se seleccionan aleatoriamente un número de
subconjuntos y se calcula la matriz de homografía para cada uno de ellos.
En este caso, en lugar de realizar votaciones, lo que se hace es calcular

los residuos que genera el conjunto total de emparejamientos para cada
homografía. De todas las soluciones obtenidas el método escoge aquella
que minimice la mediana de los cuadrados de los residuos. La ventaja
de este método frente a RANSAC es que no necesita fijar umbrales.
Sin embargo, es más costoso computacionalmente. Partiendo de la hipó-

tesis de que los datos se ajustan a una distribución normal, para eliminar
los falsos emparejamientos el método LMedS calcula un umbral σ en fun-
ción del valor de la mínima mediana obtenida, y elimina todos aquellos
emparejamientos cuyo residuo sea superior a dos veces el cuadrado de
dicho valor:
ri2 ≤ (2 · σ̂ 2 )
Durante los experimentos el método de RANSAC fue el más robusto a falsos

emparejamientos, en el sentido de que tiene probabilidades más altas de gene-
rar soluciones exactas que el emparejador básico (si no se establece ninguna
condición en la función cvFindHomography(..)) o el emparejamiento robusto
utilizando LMedS.
6.2.2. GoodFeaturesToTrack() y flujo óptico para el se-

guimiento del objeto de referencia
Como se comentó con anterioridad, el algoritmo correspondiente a esta

segunda alternativa para el control visual es completamente distinto. En este
caso, el objeto de referencia puede ser cualquier objeto plano, salvo con la con-
dición de que debe albergar gran cantidad de puntos característicos, o corners.
Se aplica un método inicial de detección de características, y posteriormente
mediante el algoritmo adaptativo de Lucas-Kanade de flujo óptico se intentan
seguir los puntos detectados en la imagen inicial en la secuencia de imágenes
posteriores.
Una vez localizados al menos 4 puntos del mismo objeto entre dos imáge-
nes (el original, o de referencia, y el actual), se procede a calcular la matriz de
homografía entre ambos conjuntos de puntos; si los puntos “casan”, la matriz
de homografía tendrá sentido. Si de lo contrario, los 4 puntos no albergan
ningún tipo de relación geométrica, la matriz resultante calculada no tendrá
sentido. En este aspecto, se han realizado varias pruebas en el laboratorio.
Posteriormente, si la matriz de homografía resultante es correcta, se pro-

cede a la descomposición de la misma para obtener la matriz de rotación y
el vector de traslación, los cuales indican cual es el movimiento inverso que
debería hacer la cámara para que los puntos fueran vistos en las posiciones
dadas en la imagen de referencia. Así pues, el algoritmo detallado que recoge
todos los pasos seguidos en esta implementación, es el propuesto en Algoritmo
6.4.
Este modelo es relativamente más complejo que el anterior, puesto que se

necesita de más funciones para localizar y seguir al objeto de referencia. A
continuación se muestran en profundidad los detalles de la implementación.
6.2.2.1. Localización del objeto de referencia
Dado que en este algoritmo no se dispone de una función de detección

automática del objeto de referencia, esto supone tanto una ventaja como una
desventaja. La ventaja consiste en que ahora se puede utilizar cualquier tipo
de objeto, sea plano o no, para la localización de puntos dentro de su contorno
y su posterior seguimiento. El problema, obvio, es que hay que implementar
Algorithm 6.4 Algoritmo de extracción de información visual para Control

Visual Basado en Imagen. Propuesta 2.
Inicio Control_PBVS_Propuesta_II
si esPrimeraIteracion:
imagenReferencia := CapturaImagenInicial(tablero_ajedrez)
puntosObjetoReferencia :=
extraePuntosObjeto(imagenReferencia)
ReservaEstructurasMemoria(puntosObjetoReferencia,..)
bucle:
si no esPrimeraIteracion:
imagenActual := CapturaImagen(camara)
[puntosObjetoActual,puntosPosicionEstimada] :=
SeguimientoFlujoOpticoPiramidal(imagenPrevia,
imagenActual,..)
matrizHomografia :=
calculaHomografia(puntosObjetoReferencia,
puntosObjetoActual)
DescomposicionHomografia(matrizHomografia)
// Cualquier operación con la matriz de homografia
TransformacionPerspectiva(imagenActual,
matrizHomografia,...)
fin si
Intercambia(puntosObjetoActual,
puntosPosicionEstimada)
Intercambia(imagenActual,
imagenPrevia)
fin bucle
Fin Algoritmo
dicho método.
Consultando [120] y [111], una de las alternativas con más éxito consiste
en utilizar la función de OpenCV denominada cvGoodFeaturesToTrack(), la
cual devuelve un conjunto de características de una escena, que son buenas
candidatas para el seguimiento en una secuencia de imágenes.
Tras realizar varias pruebas iniciales, finalmente se optó por el uso de la

función cvGoodFeaturesToTrack(), la cual se detalla a continuación:
void cvGoodFeaturesToTrack(
const CvArr* image,
CvArr* eigImage,
CvArr* tempImage,
int* corner_count,
double quality_level,
double min_distance,
const CvArr* mask = NULL,
int block_size = 3,
int use_harris = 0,
double k = 0.4 );
image :
Imagen de entrada de la cual se extraen los puntos característicos, o
corners.
eigImage,tempImage :
Son variables necesarias para los cálculos de la propia función. En un
principio, se pensó que los puntos devueltos por esta función venían
indexados en función de su correspondiente autovalor, devuelto en eigI-
mage. Pero se corroboró que al finalizar la función la variable eigImage
no contenía ningún tipo de información, puesto que al salir de la función
la memoria reservada para esta variable es liberada.
corners :
Estructura de tipo array en OpenCV, la cual contiene las coordenadas
de los puntos característicos obtenidos en la imagen. Estas coordenadas
son respecto al plano de la imagen.
corner count :
Puntero a entero que indica el número de corners encontrados en la
imagen. Este parámetro puede ser tanto de entrada como de salida, en
el sentido de que si se inicializa a algún valor, la función devolverá tan
solo los n mejores corners , donde n es el valor de inicialización de dicha
varaible. En caso contrario, busca tantos corners como posiciones tenga
el array corners de entrada.
quality_level :
Indica el valor mínimo aceptable para un autovalor para que un de-
terminado punto sea aceptado como corner. El valor actual para este
parámetro es el producto entre quality_level y el menor de los mayores
autovalores encontrados en la imagen. Así, este valor no debe exceder
de 1. Un valor típico suele estar comprendido entre 0.10 y 0.01.
min_distance :
Se indica la distancia mínima entre dos puntos. Expresada en píxeles.
Dependería pues de cada tipo de objeto.
mask :
Se pueden buscar los puntos característicos en toda la región de la ima-
gen, o bien en un área determinada. En esta propuesta se ha diseñado
una función para la selección manual del objeto (Figura 6.20 y Figura
6.21); mediante 4 puntos, se selecciona la región de la imagen donde está
el objeto, y donde se desea buscar las características que describen al
mismo. Ésta función se encuentra definida en el conjunto de clases imple-
mentadas, más concretamente en el fichero seleccion.hpp. Una máscara
no es más que una región lógica del espacio; aquellos puntos o coorde-
nadas que estén a un valor positivo serán considerados, mientras que las
que tengan un valor nulo, no lo serán.
block_size :
Región del espacio alrededor de cada píxel que es considerada para el
cálculo de las derivadas de segundo orden. Normalmente suele tener un
valor comprendido entre 3 y 5 píxeles alrededor del punto.
use_harris,k :
Si use_harris es distinto de cero, entonces para la detección de los puntos
se usa la técnica de Harris, en lugar de la de Shi y Tomasi. El valor k
es el coeficiente de Harris (ver Sección 4.4.1), cuyo valor por defecto en
este caso suele ser de 0.4.
La implementación de esta función sigue la definición de Shi y Tomasi (Sec-

ción 4.5.2). Básicamente, en esta alternativa se calculan hasta las derivadas
segundas (usando operadores de Sobel) que son necesarias para la obtención
de los autovalores de la matriz de autocorrelación alrededor de una pequeña
región alrededor de cada punto.
Figura 6.20: Selección manual del objeto.
Figura 6.21: Obtención de la máscara de selección del objeto.
Donde los cambios sean más bruscos, será una buena zona en la que situar
un punto característico. En contraposición con el criterio de Harris (Sección
4.4.1), Shi y Tomasi propusieron que era mejor obtener el menor de los autova-
lores que aplicar un cierto umbral. En general, se obtienen mejores resultados
con la propuesta de Shi y Tomasi que con el método de Harris (por las consi-
deraciones expuestas en [120]).
En la implementación de la clase CSensorCamara2.hpp, la cual alberga la

propuesta presentada en esta sección, la función cvGoodFeaturesToTrack() se
aplica en dos ocasiones. La primera de ellas es para ajustar el número máximo
de puntos que se considerarán para representar al objeto. Así, se suele ini-
cializar el array para contener dichos puntos a un valor de 150, para después
ajustarlo a las necesidades reales de cálculo. Así se evita la reserva excesiva
de memoria.
En segundo lugar, se aplica esta función para la extracción de puntos que

serán considerados en las siguientes imágenes. Una primera aproximación en
la estimación del valor de los coeficientes de dicha función es la presentada en
el código propuesto en el Apéndice A. Una vez que se ha realizado una llama-
da a esta función, el array corners contendrá las coordenadas de los puntos
del objeto. Al igual que en la primera propuesta de implementación, aplica-
mos la función cvFindCornerSubPix() para obtener una mejor precisión de la
localización de los puntos encontrados.
Tras localizar el objeto de interés en la escena, y ser representado median-

te el conjunto de puntos devueltos por la función cvGoodFeaturesToTrack(),
el siguiente paso es precisamente realizar el “tracking” de dichos puntos, es
decir, el seguimiento de los mismos entre diferentes imágenes de la escena que
se comenta en el siguiente apartado.
Como último detalle de esta sección es que en la implementación de esta

propuesta se mantienen la estructuras de memoria para la matriz intrínseca y
los parámetros de distorsión. Aunque no son necesarios en este modelo, bien
si lo pueden ser para la corrección geométrica de la imagen. En la Figura 6.22
se puede observar cómo la linea superior del tablero se observa curvada en la
imagen; esto es debido a defectos en la lente, que bien pueden ser corregidos
en el código haciendo uso de la función cvUndistort2(), la cual corrige geomé-
tricamente la imagen haciendo uso de la matriz de calibración interna y de los
parámetros de distorsión.
Tras varias pruebas iniciales se comprobó que si era necesario una correc-
ción geométrica de la imagen se perdían de media unos 3 fps; por lo que en la
implementación ésta opción se ha definido de forma opcional, si fuera necesa-
ria.
Figura 6.22: Detalle de la distorsión de la lente.
6.2.2.2. Seguimiento de los puntos del objeto de referencia
En una primera aproximación se pensó que la función cvGoodFeatures-

ToTrack() devolvía los puntos en el mismo orden, entre una secuencia de
imágenes consecutivas. Posteriormente, cuando se comprobó que no era de tal
forma, se pensó en indexar algún array en el que se relacionara el punto con
su autovalor, de forma que según el segundo parámetro se pudiera localizar
al mismo punto entre imágenes consecutivas. Pero al intentar acceder a la
estructura de eigImage (es la que contiene los autovalores para los puntos de-
vueltos) se comprobó también que no era posible, puesto que dicha estructura
de memoria era liberada justo antes de terminar la función.
Una de las maneras en la que se pensó que los puntos devueltos no se

correspondían entre escenas era que la matriz de homografía resultante no
tenía sentido. Se verifica que entre dos imágenes distintas, si no ha habido
ningún tipo de rotación ni de traslación, la matriz que lleva del mismo punto
expresado en el sistema de referencia al mismo sistema, esto es, la matriz de
homografía, es precisamente la matriz identidad I. Los resultados observados
no se correspondían con esta afirmación, por lo que se determinó que con la
función de localización de puntos no era suficiente.
Consultando de nuevo la bilbiografia, se decidió por realizar pruebas con

la función de OpenCV cvCalcOpticalFlowPyrLK(). Esta función basa su im-

plementación en tres suposiciones (Figura 6.23):
Constancia del brillo: Se asume que el brillo de un píxel entre una imagen
y la siguiente no cambia bruscamente (se considera constante) .
Persistencia temporal: El movimiento del punto característico cambia

relativamente poco de una imagen a la siguiente.
Coherencia espacial: Los puntos vecinos al punto característico, perte-

necientes al mismo plano, tienen el mismo movimiento y proyecciones
similares en la secuencia de imágenes consecutivas.
Figura 6.23: Restricciones de un punto en Lucas Kanade.
El algoritmo detallado a continuación realiza un seguimiento del punto en una

secuencia de imágenes, basándose en las anteriores asunciones y en la defini-
ción del flujo óptico (Sección 4.3), incluyendo además un proceso de búsqueda
piramidal (Figura 6.24 y 6.25).
Esta pirámide se corresponde a una secuencia de imágenes resultado de una

reducción de escala de la imagen inicial por múltiplos de dos. En la Figura
6.24, I0 será la imagen inicial y las imágenes I1 , I2 e I3 serán las siguientes
Figura 6.24: Representación piramidal de una imagen.
imágenes de la pirámide. Posteriormente se realiza el cálculo del flujo óptico

tras colocar el punto buscando en la posición en la que se encontró en la
iteración anterior. Este paso del algoritmo solo funciona si el flujo óptico de
este punto es pequeño, cosa que se puede asegurar gracias a la utilización de
la representación piramidal.
Así pues, queda detallar la función cvCalcOpticalFlowPyrLK():
void cvCalcOpticalFlowPyrLK(
const CvArr* imgA,
const CvArr* imgB,
CvArr* pyrA,
CvArr* pyrB,
CvPoint2D32f* featuresA,
CvPoint2D32f* featuresB,
int count,
CvSize winSize,
int level,
char* status,
float* track_error,
CvTermCriteria criteria,
int flags );
imgA,imgB :
imgA se corresponde con la imagen previa del objeto, e imgB se corres-
ponde con la actual. Se trata de indicar las dos imágenes en las que se
desean buscar los puntos característicos.
pyrA,pyrB :
Estructuras de memoria para contener las distintas capas de búsqueda
de la pirámide de búsqueda.
featuresA,featuresB :
El primer array contiene los puntos que se desean seguir, los cuales
son analizados para extraer la característica de su movimiento. El array
featuresB contendrá la localización estimada de los puntos calculados a
partir del movimiento de los puntos originales.
count :
Número de puntos en el array featuresA.
winSize :
Estructura para indicar el tamaño en OpenCV de la ventana de bús-
queda alrededor del píxel que contiene la característica. En el presente
trabajo se ha propuesto una ventana de tamaño 5 píxeles.
level :
Entero para indicar la profundidad de la búsqueda piramidal. Si se esta-
blece a 0, se realiza el proceso de búsqueda en un solo nivel (no habría
búsqueda piramidal). En nuestro caso, se establece a un valor de 3, por-
que es el que mejores resultados ha dado hasta el momento.
status :
De longitud count; una vez terminada la función, si la posición i-ésima
contiene un 1, significa que el punto i-ésimo del array featuresA ha sido
localizado. En caso contrario, el valor en esta posición será de 0.
track_error :
Si está activo, es un array de números en formato real, que indica la
diferencia entre la localización del punto en la primera toma y la loca-
lización estimada del punto en la imagen actual. Es utilizado en una
técnica de optimización propuesta en el siguiente apartado.
criteria :
Se establecen las condiciones de parada del algoritmo. En este caso, hasta
un máximo de 10 iteraciones o una precisión inferior al 10 %. Aunque aún
es necesario la realización de varias pruebas para determinar su posible
valor definitivo.
flags : Las usadas en esta implementación son (en conjunción con el operador
booleano &):
CV_LKFLOW_PYR_A_READY : Indica que la pirámide de bús-

queda para la imagen de referencia es calculada antes de la llamada
y almacenada en pyrA.
CV_LKFLOW_INITIAL_GUESSES : Indica que el array featu-
resB contiene una estimación inicial de la localización de los puntos
antes de realizar la llamada a la función.
Al igual que tras la llamada de cvGoodFeaturesToTrack(), tras la ejecución de

esta función se realiza también un proceso de refinamiento en la precisión de
las coordenadas con la función cvFindCornerSubPix().
Figura 6.25: Búsqueda piramidal con flujo óptico.
Al tiempo que se presenta este proyecto, aún se están realizando diferen-

tes configuraciones en el laboratorio para obtener de forma experimental los
parámetros que optimicen el funcionamiento de esta función. Se prueba con
diversos objetos de interés y se visualizan los resultados obtenidos.
Un ejemplo de ello es el mostrado en la Figura 6.26, en la que se puede

observar la estimación de la localización de los puntos interiores al tablero
de ajedrez con una tasa de aproximadamente 15 veces por segundo (15 fps,
en total), incluyendo la tarea de descomposición de la matriz de homografía H.
Figura 6.26: Estimación de los puntos usando la función cvCalcOptical-

FlowPyrLK().
Optimización del método propuesto
El principal problema del método anterior consiste en que cuando algún

objeto se cruza entre la cámara y el objeto de referencia, los puntos caracte-
rísticos del mismo se dispersan (Figura 6.27). La mismo sucede si se mueve el
objeto con cierta rapidez.
Figura 6.27: Error en la estimación de los puntos del objeto.
Esto conlleva a deshechar todos los puntos que no se quedan sobre el ob-
jeto, con lo que es posible que a medida que vayan avanzando la secuencia de
imágenes se vayan descartando puntos hasta sobrepasar el mínimo necesario
para calcular la matriz de homografía (4 puntos).
Así, se plantea la necesidad de añadir algún mecanismo para evitar este

tipo se situaciones no deseables. Existe una propuesta, aún no implementada,
que consiste en aplicar técnicas de template matching cuando el método ante-
rior falla para localizar de nuevo el objeto.
La idea se expone en los siguientes pasos:
Paso 1 :
Para la localización inicial del objeto se utiliza la función cvGoodFeatu-
resToTrack(), con selección manual para la máscara.
Paso 2 :
Para el seguimiento se hace uso de la función cvCalcOpticalFlowPyrLK(),
calculando en cada iteración la media del desplazamiento de los píxeles,
obtenido a partir de track_error. Se calcula el mínimo y máximo valor
en las coordenadas tanto del eje X como del eje Y. Éstas cuatro coorde-
nadas determinarán una región del espacio en la que se está desplazando
el objeto.
Paso 3 :
Si en algún momento los puntos estimados no verifican que se desplazan
en media igual que el conjunto (en principio el objeto no se deforma geo-
métricamente), estos son eliminados, para garantizar que no pertenecen
al objeto. Este paso es aún matizable, en el sentido de que otra restric-
ción para usar la media del conjunto es que no haya alguna deformación
por efecto de la perspectiva.
Paso 4 :
Si se alcanza el mínimo de puntos necesarios para calcular de forma ópti-
ma la matriz de homografía (según lo indicado anteriormente, al menos
4), se busca de nuevo al objeto en la región delimitada por los puntos del
paso 2. La forma de búsqueda en este caso es por fuerza bruta siguiendo
la técnica de template matching definida en 4.5.2. En este caso, el patrón
a buscar se corresponde con la sección de la imagen delimitada por los
puntos del paso 2, y la imagen donde buscar al objeto es la imagen actual.
El valor devuelto se corresponderá con el centro de un rectángulo que

contendrá al objeto y a algunos puntos externos. Se extraen las caracte-
rísticas de la región devuelta, y se vuelve al paso 2. Los puntos externos
devueltos en este paso se irán descartando sucesivamente tras varias
iteraciones del paso 2.
Figura 6.28: Ejemplo de la técnica template matching. Se desplaza la plantilla

de referencia hasta que el emparejamiento sea óptimo.
6.2.2.3. Ejemplo de aplicación. Reconstrucción proyectiva
Un ejemplo muy interesante de la obtención de la matriz de homografía es

la reconstrucción proyectiva. Es decir, si tenemos el conjunto de puntos del ob-
jeto en la imagen de referencia, el conjunto de puntos del objeto en la imagen
actual, y la matriz de transformación (en este caso la matriz de homografía)
que lleva puntos de un sistema al otro, tendremos una reconstrucción parcial
de la escena original, siendo precisamente reconstruido el objeto de referencia.
En la Figura 6.29 se muestra cómo a pesar de que el objeto se encuentra en

movimiento (Derecha), al aplicar la matriz de homografía, la transformación
parcial (Izq) reconstruye el objeto a partir de su posición inicial, que precisa-
mente era cuando el tablero estaba en una posición casi horizontal respecto
al punto de vista de la cámara. Se puede observa cómo en la imagen de la
izquierda todo lo que no es el objeto de referencia está rotado respecto del
punto de vista de la cámara. La función de OpenCV utilizada para realizar
esta transformación se denomina cvWarpPerspective() [120].
Figura 6.29: Reconstrucción parcial usando la matriz de homografía.

6.2.2.4. Cálculo del factor de indeterminación
Tal y como se ha expresado en la sección 6.2.1.1, a partir de la matriz de

homografía H obtenemos una reconstrucción parcial, de la cual es necesario
estimar algunos parámetros más para poder obtener la reconstrucción com-
pleta. Partiendo de la expresión:
αh m = H m∗
donde H estará relacionada con rotación y traslación de forma que:
t T
H = γ(R + n ) (6.6)
d∗
lo que se desea en esta propuesta, tal y como se consiguió en la primera

implementación, es obtener el factor de escala para determinar de forma más o
menos precisa cuál ha sido el desplazamiento del objeto respecto de la posición
inicial. Una de las vías por las cuales es posible la obtención de dicho factor,
es observando que:
nT tnT
det(H) = det(R + t ) = (1 + )
d∗ d∗
Se han realizado varias pruebas, situando la cámara perpendicularmente

al objeto de referencia (tablero de ajedrez). En estas condiciones se tiene que
el vector normal del sistema de referencia es de la forma n = (0, 0, 1)T , y se
cumple que las dos primeras columnas de la matriz de homografía son pro-
porcionales a las dos primeras columnas de la matriz de rotación. Otra forma
de cálculo es la siguiente.
En primer lugar, se calcula la descomposición en valores singulares de la

matriz de homografía H:
svd(H) = {σ1 , σ2 , σ3 }, σ1 ≤ σ2 ≤ σ3
En general, existen dos formas para la normalización de la matriz de ho-

mografía. La primera de ellas, es forzando a que el det(H) = 1. La segunda,
más interesante para nuestro caso, es garantizando que σ2 = 1. En este caso,

el factor γ de la fórmula 6.6 debe ser también unitario:
nT
H = (R + t )
d∗
En este caso, se puede comprobar que:
ktk
≡ σ1 + σ3
d∗
Es más, incluso aunque no se haya normalizado H, puede verificarse que

la única diferencia respecto a la relación anterior es que hay que generalizarla
de la forma:
ktk σ1 + σ3
≡
d∗ σ2
Con este resultado teórico se realizarán un conjunto de experimentos si-

milares a los expuestos en la sección 6.1.4.1.
6.2.3. SIFT - Scale Invariant Feature Transform
SIFT es una técnica precursora de SURF propuesta por David G. Lowe

en 2004 [115]. Esta técnica tiene una gran aceptación por la calidad de las
características que extrae.
Para detectar puntos de interés en primer lugar se transforma la imagen I

de la que se quieren extraer los puntos mediante máscaras G de convolución
gaussiana a diferentes escalas:
1 −(x2 +y 2)
G(x, y, σ) = e 2σ 2
2πσ 2
Posteriormente se calculan las diferencias D entre las distintas imágenes sua-
vizadas, donde ∗ es la operación de convolución en x e y:
L(x, y, σ) = G(x, y, σ) ∗ I(x, y) (6.7)
A partir de la ecuación 6.6 se define:
D(x, y, σ) = L(x, y, kσ) − L(x, y, σ)

Posteriormente, el extractor calcula máximos locales en D(x, y, σ) compa-
rando con sus vecinos, tanto en la misma escala σ como en las escalas anterior
y posterior. En la Figura 6.30 se pueden observar todos los píxeles con los que
se realiza la comparación.
Figura 6.30: Píxeles con los que se realiza la comparación del valor de D para
encontrar máximos locales en SIFT.
Para todos los puntos detectados se calcula un descriptor especial em-

pleando la magnitud y la orientación del gradiente. Partiendo de una ventana
de 16x16 píxeles se calculan histogramas de orientación como los de la parte
derecha de la Figura 6.31. Al final, para cada punto de interés se obtiene un
descriptor de 128 parámetros de longitud (4x4x8).
Figura 6.31: Histogramas de orientación SIFT para el cálculo del descriptor.

En la imagen se muestra un ejemplo de tamaño 2x2 histogramas (derecha)
obtenidos a partir de una ventana de 8x8 (izquierda), el extractor utiliza una
ventana de 16x16, obteniendo 4x4 histogramas de descriptores.
Las primeras pruebas experimentales con este método resultan no ser tan
buenas en cuanto a coste computacional. Aunque sea un buen método para la
extracción robusta de características, no es válido para aplicaciones en tiempo
real, y para una imagen media de 752x480, como es nuestro caso, el tiempo
de extracción de características es del orden de segundos para cada imagen.
6.2.4. SURF - Speeded Up Robust Features
Propuesta recientemente por Herbert Bay [111], SURF es una técnica para
la extracción de puntos en una imagen, cuya principal ventaja es su robustez
ante cambios en la rotación o de escala. Esto hace que el posterior empare-
jamiento de características entre imágenes sea muy robusto. Además lo hace
con un coste computacional inferior al de otros extractores de calidad simi-
lares como SIFT [115]. A continuación se presenta una breve descripción del
funcionamiento de este método.
6.2.4.1. Puntos de interés
Lo primero que hace el algoritmo es encontrar puntos de interés dentro

de la imagen. La imagen debe estar tomada en escala de grises, sin embargo,
para obtener una mayor precisión numérica normaliza el valor de cada píxel,
transformándolo en un valor real que se encuentre en el intervalo [0,1].
Con la matriz de píxeles ya normalizados, el algoritmo busca máximos

locales del determinante de la matriz Hessiana. Dado un píxel de la imagen
definido por sus coordenadas p = (x, y), la matriz Hessiana del punto p con
un valor de escala σ se define como:
!
Lxx Lxy
H(p, σ) =
Lxy Lyy
donde Lxx , Lxy y Lyy representan las derivadas segundas parciales de la
gaussiana G(σ) respecto a las coordenadas de cada píxel p = (x, y), descritas
como:
∂ 2 G(p, σ)
Lxy =
∂x∂y
2
∂ G(p, σ)
Lxx =
∂x2
∂ 2 G(p, σ)
Lyy =
∂y 2
Para que el algoritmo sea más eficiente, en lugar de calcular las segun-
das derivadas, se hace una aproximación mediante filtros en forma de caja,
Figura 6.32: De izquierda a derecha: Las derivadas parciales de segundo orden

de la Gaussiana en la dirección de ~y , en la dirección de xy
~ y las aproximaciones
realizadas usando filtros de caja (box filters). Las regiones grises son igual a 0.
como los que aparecen en la Figura 6.32. Si se emplean imágenes integrales,

las convoluciones para estos filtros pueden ser calculadas en muy poco tiempo.
Una imagen integral IP es una representación de la imagen en la que cada

píxel p = (x, y) almacena el valor del sumatorio en ~x y en ~y desde el origen
hasta el punto. Este valor viene representado en la siguiente expresión:
XX
IP = p(x, y)
x y
6.2.4.2. Características de los descriptores
Para cada punto extraído en la imagen integral, se calcula un descriptor

de longitud variable que identifique de forma unívoca dicho punto. Cuanto
mayor sea la longitud que se emplee para los descriptores, el emparejamiento
será más robusto, pero todo el proceso requerirá un mayor tiempo de proce-
samiento.
Las tres características que definen a cada punto son las siguientes:
Signo del determinante de la matriz Hessiana :

Se utiliza para distinguir zonas brillantes sobre fondo oscuro o viceversa.
Esta característica es muy interesante, ya que clasifica los puntos en dos
clases: brillantes y oscuros.
De esta forma, en el emparejamiento, mirando el signo del determinante

se podrían descartar una gran cantidad de puntos sin tener que mirar el
resto de los valores del descriptor.
Orientación del gradiente :

Para cada punto extraído, el extractor define una región circular alrede-
dor del mismo y calcula la orientación dominante del gradiente dentro
de dicha región.
Sumatorio del gradiente :

Se define una región cuadrada alrededor del punto seleccionado del ta-
maño relativo a un factor de escala con el que se detectó. Dependiendo
del tamaño elegido para el descriptor se subdivide la región en partes
iguales (4, 9, 16 ó 32) y se calculan 4 valores en cada subregión basados
en los valores del gradiente obtenidos en la correspondiente subregión.
El conjunto de valores obtenido constituye el descriptor del punto.
Ésta técnica está aún bajo desarrollo en la fecha de entrega del proyecto. Las
primeras pruebas experimentales con códigos de prueba han dado resultados
relativamente pobres en lo que a velocidad se refiere, aunque la eficacia en la
detección y seguimiento6.4 de los puntos es bastante buena.
6.4
No se realiza ninguna tarea de seguimiento; los puntos son recalculados en cada imagen
de la secuencia.
6.3. Otras alternativas para la realimentación visual 150
6.3. Otras alternativas para la realimentación

visual
Al comienzo del desarrollo del proyecto se basó la localización y segui-

miento del objeto de interés en la técnica denominada template matching.
Tras numerosas pruebas, finalmente se descartó por dos motivos:
Pérdida del objeto ante cambios de escala: Si se desplazaba el objeto en

profundidad respecto a la cámara, dado que la plantilla de referencia es
fija, se perdía la localización del objeto en la imagen.
Pérdida del objeto ante rotación: En función de la distancia a la que se

planteara el objeto respecto de la cámara, había un límite en la rotación
(bien de la cámara respecto al objeto o viceversa) en el que se perdía de
nuevo la localización del objeto.
Además, dados los anteriores problemas y que el método es de los denomina-

dos de fuerza bruta, se optó finalmente por buscar nuevas alternativas para la
localización y seguimiento del objeto. Los métodos propuestos en el presente
capítulo son tanto invariantes en los cambios de escala como en los cambios
de rotación. Sin embargo, existen alternativas y propuestas en [34],[36] y [60]
en las que se plantean técnicas aplicadas a template matching para hacerlas
invariantes a los cambios anteriormente mencionados.
Otra posible técnica que hubiera podido ser implementada es el seguimien-

to del objeto considerando solamente los contornos del mismo, tal y como se
plantea en [43]. En esta propuesta, a partir de la localización de los contornos
y del emparejamiento en una secuencia de imágenes, se realiza el cálculo de
la matriz de homografía H entre ambas vistas. El resto de pasos es similar a
lo presentado en este capítulo.
Capítulo 7
Fusión sensorial
Hasta el momento todo lo explicado en los capítulos anteriores se corres-

ponde con el conjunto de técnicas utilizadas para el control basado en visión.
Pero a bordo del quadrotor es necesaria la incorporación de algún otro tipo
de sensor, principalmente debido a que si hubiera problemas con el sensor óp-
tico y no hubiera ninguna medida de seguridad implementada, el vehículo se
precipitaría hacia el suelo, con la más que probable pérdida del mismo.
Es por ello que se requiere de una fusión sensorial completa, de manera que
cuando un sensor no aporte toda la información necesaria para el control y
estabilización del quadrotor, se pueda complementar con alguna otra medida
proveniente de otras fuentes.
7.1. Descripción del sensor inercial
La descripción comercial de la IMU utilizada en el presente proyecto es una

MTi-G (Figura 7.1), de Xsens Technologies B.V. Es una unidad de medida
inercial, con un sistema GPS integrado, y con un procesador que mantiene
siempre un sistema de referencia para la navegación y la altitud. El procesa-
dor interno de bajo consumo ejecuta en tiempo real un Filtro extendido de
Kalman, proporcionando una estimación de la posición 3D y estimación de
velocidad. Dispone, entre otras funcionalidades, de aceleración 3D calibrada,
brújula y barómetro.
En la Figura 7.2 se muestra un esquema de los distintos componentes

y funcionalidades que posee esta unidad. Posee, entre otras, las siguientes
151
7.1. Descripción del sensor inercial 152
Figura 7.1: Detalle externo del sensor inercial.
Figura 7.2: Detalle interno del sensor inercial.
características:
Estimación en tiempo real de las medidas de posición/velocidad y me-

didas de GPS.
Sensibilidad de seguimiento -160 dBm.
Inmunidad a interferencias de tipo GPS.
Sensor de presión (barómetro).
Tasa de actualización de 120Hz, como mínimo.
Bajo consumo ∼ 910 mW.

7.2. Funciones de interfaz con la IMU 153
7.2. Funciones de interfaz con la IMU
La comunicación entre la IMU y el PC104 de a bordo se realiza físicamente

a través de un puerto tipo serie/USB. Se dispone de unos módulos software
que ofrecen funciones de alto nivel para configurar y obtener medidas del dis-
positivo. Pueden obtenerse datos de distintos tipos, fundamentalmente, datos
de orientación, datos de posición y velocidad a partir del GPS, y los llama-
dos ”calibrated data”, incluyendo medidas de aceleración lineal, de velocidad
angular y de norte magnético. También es posible la obtención de medidas
barométricas y de temperatura. A continuación, se comentarán brevemente
las funciones de alto nivel que pueden usarse como interfaz con la IMU.
7.2.1. Datos de orientación
La orientación puede ser obtenida de 3 formas distintas: como un cuater-

nio unitario, mediante los ángulos de Euler o como matriz de rotación. Se ha
observado el hecho de que estos datos presentan una deriva importante en,
al menos, uno de los ángulos. Esto se reduce significativamente situando la
antena GPS en zonas exteriores (al aire libre). En zonas interiores, la deriva
se logra reducir, aunque dista de desaparecer totalmente.
7.2.1.1. Cuaternio unitario
El tipo apropiado para una medida en forma de cuaternio es la siguiente

estructura:
struct CmtQuat { double m data[4]; };
Se definiría un dato de este tipo:
CmtQuat qatData;
y podríamos obtener la medida con la función de lectura:
qatData = packet->getOriQuat(0);
Todas las funciones del tipo get...() tienen como argumento el número del
dispositivo imu del cual toman las medidas. En nuestro caso, será siempre 0,
debido que tan solo hay un sensor de este tipo en el sistema.
7.2.1.2. Ángulos de Euler XYZ (Roll, Pitch and Yaw)
Se puede obtener la orientación mediante la tripleta de ángulos de Euler

respecto a ejes fijos. Cabe destacar que las medidas de estos ángulos se dan
en grados, no en radianes. La estructura de datos asociada es la siguiente:
struct CmtEuler {
double m_roll; // Rotation around x-axis / back-front-line

double m_pitch; // Rotation around y-axis / right-left-line
double m_yaw; // Rotation around z-axis / down-up-line
};
Se definiría un dato de este tipo:
CmtEuler eulerData;
y podríamos obtener la medida mediante:
eulerData = packet->getOriEuler (0);
Los ángulos de Euler tienen una indeterminación cuando el segundo ángulo

está próximo o es igual a los +90º ó -90º. Esta indeterminación no existe en
formato cuaternio o matriz de rotación.
7.2.1.3. Matriz de Rotación
Si lo deseamos, podemos pedir que se nos facilite la matriz de rotación

completa. La estructura asociada es la siguiente:
struct CmtMatrix {
double m data[3][3];
};
Podemos definir un dato de este tipo mediante:
CmtMatrix matrixData;
y obtener la matriz usando la función:
matrixData = packet->getOriMatrix(0);
7.2.2. “Calibrated Data”
Permite obtener la medida de tres sensores: acelerómetro, giróscopo y brú-

jula.
Acelerómetro :
Ofrece una medida de la aceleración lineal (en m/s2 ) de la IMU respecto
al sistema inercial, pero expresado respecto al propio sistema de la IMU.
Un inconveniente de esta medida es que lleva incorporado el efecto de la
aceleración de la gravedad. Es como si, en situación de reposo, la IMU se
estuviera moviendo en dirección vertical hacia arriba con una aceleración
igual a la de la gravedad, aproximadamente: [0, 0, 9,713923]T .
Giróscopo (”gyro”) :
Proporciona un vector velocidad angular (en rad/s) de la IMU respecto
al sistema inercial, pero expresado respecto al propio sistema de la IMU.
Brújula (”compass”) :
Aporta la dirección del vector norte magnético respecto al sistema de
coordenadas local de la IMU. Las unidades son en a.u. (”arbitrary units”,
unidades normalizadas con la fuerza del campo magnético de la Tierra).
Dadas las unidades, de esta medida probablemente sólo tenga sentido
usar la dirección.
Conviene insistir en que estas medidas no están expresadas respecto al sistema

de coordenadas inercial. La estructura asociada es la siguiente:
struct CmtCalData {
CmtVector m acc, m gyr, m mag;
};
Cada uno de los vectores es del tipo:
struct CmtVector {
double m data[3];
};
Podemos definir un dato de este tipo:
CmtCalData calData;
y obtener en él la medida mediante:
calData = packet->getCalData(0);
O bien, para acceder selectivamente:
...= packet->getCalAcc(0);
...= packet->getCalGyr(0);
...= packet->getCalMag(0);
Hay otra opción para obtener los ”calibrated data”, se trata del formato ”raw
data”, en formato entero, sin convertir, y donde va la temperatura ya integra-
da. En este caso, la estructura es la siguiente:
struct CmtRawData {
CmtShortVector m_acc, m_gyr, m_mag;
uint16_t m_temp
};
Cada uno de los vectores es del tipo:
CmtShortVector: struct CmtShortVector {uint16 t m data[3]; };.
Podemos definir un dato de este tipo:
CmtRawData rawData;
y obtener la medida mediante:
rawData = packet->getRawData(0);
Por otro lado, puede obtenerse la medida de temperatura aisladamente:
double temperat = packet->getTemp(0);

7.3. Medidas incompletas de la IMU 157
7.3. Medidas incompletas de la IMU
En principio, se asume que la IMU proporciona una medida relativamente

precisa de la orientación y de la velocidad angular, así como de la aceleración
lineal: θ,ω y a, respectivamente. Estos datos se obtendrían con las llamadas
a las funciones:
a ← getCalAcc(0)
ω ← getCalGyr(0)
θ ← getOriEuler(0) o alternativamente: getOriQuat(0), getOriMatrix(0).
Estas medidas son orientaciones, velocidades etc. del sistema de coorde-

nadas ligado a la IMU (al que en adelante denominaremos {=}, de ”gyro”),
respecto del sistema de coordenadas inercial (al que denominaremos W, de
”world coordinate system”).
En particular, la orientación viene expresada respecto al sistema de refe-

rencia inercial, mientras que la velocidad angular y aceleración lineal vienen
expresadas respecto al sistema de coordenadas móvil de la IMU. Para repre-
sentar este hecho, completaremos nuestra nomenclatura de la siguiente forma:
ω (g)
ag ← getCalAcc(0)
ω (g)
ω g ← getCalGyr(0)
ω (g)
θ g ≡ ω θ (w)
g ←getOriEuler(0)
Sin embargo, nos interesan todas las medidas respecto al sistema de referencia
inercial:
ω
ω
Rg · ag(g)
   
ag
 ω  ω
 ω g  =  Rg · ω (g)
 
g 
ω ω
θg θg
donde ω Rg es la matriz de rotación equivalente a la tripleta de ángulos

ω
θ g = [φ, θ, ψ]T . Para obtener una medida efectiva de la aceleración lineal, es
necesario eliminar la contribución de la gravedad:
ω
ẗg = ω ag −ω g, siendo g ω ≈ [0, 0, 9,713923]T
Por otro lado, en lugar de la velocidad angular ω ω g , nos interesa la deri-

vada de los propios ángulos: ω θ̇ g . La relación entre ambos vectores viene dada
por:
1 r−r 31 r32 −r31 r33

 
2 2 2 +r 2
r32
32 +r33 33
 0 √ r33 √ −r
 
ω 32  ω
θ̇ g =  2 +r 2
r32 2 +r 2
r32  · ωg
 33 33 
0 r2 r+r
32
2 2
r33
2
r32 +r33
32 33
Con esto, es posible componer un vector de medida preliminar, de la forma:
ω
 
ẗg
xraw =  ω θg 
 
ω
θ̇ g
Desde el punto de vista del control, resulta más interesante disponer de

estimaciones tanto de la velocidad como de la posición lineal, en lugar de la
aceleración. A partir de dicha aceleración lineal, se puede obtener por software
una estimación de la velocidad lineal. En principio, la opción más inmediata es
hacer una estimación discreta mediante Euler hacia atrás, usando un período
de integración fijo Tm :
ω
ṫg (k) ≈ ω ṫg (k − 1) + Tm ω ẗg (k)
También podría pensarse en métodos más elaborados para realizar esta

estimación de la velocidad. Por un lado, se puede optar por filtrar la señal de
aceleración lineal despues de realizar un estudio de su espectro frecuencial en
condiciones normales. Por otro lado, en ausencia de un filtrado apropiado de
la aceleración, podría suavizarse su efecto en la integral simplemente modifi-
cando la ecuación anterior por:
ω Tm ω
ṫg (k) ≈ ω ṫg (k − 1) + ( ẗg (k) + ω ẗg (k − 1))
2
En caso de que se estime que el periodo no es suficientemente constante

de un ciclo al siguiente, habría que modificar esta relación por la siguiente:
ω 1
ṫg (k) ≈ ω ṫg (k − 1) + (T (k) ω ẗg (k) + T (k − 1) ω ẗg (k − 1))
2
Donde se tiene que T (k) se define como el tiempo transcurrido desde que
se tomó la medida (k − 1) hasta que se tomó la medida k .
Lo que no parece viable es aplicar el mismo mecanismo de integración (en

cualquiera de sus variantes) para obtener una aproximación de la posición,
puesto que es previsible que integrar dos veces una medida dé resultados poco
aceptables. De este modo, se asumirá que, con la IMU únicamente podemos
llegar a disponer de un vector de medida ampliado respecto al anterior, de la
forma:
ω
ṫg
 
ω
 ẗg 
ximu = 
 
ω
θg

 
ω ˙
θg
Sin embargo, lo que interesa como vector para la realimentación del control
es:
ω
tg
 
ω
 ṫg 
x= (7.1)
 
ω
θg

 
ω ˙
θg
Para resolver esta deficiencia es para lo que se plantea la inclusión del

sensor óptico en el sistema, cuyo modelo ya se ha explicado en el capítulo 5.
A continuación se detalla cómo sería el proceso de integración entre el sensor
inercial y el sensor óptico.
7.4. Fusión de la información 160
7.4. Fusión de la información
En este punto se dispone de información que puede ser redundante y otra

que es complementaria. Por un lado, dado que se asume que la orientación que
proporciona la IMU por sí sola es suficientemente precisa, se puede extraer
la parte del vector de medida correspondiente a w θg . Por otra parte, dada
la dificultad de obtener una medida directa de w tg , se opta por reemplazarla
por o tg . Asimismo, se realizará una estimación de la derivada de este último
vector: o ṫg . Esto conlleva a un nuevo vector de medida:
o
tg
 
o
o,w
 ṫg 
xg = 
 
w
θg

 
w
θ̇ g
el cual tendría como característica poco deseable que no todos sus elemen-
tos están referidos al mismo sistema de coordenadas. Pese a que tal vez esto no
supusiera ningún problema, resulta más natural tener todos los componentes
del vector de medida referidos al mismo sistema de coordenadas, {W}. Para
ello, se se realizará un paso previo de multiplicación de o tg como de o ṫg por la
matriz de orientación ω Ro :
o (w)
tg =w R0 ·o tg
o (w)
ṫg =w R0 ·o ṫg
Resulta, por tanto, necesario disponer de la matriz w R0 . Esta matriz puede
obtenerse en cada momento de la siguiente forma:
w
R0 =w Rg ·g Rc ·o Rc(−1)
Con todo esto, se puede ofrecer el vector de medida definitivo:
 
o (w)
tg
w (w)
ṫg
 
w
 
xg =  w


 θg 

w
θ̇ g
Desde el punto de vista del control, la única diferencia apreciable respec-
to al uso del vector de medida mostrado en 7.1 es que, aún manteniendo la
referencia constante, si se mueve el objeto, se moverá el quadrotor (si bien
sin cambiar su orientación), para reubicarse en la misma posición relativa al
objeto, que es quien fija la referencia.
7.5. Calibración IMU-Cámara 161
7.5. Calibración IMU-Cámara
El acomplamiento mecánico entre la IMU y la cámara se ha realizado a

partir del diseño de la pieza que aparece en la Figura 7.3. Por su parte, en la
Figura 7.4 se puede apreciar la disposición relativa de los dos sensores con la
ubicación aproximada de los sistemas de coordenadas respectivos.
El proceso de calibración IMU-cámara consiste en estimar precisamente

esa disposición relativa de los dos sistemas de coordenadas. En particular, se
busca estimar la posición y orientación del sistema de coordenadas de la cá-
mara {C} respecto al de la IMU {G}.
Figura 7.3: Diseño del acoplamiento entre la imu y la cámara.
Para realizar esta calibración, se utilizó en primera instancia el método

conocido como hand-eye calibration de Tsai y Lenz [72], que tradicionalmente
se emplea para la calibración entre la cámara y el efector final de un robot
Figura 7.4: Acoplamiento real entre la cámara y el sensor inercial.
manipulador al que está rígidamente acoplada aquélla. Para realizar esta cali-
bración es necesario recurrir de nuevo a un objeto de geometría conocida, del
tipo tablero de ajedrez, por ejemplo.
El método parte de la captura de varias imágenes desde diversos puntos

de vista de dicho objeto, el cual debe permanecer inmóvil, mientras se varían
las posiciones de la cámara haciendo uso del brazo articulado. Para cada uno
de los puntos de vista, debe registrarse la posición del efector final del brazo
manipulador y realizar una estimación de la posición y orientación del objeto
respecto a la cámara.
Con esta información, se aplica el algoritmo que proporcionará la transfor-

mación homogénea de la cámara al sistema de coordenadas ligado al efector
final del robot. Para que el resultado sea aceptable, los puntos de vista deben
cumplir algunos requisitos, como que el desplazamiento entre los distintas po-
siciones no sea suficientemente grande y que existan al menos dos pares de
tomas entre las cuales la rotación se realice en torno a ejes no paralelos.
En el presente caso, el papel del efector final lo debe desempeñar de alguna

forma la IMU. La diferencia fundamental estriba en que, si bien la IMU pue-
de proporcionar información de orientación (respecto a un sistema inercial),
es incapaz de proporcionar una medida de posición que permita conocer el
desplazamiento que la misma ha sufrido desde un punto de vista a otro.
Dada esta importante limitación, una opción era hacer las diversas tomas
intentando que el origen del sistema de coordenadas de la IMU no se despla-
zara en ningún momento y jugar únicamente con la orientación para conseguir

puntos de vista diferentes del objeto. Es evidente que, al realizar este tipo de
movimientos, la cámara sí que sufriría algún desplazamiento, aunque bastante
limitado, dada la proximidad entre ambos elementos.
Para intentar garantizar, en la medida de lo posible, que el origen del sis-

tema de coordenadas de la IMU no sufriera ningún desplazamiento durante
el experimento, se optó por utilizar dos punteros lásers inmóviles, dispues-
tos en sendos trípodes de tal forma que sus rayos intersectaran en un punto
en el espacio. Idealmente, en ese punto se colocaría el origen del sistema de
coordenadas de la IMU. Sin embargo, de acuerdo con la documentación del
sensor inercial, el origen del sistema de coordenadas de la IMU no coincide
con ningún punto de la carcasa del dispositivo, sino con un punto interior.
Pese a todo, la localización del mismo es conocida respecto a un punto

característico del exterior (ver punto en rojo próximo a la esquina superior
derecha de la IMU en la Figura 7.3). Este mismo punto se resalta en la parte
izquierda de la Figura 7.4. Se sabe que la posición de dicho punto respecto al
sistema de coordenadas de la IMU es:
[x, y, z] = [12, 22,9, −9,5] , expresado en mm.
Lo que se intentó en los experimentos era forzar a que ese punto fuera el
que permaneciera inmóvil. De esta forma, el origen de la IMU sí se habría
desplazado, pero este desplazamiento es fácilmente calculable.
En la Figura 7.5 puede apreciarse la disposición de todos los elementos,

mientras que en la Figura 7.6 puede verse marcado por los lásers el punto
usado como centro de los giros.
Los resultados de la calibración cámara-IMU empleando el método hand-

eye calibration referido no fueron satisfactorios. Ello se atribuye a que los
desplazamientos entre unas posiciones y otras fueron todos excesivamente re-
ducidos. Como alternativa, se propuso usar un nuevo método, propuesto por
Andreff et al. [122], el cual permite una estimación robusta de la disposición
entre una cámara y un elemento electromecánico incluso en situaciones singu-
lares, tales como rotación pura y traslación pura.
Figura 7.5: Montaje para el proceso de calibración.
En una primera aproximación, más o menos simple, se realizó ésta cali-

bración partiendo de una estimación de la posición del origen del sistema de
coordenadas de la cámara, de las medidas de la pieza de acoplamiento y de la
situación teórica del sistema de coordenadas de la IMU.
Para la estimación de la posición del sistema de coordenadas de la cámara,

es necesario tener en cuenta que la mayor incertidumbre está presente en la
posición a lo largo del eje óptico, mientras que para los ejes X e Y se toma el
centro de la lente (ver Figura 7.4 izquierda). Los experimentos llevados a cabo
para hacer esta estimación consistieron en hacer pares de tomas, de tal forma
que en cada par se realizaba un giro de la cámara respecto a su eje Y, dejando
la plantilla inmóvil e intentando que el giro fuera lo más amplio posible sin
que dicha plantilla se saliera de la imagen.
Se apuntaría con el láser desde arriba de forma que se garantizara que el

giro se realizaba en torno al punto marcado sobre la lente por el láser (ver
Figura 7.7). La única diferencia entre cada par de tomas era que la cámara se
habría desplazado a lo largo del eje Z algunos milímetros7.1 .
7.1
Recalcar que de un par de tomas al siguiente, el objeto puede moverse libremente.
Figura 7.6: Detalle del puntero láser sobre el centro de referencia.
Para la primera y segunda toma de cada par, se estimará la posición y

orientación de la plantilla respecto a la cámara, c1 To y c2 To , respectivamente.
A continuación, se estima la transformación:
c1
Tc2 =c1 Toc2 T−1
o
De todos los giros analizados, aquél para el que el desplazamiento de la

cámara de la primera a la segunda toma tenga menor módulo, debería corres-
ponderse con la situación del origen de la cámara coincidente con la profun-
didad marcada por el láser:
min(kc1 tc2 k)
Figura 7.7: Detalle de la primera estimación para el centro de referencia del

sistema de la cámara.
En una primera estimación, se obtuvo que la profundidad de la lente a la

que se encontraba el origen de la cámara era la que aparece en la Figura 7.7.
Esto hacía que la posición del origen del sistema de coordenadas de la cámara
respecto a la IMU estuviera situada en:
g
tc = [−28,51, −53 − 2, −21]T (mm)
En una segunda estimación (Figura 7.8), esta medida se corrigió, obtenién-
dose finalmente:
g
tc = [−28,51, −53 − 2, −37]T (mm)
correspondiendo con la ubicación que se muestra en las Figuras 7.3 y 7.4

(derecha).
Figura 7.8: Detalle de la segunda estimación (definitivo) para el centro de

referencia del sistema de la cámara.
En lo que respecta a la orientación, de forma aproximada, se estima que

para llevar el sistema de coordenadas de la IMU al de la cámara, basta con
realizar un giro respecto al eje Y de la IMU de 180 grados. Expresado en
forma de RPY, se tendría que:
g
θc = [0, π, 0]T
Resultando como matriz de transformación del sistema cámara-IMU la

siguiente:
−1 0 0 −28,51
 
 0 1 0 −53,2 
g
Tc =  
(10−3 m)
0 0 −1 −37 
 

0 0 0 1
7.6. Otras alternativas de realimentación sensorial 168
7.6. Otras alternativas de realimentación sen-

sorial
Tal y como se mostró en el Capítulo 2, existe una gran variedad de sen-

sores con los que poder realizar controladores relativamente robustos para el
control de vuelo de los UAV. Desde sensores inerciales, como los usados en la
propuesta de este proyecto, hasta sensores de posicionamiento con GPS, entre
otros.
Pero en la literatura también se proponen distintas alternativas para el

control no basadas en imagen. Un ejemplo es el mostrado en [53], en el que
se propone un sensor basado en luz infraroja para la estimación de la altura
de un vehículo aéreo no tripulado. Precisamente haciendo uso de este tipo de
sensores, se muestra en [36,2] un experimento bastante curioso. Se instalan un
conjunto de cámaras en la zona de vuelo del helicóptero, basadas en luz infra-
roja, para calcular en cada momento mediante triangularización la posición
actual del vehículo.
Figura 7.9: Control de UAV mediante cámaras infrarojas.
Con ésta técnica, es posible realizar maniobras a gran velocidad, como por
ejemplo pasar a través de un pequeño hueco en una pared a una velocidad de
varios m/s (Figura 7.9) o esquivar obstáculos en tiempo real. A diferencia del
control visual planteado en el presente proyecto, la cámara en estos casos no
va a bordo del quadrotor.
Otra propuesta para un control distinto al presentado en esta sección es la

mostrada en [5], en la que se describe un controlador de vuelo y de navegación
para un vehículo aéreo no tripulado de ala fija (distinto al quadrotor)(Figura
7.10) con sensores de bajo coste, tales como altímetros barométricos o medi-
dores para la velocidad del aire, para mejorar la eficiencia en la gestión de
posibles situaciones de emergencia. Se incluyen además filtros adaptativos de
Kalman para obtener medidas más robustas para el control de la altitud y
una red neuronal para el control de la actitud.
Figura 7.10: Vehículo aéreo de ala fija.

Capítulo 8
Hardware y modelado del

helicóptero Quadrotor
En este capítulo, en primer lugar, se describen a nivel teórico las ecuacio-

nes que gobiernan la dinámica del movimiento del quadrotor. Posteriormente
se incluye el esquema general de control para la estabilización del quadrotor,
incluyendo el sistema de visión y el sensor inercial, cerrando el lazo de control.
Por último, se describe en conjunto todos los componentes que conforman el
hardware del sistema.
Todo lo relacionado con el modelado lineal del sistema del quadrotor y las
propuestas de estructuras de control para el seguimiento de trayectorias se
ha extraído del documento [52], trabajo fin de Máster de Guilherme Vianna,
integrante del grupo de investigación.
8.1. Descripción del modelo del quadrotor

8.1.1. Descripción del modelo del UAV
El vehículo aéreo utilizado es un helicóptero en miniatura con cuatro roto-

res coplanarios (quadrotor), como el representado en la Figura 8.1. El movi-
miento del mismo se origina a partir de los cambios de velocidad de los rotores,
los cuales constan de un motor eléctrico de corriente continua, un mecanismo
de engranaje y un rotor de palas. Para lograr movimiento hacia adelante la
velocidad del rotor trasero debe ser aumentada y, simultáneamente, la veloci-
dad del rotor delantero debe ser disminuida.
171
8.1. Descripción del modelo del quadrotor 172
El desplazamiento lateral se ejecuta con el mismo procedimiento, pero

usando los rotores de la derecha y de la izquierda. El movimiento de guiñada
(yaw) se obtiene a partir de la diferencia en el par de torsión entre cada par
de rotores, es decir, se aceleran los dos rotores con sentido horario mientras se
desaceleran los rotores con sentido anti-horario, y vice-versa.
Figura 8.1: Esquema básico de funcionamiento del quadrotor.
8.1.2. Planteamiento del modelo del sistema
En esta sección se presenta el modelado basado en leyes físicas que des-

criben la posición y orientación del helicóptero quadrotor. Para obtener el
modelo dinámico se supone al vehículo como un cuerpo rígido en el espacio,
sujeto a una fuerza principal (empuje) y tres momentos (pares). En la Figura
8.2 se muestra las fuerzas que ejercen las distintas hélices para generar el mo-
vimiento del vehículo.
Para generar un movimiento de balanceo o de roll (ángulo φ) se realiza

mediante un desequilibrio entre las fuerzas f2 y f 4 (ver Figura 8.2). Para el
movimiento de cabeceo o de pitch (ángulo θ), el desequilibrio a realizar será
entre las fuerzas f1 y f3 . El movimiento en el ángulo de guiñada o de yaw
(ángulo ψ) se realizará por el desequilibrio ente los conjuntos de fuerzas (f2 ,
f4 ) y (f1 , f3 ). Este movimiento es posible ya que los rotores 1 y 3 giran en
sentido contrario a los rotores 2 y 4. Para concluir, el empuje total que provoca
que el helicóptero se desplace perpendicularmente al plano de los rotores, se
obtiene como la suma de las cuatro fuerzas que ejercen los rotores.
Figura 8.2: Conjunto de fuerzas sobre el modelo ideal del quadrotor.
Un comentario más al respecto está relacionado con los efectos giroscópicos

resultantes, tanto del cuerpo rígido rotando en el espacio como de la rotación
de las cuatro hélices. En la siguiente tabla se muestran los principales efectos
físicos que actúan sobre el helicóptero.
Término Correspondencia
C Términos constantes
Ω Velocidad angular del rotor
JR Momento de inercia rotacional
l Distancia del centro de masa a los rotores
J Momento de inercia del cuerpo rígido
φ, θ, ψ Ángulos de Tait-Bryan
Efectos Fuentes Formulación

Efectos Aerodinámicos - Rotación de los rotores.
- Giro de hélices. CΩ2
Pares Inerciales Opuestos - Cambio en la velocidad de
rotación de los rotores. JR Ω̇
Efectos de la Gravedad - Posición del centro de masa. l
- Cambio en la orientación
Efectos del cuerpo rígido. Jθψ
Giroscópicos - Cambio en la orientación
del plano de los rotores. JR Ωθ, φ
Fricción - Conjunto de movimientos.
del helicóptero C φ̇,θ̇, ψ̇
Respecto al modelo del helicóptero, se asume que el centro de masa es

coincidente con el origen del sistema de coordenadas fijo al helicóptero, y se
supone que la estructura del mismo es simétrica, lo que resulta en la matriz
de inercia diagonal.
Para la estimación de la posición y orientación del vehículo respecto a un

sistema de coordenadas de referencia inercial {W}, se tiene en cuenta que el
helicóptero está caracterizado por un sistema de coordenadas ligado a él y con
origen en su centro de masa (Figura 8.2).
Este sistema se define considerando B = {− x→ −

→ → −
L , yL , zL } como el sistema de
coordenadas fijo al helicóptero, donde el eje −x→
L es la dirección normal de ata-
−
→ −
→
que del helicóptero, yL es ortogonal a xL y es positivo hacia estribor en el
plano horizontal, mientras que → −
zL está orientado en sentido ascendente y or-
togonal al plano xL OyL . El sistema de coordenadas inercial, W = {→
−
→ −
→ −x ,→
−y ,→
−
z}
se considera fijo respecto a tierra.
En [52] se designa el vector ξ = {x, y, z} como la posición del centro de

masa del helicóptero con respecto al sistema inercial W. De igual modo, la
orientación del vehículo viene dada por la matriz de rotación RW : B −→ W,
donde RW es una matriz de rotación RPY.
La rotación de un cuerpo rígido puede ser representada mediante los án-

gulos de Tait-Bryan, los cuales, son tres ángulos usados para describir una
rotación general en el espacio Euclideo tridimensional a través de tres rotacio-
nes sucesivas entorno al sistema de ejes móvil sobre el que están definidas. Así,
la configuración de la rotación de un cuerpo rígido en el espacio es realizada
a través de tres rotaciones sucesivas:
Rotación según ~x de φ: el primer giro es el correspondiente al ángulo de

roll o de balanceo, φ , y se realiza alrededor del eje ~x .
Rotación según ~y de θ : el segundo giro se realiza alrededor del eje ~y a

partir del nuevo eje ~yL , con el ángulo pitch o de cabeceo, θ , para dejar
el eje ~zL en su posición final.
Rotación según ~z de ψ : el tercer giro y última rotación corresponde al

ángulo de guiñada o yaw, ψ , alrededor del eje ~z a partir del nuevo eje
~zL para llevar al helicóptero a su posición final.
A partir de las rotaciones presentadas anteriormente, se pueden definir las ma-

trices de rotación y tipo de rotación que representan la orientación del cuerpo
rígido rotando alrededor de cada eje.
Si se denominan a estas matrices R(x, φ), R(y, θ) y R(z, ψ), la matriz de

rotación completa de B respecto de W , denominada matriz de coseno directa,
viene dada por la expresión:
RW = R(z, ψ) · R(y, θ) · R(x, φ).
Sin entrar en detalles matemáticos, la matriz de rotación expresada en

el sistema de coordenadas de B es la traspuesta de RW debido a que dicha
matriz es ortonormal. A partir de la matriz RW y relacionando la derivada
de la matriz ortonormal con una matriz anti-simétrica, se pueden obtener las
ecuaciones cinématicas de rotación del vehículo que establecen las relaciones
entre las velocidades angulares.
La relación entre las velocidades angulares en el sistema fijado al cuerpo y

la variación en el tiempo de los ángulos de Tait-Bryan viene dada por:
  
1 0 −sinθ φ̇
ω =  0 cosφ sinφ cosθ   θ̇ 
  
0 −sinφ cosφ cosθ ψ̇
El movimiento rotacional del helicóptero viene dado por las componentes

de las velocidad angular en los tres ejes: velocidad angular de balanceo (p),
velocidad angular de cabeceo (q), y velocidad angular de guiñada (r), sobre
los ejes {−
x→ −
→ → −
L , yL , zL } respectivamente.
Estas velocidades rotacionales son debidas a los pares ejercidos sobre el

sistema ligado al cuerpo del helicóptero producidas por las fuerzas externas,
las cuales definen los diferentes momentos en los tres ejes: momento de balan-
ceo (L), momento de cabeceo (M), y momento de guiñada (N) sobre los ejes
{−
x→ −
→ → −
L , yL , zL } respectivamente.
El movimiento de traslación viene dado por las componentes de la velo-

cidad v0 en los tres ejes inerciales con relación a la velocidad absoluta del
helicóptero expresada en la base B, V0 . Las velocidades v y V están relacio-
nadas por la expresión: v0 = RW · V0 .
8.1.2.1. Ecuaciones dinámicas del helicóptero
Las ecuaciones dinámicas de un cuerpo rígido sujeto a fuerzas externas

aplicadas al centro de masa y expresadas en el sistema de coordenadas B se
pueden obtener a través de la formulación de Newton-Euler como sigue:
" #" # " # " #

mI3x3 0 v̇ ω × mV F + Fd
+ =
0 J ω̇ ω × Jω τ + τd
donde J ∈ R3x3 es la llamada matriz de inercia, I3x3 es la matriz identidad,

v es el vector de velocidad translacional, ω es el vector de velocidad angular
y m es la masa total del helicóptero.
De acuerdo con las suposiciones anteriores, la matriz de inercia J se pue-

de suponer diagonal, y si consideramos el vector de estado ζ = [ξ v 0 η ω]T
donde ξ y v 0 representan la posición y la velocidad lineal expresada en W,
η = [φ θ ψ] y ω es la velocidad angular expresada en el sistema del helicóp-
tero, se pueden reescribir las ecuaciones de movimiento de un cuerpo rígido
como (idéntico resultado en [3]):
ξ˙ = v




˙ I FB

mv 0 = R


donde ξ˙ = v 0 = RW V y S(ω) = RW
T
R˙W




ṘW = RW S(ω)
Jω̇ = −ω × Jω + τb


Por otra parte, FB y τB , definidas en el sistema del helicóptero, son las

fuerzas y pares externos aplicados al cuerpo del helicóptero, y consisten basi-
camente en su propio peso, en el vector de fuerzas aerodinámicas, en el empuje
y en los pared desarrollados por los cuatro motores.
Reescribiendo las ecuaciones, y considerando, entre otros, la suma del to-

tal de fuerzas de los rotores, se obtiene la ecuación diferencial no lineal que
caracteriza al sistema:
4
X
ζ̇ = f (ζ) + gi (ζ)Ui
i=1
donde:
ζ: Vector de estados, de la forma ζ = [ξ v 0 η ω]T .
Ui : Entrada principal de control aplicada sobre el motor i-ésimo.
f, g: Expresiones definidas en [52] en función de ζ.
Según se concluye, se determina que la expresión anterior es suficiente para el

diseño de un controlador en el cual se consideran los momentos aerodinámicos
y las fuerzas que puedan actuar sobre el vehículo en entornos desconocidos
como un conjunto de perturbaciones externas.
En el diagrama de la sección 8.2, se muestra el conjunto de vectores de

medidas que se definen para cada elemento, y la relación en el esquema de
control realimentado para el control del quadrotor. En este caso se define
como:
 
φ
 θ 
ϕ= 
ψ
al vector que contiene la rotación respecto a cada eje, el cual se define

tanto para la IMU como para la cámara, de la forma W ϕG para el caso de la
IMU respecto del sistema inercial y O ϕC para el caso de la cámara respecto
del sistema del objeto.
Del mismo modo se añaden al sistema dos nuevos vectores de estado; el

primer de ellos ya se definió en el capítulo de la fusión sensorial, y recoge
toda la información que aporta la IMU y la cámara, el cual tiene la siguiente
expresión:
 
O (W)
pG
W
 
W
 ṗG 
xG =  W


 ϕG 

W
ϕ̇G
Tras el proceso de fusión sensorial, el vector de estado con el que se reali-

mentaría al lazo de control es el expresado anteriormente: W xG . Sin embargo,
el vector anterior expresa velocidad, posición y ángulos de la IMU ({G}) res-
pecto al sistema de coordenadas inercial {W} , siendo incompatible con las
entradas del controlador, el cual, requiere de medidas que estén expresadas
respecto al sistema de referencia del quadrotor, {B}.
Para solventar este problema, se supone de la existencia de un dispositi-

vo tipo caja negra, denominado “Transformación”, entre el bloque de fusión
sensorial y el controlador, de forma que se pueda adaptar el vector de estados
W
xG al sistema de referencia del quadrotor, {B}, mediante la siguiente expre-
sión:
W
pB
 
W
W
 ṗB 
xB =  W

ϕB
 
 
W
ϕ̇B
Dado el conjunto anterior de expresiones, en la sección siguiente se presenta

el esquema general de control del quadrotor.
8.2. Esquema general de control 180
8.2. Esquema general de control

8.3. Descripción del equipo 181
8.3. Descripción del equipo
La plataforma que se ha utilizado para el conjunto de experimentos es un

helicóptero en miniatura (Figura 8.3) propulsado por cuatro rotores (Figura
8.4). A bordo del aparato se colocan los siguientes sensores:
Cámara uEye modelo u220. Resolución de 752x480, a unos 40 fps, pro-

fundidad de color de 8 bits.
Sensor de medida inercial (IMU), para los datos de aceleración y posi-

ción mediante GPS.
PC 104 Cool LiteRunner-ECO, de la compañia LIPPERT Embedded

Computers GmbH. Aparte de los puertos de E/S de los que dispone este
equipo, el equipo dispone de un µ-procesador Intel Atom Z510 a 1.6
Ghz de doble núcleo, con 2 GB de memoria DRAM y hasta 4 GB de
memoria FLASH como soporte para memoria principal. Los motivos por
los cuales se ha escogido este equipo son:
• Equipo de bajo consumo (∼ 11 W).

• Dado que toda la tarea de procesamiento de imágenes es llevada a
cabo on-board (no va a existir un equipo off-line que se encargue
de gestionar el procesamiento visual y de enviar las consignas de
control a los motores, como en [3]), se precisa de un procesador
que al menos fuera de doble núcleo, incluyendo además suficiente
memoria dinámica, para evitar que el equipo supusiera un cuello
de botella en el sistema. En la Figura 8.5 se puede ver en detalle
una ilustración de este elemento.
En la Figura 8.6 se muestra el acoplamiento mecánico entre la cámara y el

sensor inercial.
Figura 8.3: Detalle del helicóptero en miniatura.
Figura 8.4: Detalle de uno de los rotores integrados en el quadrotor, en fase

de pruebas.
Figura 8.5: Equipo integrado on-board PC-104.
Figura 8.6: Detalle de integración de los sensores inercial y óptico a bordo del
quadrotor.
Capítulo 9
Trabajos futuros y conclusión
9.1. Ampliaciones y otras alternativas para el

control
Debido a la formación obtenida correspondiente a Ingeniería en Informá-

tica, el autor ve este campo desde otro punto de vista al que lo pudiera ver,
por ejemplo, un Ingeniero en Aeronáutica. Dada la formación en asignaturas
como Inteligencia Artificial o Procesadores de Lenguajes, a continuación se
exponen posibles ampliaciones o nuevos proyectos que versan sobre este área,
y las conclusiones derivadas de la finalización del proyecto.
9.1.1. Open Tracking Library
Enlace indicado en [125], se trata de una librería para desarrollar aplica-

ciones para el seguimiento tridimensional de objetos en el espacio. Hace uso
de la librería OpenGL para la visualización de los resultados. Las principales
características de la misma son las siguientes:
Arquitectura software modular, con programación orientada a objetos.
Conjunto de algoritmos y técnicas básicas para el procesamiento digital

de imágenes: filtros Bayesianos, representación de la posición, almace-
namiento, etc.
Algoritmos optimizados con soporte para tiempo real y procesamiento

GPU (Graphic Processor Unit).
Abstracción genérica de sensores del tipo cámara, rádar, GPS, etc.
184
9.1. Ampliaciones y otras alternativas para el control 185
Posibilidad de integración multiplataforma.
Sería interesante poder desarrollar algún código con esta librería, pero debido
a falta de tiempo se deja como una posible alternativa para el desarrollo futuro
de aplicaciones para el control visual.
9.1.2. Lenguaje de comunicación de UAVs
Esta parcela es más relativa a lo visto en la Titulación del autor que a

lo propio que se haya podido aprender en este proyecto. Esta propuesta de
un posible lenguaje para UAVs partió como un trabajo voluntario para una
asignatura de procesadores de lenguajes.
Sería muy interesante poder desarrollar esta idea, porque a partir de vehícu-
los aéreos realmente autónomos, es posible generar una comunicación entre
ellos con un formato determinado, y poder realizar tareas complejas. A conti-
nuación se detalla brevemente esta propuesta.
9.1.2.1. Características del lenguaje propuesto
El lenguaje presentado es una combinación de dos lenguajes completamen-

te distintos; por un lado, se han extraído ideas del lenguaje propuesto en [126],
el cual es una propuesta de un lenguaje para comunicación en sistemas mul-
tiagentes. Este lenguaje se adapta a un sistema multiagente de forma eficaz
porque es orientado a objetos, lo que le da cierta flexibilidad para la definición
de distintos tipos de atributos y/o métodos. Un ejemplo del mismo se muestra
a continuación:
value CommunicationService is abstraction ()

{
Send_Receive : Connection[Message];
Transmit_Deliver : Connection[any];
..
choose {
//send message
via Send_Receive receive message_out;
unobservable;
...
via Transmit_Deliver send transmit_out;
or
...
}
}
El otro lenguaje del cual también se han extraído varias ideas es el presentado
en [127]. En este documento se propone un lenguaje para la comunicación entre
un vehículo aéreo no tripulado (UAV) y una torre de control. Lo singular que
presenta esta propuesta es que la comunicación se basa en el lenguaje natural,
con lo que aparentemente es relativamente sencillo de entender e implementar.
Un ejemplo del mismo se muestra a continuación:
HORIZON: Inbound.
CONTROLLER: Horizon. Clear to land runway 29.
HORIZON: Roger. Preparing to land on runway 29.
Así pues, queda mostrar un ejemplo del lenguaje propuesto. Cabe destacar que
no es más que una primera propuesta, con bastantes elementos mejorables:
CONTROL_MODULE task1
OPEN
>STATE_DEFINITION OPEN:
<GROUP : identificadorGrupo1>
UAV_SET
UAV_DEF
UAV_ID := UAV2
UAV_POSITION
GPS_COORDENATE := (11p3822)
GPS_ALTITUDE := (23)
END UAV_POSITION
END UAV_DEF
...
END UAV_SET <GROUP;>
>STATE_DEFINITION CLOSE;
>CONTROL_ROUTINE OPEN:
...
<PROCS;>
<MAIN>
loop until
(identificadorGrupo1.uav1.GPS_COORDENATE != coorden)
identificadorGrupo1.uav1.go_to_coorden();
end loop
<MAIN;>
>CONTROL_ROUTINE CLOSE;
>COMMUNICATION_PROTOCOL OPEN:
FORBIDDEN,ON_DEMAND in identificadorGrupo1
>COMMUNICATION_PROTOCOL CLOSE;
CONTROL_MODULE CLOSE
La idea que se plantea es la mostrada. El posible área de investigación rela-

cionada con esta temática es muy amplia.
9.1.3. Ampliaciones con la librería OpenCV
Existen muchos algoritmos y técnicas de OpenCV que no han sido vistos

debido a falta de tiempo. Clasificadores, algoritmos de condensación para el
seguimiento de objetos, optimización del código a bajo nivel con el conjunto
de utilidades TBB9.1 de la versión 2.0, etc. La librería de OpenCV es muy
extensa, y posee algoritmos para casi todo.
Por ejemplo, dado que la cámara del sistema es monocroma, todos los
algoritmos para la localización y el seguimiento del objeto están basados en
este tipo de imágenes. Sin embargo, existen gran cantidad de métodos para la
localización y seguimiento de objetos que son muy robustos ante cambios en
la escala y rotaciones, basados en el color o en otras propiedades; información
visual que no es posible capturar con este tipo de sensor óptico.
9.1
Intel Threading Building Blocks (Intel TBB) es una biblioteca basada en plantillas
para C++ desarrollada por Intel para facilitar la escritura de programas que exploten las
capacidades de paralelismo de los procesadores con arquitectura multinúcleo.
9.1.4. Obtención de un controlador robusto mediante

algoritmos genéticos
Un algoritmo genético, básicamente consiste en representar el dominio de

un determinado problema como un conjunto de individuos, caracterizándolos
mediante su cromosoma. A partir de una población inicial, y aplicando un
conjunto de operadores básicos (la mutación y el cruce), es posible encontrar
una población que mediante los anteriores operadores y tras varias generacio-
nes den resultados interpretables como posibles soluciones.
Con esta idea, en [130] se presenta una propuesta que consiste en la aplica-
ción de los algoritmos genéticos para la obtención de los parámetros necesarios
de un controlador PID robusto ante posibles perturbaciones (tales como rá-
fagas de viento) para controlar el vuelo de un mini-helicóptero. Se parte de
una población inicial, y mediante un proceso de aprendizaje y evolución de la
población aplicando operadores de mutación y cruce, tras varias generaciones
(unas 27, y 6 horas después) consiguen obtener los parámetros para un con-
trolador que, como se puede ver en [130], hace que el vuelo del helicóptero
sea relativamente estable. En la Figura 9.1 se puede observa un detalle de los
experimentos presentados en esta propuesta.
Figura 9.1: Obtención del controlador de vuelo mediante algoritmos genéticos.

9.1.5. Aplicación de técnicas de inteligencia artificial

para el control
Existen muchas otras técnicas de I.A., además de la presentada en la sec-

ción anterior, que son posibles aplicar al campo del control de UAVs. Por
ejemplo, una red neuronal se puede definir como un grafo dirigido, en el que
existen varias capas interconexionadas entre sí, y cuyo objetivo es adecuar
el sistema que está modelando al entorno para que el comportamiento sea el
adecuado.
Este tipo de técnicas ([10][11]) sustituirían a cierta parte del controlador

en el lazo de control para el control visual, puesto que gran parte de la com-
plejidad del mismo se asume ponderando ciertas aristas y adecuando dichos
pesos en el proceso de entrenamiento. Sería un campo muy interesante en el
cual poder investigar en un futuro.
Otra técnica relacionada con la inteligencia artificial consiste en el apren-

dizaje automático. Existen muchos métodos para el aprendizaje por parte de
una máquina de cierta tarea, pero los sistemas clasificadores propuestos por
Holland son los que más se adecuarían a esta aproximación. Se trata de un
conjunto de sensores que captan la información del exterior, y en base a un
conjunto de reglas pre-establecidas y a una implementación de una versión
simplificada de algoritmos genéticos, es posible conseguir un vuelo automáti-
co por parte de un UAV, utilizando por un lado el control visual que cierre el
lazo de contro, pero ante posibles perturbaciones como pudieran ser pájaros
o otro tipo de objeto/animal el vehículo “supiera” que se tiene que apartar, y
dar los comandos de control necesarios al sistema para evitar dichos obstácu-
los. Es otra área de investigación muy interesante, puesto que con este tipo de
técnicas de aprendizaje automático realmente es posible construir vehículos
que realmente posean capacidades de autonomía.
Existen en la literatura muchas más aplicaciones, que si el lector estuviera

interesado, puede consultar: [47],[4],[8] y [12]. En el último artículo se expone
una propuesta muy interesante: aplicar técnicas de agentes inteligentes para
el control de vehículos autónomos. Pero es posible llevarlo un paso más allá:
¿Sería posible generar una red de UAV’s (Figura 9.2), gobernados por
agentes inteligentes, interconectados entre sí [60] y hablando el mismo len-
guaje, entrenados para evitar cierto tipo de obstáculos, basando sus leyes de
navegación en esquemas de control visual para realizar una tarea específica?
Figura 9.2: Ejemplo de robots colaborativos.
La pregunta pudiera ser un poco extravagante, pero si el lector supiera que

la NASA está actualmente investigando [49] en sistemas complejos de agentes
inteligentes para futuras misiones espaciales utilizando plataformas aéreas no
tripuladas basadas en cierta parte, control visual, ¿cambiaría de opinión?.
Mi opinión es que es un área fascinante, a la que me encantaría dedicarme

en un futuro.
9.2. Conclusión 191
9.2. Conclusión
Para introducir al lector de forma breve en los proyectos más interesantes

y relevantes, en la siguiente tabla se muestran los principales grupos de inves-
tigación y las plataformas de helicópteros autónomos en uso hoy en día.
Centro Características principales

Georgia Institute of Technology, Helicóptero Yamaha R-50
Atlanta,USA. ISIS IMU con frec. de actualización a 100Hz
Desviación 0.02 grados/ minuto.
Altímetros basados en radar y sonar
Control basado en redes neuronales
Feedback Linearization
Canegie Mellon University, Helicóptero Yamaha R-Max
Pittsburgh,USA. Litton LN-200 IMU a 400Hz
Novatel RT-2 GPS diferencial
Control H∞
University of Southern Helicóptero Bergen Industrial Twin
California,USA. ISIS IMU a 100Hz frec. de actualización
Control PID
Linkoping University, Suecia. Helicóptero Yamaha R-Max
RTK GPS, sonar, compass, sensor de
temperatura y presión
Yamaha sensores de actitud (YACS)
Control Fuzzy. Basado en modelado dinámico
Massachusetts Institute Helicóptero X-Cell 60
Technology,MIT,USA. ISIS IMU a 100Hz frecuecia de actualización
Superstar GPS a 1Hz
Control basado en LQR
University of California Helicóptero Yamaha R-Max
Berkeley,USA. Sistema integrado Boeing DQI-NP
INS/GPS. Provee información de velocidad,
posición y actitud
La realización de este proyecto ha supuesto un gran enriquecimiento, tan-

to personal como intelectual. El enriquecimiento personal ha sido inherente al
continuo contacto con varios compañeros y con el tutor del proyecto, el cual
me ha ayudado muchísimo para lograr la finalización del presente trabajo. Sin
su ayuda, este proyecto hubiera albergado aún más dificultad.
Los conocimientos teóricos y técnicos adquiridos son muchos y muy va-

riados: desde la comprensión de la dinámica de vuelo del quadrotor, hasta la
configuración y puesta en marcha de distintos tipos de librerías, pasando por
el estudio del controlador propuesto en [52] para la estabilización del helicóp-
tero, entre otros.
Dada mi titulación, y una vez adquiridos los conocimientos tras la reali-

zación del presente proyecto, es fácil imaginar posibles ampliaciones o apli-
caciones, tal y como queda expuesto en el presente capítulo. Es un área de
investigación muy extensa e interesante, en la con una frecuencia cada vez ma-
yor se proponen nuevas técnicas y/o aplicaciones sobre las plataformas UAVs.
Apéndice A
Código desarrollado
El conjunto de clases que se han desarrollado específicamente para las

tareas presentadas en el presente proyecto son 4:
CSensorCamara.hpp: Contiene la implementación detallada en la sección

6.1.
CSensorCamara2.hpp: Contiene la implementación detallada en la sec-

ción 6.2.
homographyDecomposition.hpp: Contiene la implementación detallada

en la sección 6.2.1.
seleccion.hpp: Conjunto de funciones útiles para la selección manual del

objeto.
Además, para el desarrollo del código anterior se hicieron uso de un conjunto

de bibliotecas pre-definidas :
matriz.hpp: Biblioteca de funciones para manipulación de matrices.
general.hpp: Biblioteca de funciones para definición y manipulación de

tipos de datos.
En el CD adjunto a la documentación del presente proyecto se pueden encon-

trar los ficheros fuentes asociados.
194
APÉNDICE A. CÓDIGO DESARROLLADO 195
Apéndice B
OpenCV
B.1. Características de la versión 2.0
La libreria OpenCV (Open Source Computer Vision) es una libreria com-

puesta de funciones para aplicaciones de visión por computador en tiempo
real. Ha sido desarrollada bajo licencias del tipo BSD (Free to Share, Free to
Remix), y el principal precursor ha sido Intel, entidad que financió las prime-
ras fases de desarrollo de la libreria.
Actualmente está financiada por el grupo de trabajo WillowGarage. Para

más información, se puede visitar la página de la versión 2.0 en Internet:
http://opencv.willowgarage.com/wiki/ o consultar [120].
B.2. Configuración de OpenCV

B.2.1. Configuración en Ubuntu 9.10
Conseguir empezar a trabajar con esta librería fue toda una hazaña. El
conseguirlo para una distribución de Linux, mucho menos. A continuación se
exponen de forma detallada los pasos a seguir para la instalación y puesta
en marcha de la libreria OpenCV, en su versión 2.0, en la distribución de
Linux Ubuntu 9.10. También se ha conseguido instalar de forma satisfactoria
196
B.2. Configuración de OpenCV 197
en la versión Karmic 10.04. Para otras versiones, tanto de librería como de

sistema operativo, los pasos descritos a continuación no garantizan el correcto
funcionamiento, aunque es posible que también funcione correctamente.
B.2.1.1. Paso 0
En primer lugar, es imprescindible asegurarnos que las versiones de los
paquetes que se van a descargar estén actualizadas, y sean estables. Para ello,
en el menú de usuario de Ubuntu, accedemos a :
Sistema -> Administración -> Orígenes del Software
En esta ventana deben estar marcados, al menos, las que se indican a conti-
nuación para el propósito de esta guía:
Figura B.1: Lista de servidores de versiones
A continuación , sobre la pestaña ’Other Software’, seleccionar, al menos,

las siguientes opciones:
http://archive.canonical.com/ubuntu karmic partner

http://archive.canonical.com/ubuntu karmic partner (Source
Code)
Es necesario asegurar que la versión de los paquetes esté actualizada:
> sudo apt-get upgrade

B.2.1.2. Paso 1
Obtenemos todos los prerequisitos necesarios para el correcto funciona-
miento de la libreria OpenCV:
> sudo apt-get install build-essential libgtk2.0-dev
Estas son las librerias que dan soporte para video en OpenCV:
> sudo apt-get install libavcodec-dev libavformat-dev

libjpeg62-dev libtiff4-dev
> sudo apt-get install build-dep libswscale-dev swig
FFmpeg es una plataforma para el manejo de streams de video y audio.

En el caso de que al intentar instalar la libreria build-dep se produzca
algún tipo de error, bien porque no se ha definido dicha libreria para nuestra
distribución de Linux o bien porque no se encuentra en el repositorio, probar
con el siguiente comando:
> sudo aptitude build-dep
B.2.1.3. Paso 2
Obtenemos la versión 2.0 de la libreria de Intel, en su versión para sistemas
tipo UNIX, y la desempaquetamos por ejemplo en nuestra carpeta personal
’home’:
Fuente de la descarga:
http://sourceforge.net/projects/opencvlibrary/files/
opencv-unix/2.0/
Comando para desempaquetar:
> tar -xjf OpenCV-2.0.0.tar.bz2
B.2.1.4. Paso 3
A continuación se van a generar los enlaces simbólicos para las librerias de
video. En este punto es necesario loguearse en el sistema como super-usuario
(sudo -s) y realizar las siguientes operaciones:
> mkdir /usr/include/ffmpeg

> ln -s /usr/include/libavcodec/avcodec.h
/usr/include/ffmpeg/avcodec.h
> ln -s /usr/include/libavformat/avformat.h
/usr/include/ffmpeg/avformat.h
> ln -s /usr/include/libavformat/avio.h
/usr/include/ffmpeg/avio.h
> ln -s /usr/include/libavutil/avutil.h
/usr/include/ffmpeg/avutil.h
El comando ln en linux sirve para establecer enlaces entre archivos.
B.2.1.5. Paso 4
Volvemos a la carpeta donde se haya descomprimido los fuentes de la
libreria OpenCV, y procedemos a realizar las operaciones de configuración e
instalación:
> ./configure --prefix=/usr/local/opencv

--enable-apps --enable-shared
--enable-swscale --enable-gpl --with-swig
> sudo ln -s /usr/include/libswscale/swscale.h
/usr/include/ffmpeg/swscale.h
Nota 1: Probablemente en el terminal hayamos obtenido algún mensaje

relacionado con swscale o gpl. Este mensaje variará en función de la
versión que hayamos descargado de los fuentes en el paso 1.Puesto que
no son imprenscindibles, pueden ser omitidos por el momento.
Nota 2: En el caso de que tras este punto se haya producido algún error,
es necesario volver al paso 2. Esto es debido a que cuando lanzamos
el comando ./configure se modifica el make generado, por lo que si se
han creado enlaces simbólicos con alguna de las librerias anteriores, es
necesario partir de una copia limpia del conjunto de fuentes de OpenCV.
B.2.1.6. Paso 5
Una vez que hemos creado todos los enlaces, descomprimido la libreria e
instalado todas las librerias auxiliares, se procede a compilar la libreria para
nuestro sistema. Es posible que para realizar la siguiente operación tengamos
que loguearnos como super-usuario. Los pasos a seguir son los siguientes:
1. En el directorio donde se ha descomprimido la libreria, procedemos a
compilar los fuentes haciendo uso del comando make:
> make
Importante: Si despues de hacer el make se generan errores, en funcion de

la version del paquete que se haya descargado, es necesario o bien volver
al paso 0, comprobar que los orígenes de software son los correctos, y
volver a realizar los pasos anteriores. Si bien realizando estos pasos no
se resuelven los errores a la hora de realizar el make, es necesario ver
nota B.
2. Tras unos minutos, el proceso anterior habrá finalizado. Si todo ha ido
bien, y no hemos obtenido ningun mensaje de error en el terminal, pro-
cedemos a instalar la libreria:
> sudo make install
B.2.1.7. Paso 6
Configuramos nuestro sistema para localizar y enlazar las librerias de
OpenCV:
> echo /usr/local/opencv/lib >
/etc/ld.so.conf.d/opencv.conf
Actualizamos las librerias para asegurarnos que todo está correcto:
> ldconfig -v | grep opencv
Es posible que se muestren algunos mensajes de error de rutas a librerias.
No hay problema, salvo probablemente la última línea, que es la que vamos
buscando. Si aparece ena la consola “/usr/local/opencv/lib”, todo ha ido co-
rrectamente.
B.2.1.8. Paso 7
Configuramos el pkg-config y las variables de entorno, escribiendo los si-
guientes comandos en el terminal:
> echo ’export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:
/usr/local/opencv/lib/pkgconfig’ >> /etc/bash.bashrc
> echo ’export PYTHONPATH=
/usr/local/opencv/lib/python2.6/
site-packages/opencv’ >> /etc/bash.bashrc
La segunda línea es necesaria si se tiene pensado programar con Python. Si
no es el caso, se puede omitir dicha exportación. A continuación reiniciamos
el terminal para que todos los pasos de configuración sean actualizados.
B.2.1.9. Paso 8
En principio, si se ha llegado a este punto sin ningún error en el terminal, es
porque se ha instalado correctamente la libreria de OpenCV en el sistema. Para
verificarlo, accedemos al directorio donde hemos descomprimido la libreria
de OpenCV, y accedemos al subdirectorio samples/c, y autentificándonos de
nuevo como super-usuario, procedemos a ejecutar el siguiente comando en el
terminal:
> . build_all.sh
Si todo ha ido bien, la mayoria de los ejemplos se compilarán para obtener los
ejecutables en la carpeta OpenCV2.0.X/bin.
B.2.1.10. Paso 9
Este paso no es necesario para la instalación de la libreria en el sistema,
pero sí para la correcta compilación de cualquier ejemplo que se implemente
usando definiciones de la libreria OpenCV. Si optamos por compilar nuestros
fuentes haciendo uso de la herramienta make, para poder enlazar correcta-
mente las librerias de OpenCV será necesario establecer el formato de enlace
simbólico con las mismas en un archivo Makefile.
A modo de ejemplo, a continuación se expone el contenido de una archivo

Makefile que sirve para compilar un archivo fuente main.cpp, el cual contiene
llamada a funciones de OpenCV:
CC=g++
CFLAGS=-I. -Wall
LFLAGS=-lrt -lueye_api
DEPS = general.hpp Matrix.hpp CSensorCamara.hpp
main: main.cpp
$(CC) $(CFLAGS) $(LFLAGS) -ggdb ‘pkg-config --cflags opencv‘

main.cpp -o main ‘pkg-config --libs opencv ‘
En este ejemplo, se incluyen referencias a las siguientes librerias/archivos:
Libreria externa: -lueye_api
Librerias de definiciones: general.hpp, Matrix.hpp, CSensorCamara.hpp.

B.2.2. Configuración para Dev C++ en entornos Win-

dows
Los pasos aquí descritos son igualmente válidos tanto para la versión 2.0
como para la versión 2.1 de la librería de OpenCV.
B.2.2.1. Paso 0
Para instalar la librería de OpenCV es necesario acudir a la página donde
se encuentra en versión ejecutable el instalable de la versión 2.0:
https://sourceforge.net/projects/opencvlibrary/files/opencv-win/
2.0/
Una vez seguidos los pasos de instalación, se da por finalizado este paso
inicial.
B.2.2.2. Paso 1
Se inicia el compilador Dev C++, en cualquiera de sus versiones actuales.
Si no dispone del programa, se puede descargar del siguiente enlace web:
http://sourceforge.net/projects/dev-cpp/
Una vez finalizado este paso, se supone que el lector dispone del programa
Dev C++ correctamente instalado en su máquina y ejecutándose.
B.2.2.3. Paso 2
Se crea un nuevo proyecto, en el cual se pueden generar tantos archivos
fuente como sea necesario. Por ejemplo, se puede crear un archivo fuente
denominado main.cpp, cuyo código sea de prueba, como el mostrado a conti-
nuación:
#include ‘‘highgui.h”
#include ‘‘cv.h’’
int main( int argc, char** argv ) {
IplImage* img = cvLoadImage( argv[1] );
cvNamedWindow( ‘‘Example1”, CV_WINDOW_AUTOSIZE );
cvShowImage( “Example1”, img );
cvWaitKey(0);
cvReleaseImage( &img );
cvDestroyWindow( “Example1” );
}
El código anterior carga una imagen a partir de la ruta pasada como argumento
de llamada y la muestra en una ventana gráfica.
B.2.2.4. Paso 3
En este paso, se procede a la definición de un nuevo tipo de compilador en
Dev C++. En primer lugar:
Ir a “Tools” → “Compiler Options” , y crear un nuevo compilador,

presionando sobre la cruz verde de la parte derecha del cuadro, y lo
denominados por ejemplo “Compilador por Defecto”.
Figura B.2: Creación del nuevo compilador.
Posteriormente, seleccionamos la casilla "Add these commands to the

linker command line" (Figura B.2) y añadimos al recuadro lo siguien-
te(incluyendo el guión delante):
-llibcxcore200 -llibcv200 -llibcvaux200

-llibhighgui200 -llibml200 -llibfftw3-3
Nos vamos a la pestaña “Directories” y en la subpestaña “Binaries”

deben estar incluidas las siguientes opciones (pulsando la opción “Add”
para añadir nuevas) tal y como se muestra en la Figura B.3 :
> C:\OpenCV2.0\bin
> C:\Dev-Cpp\Bin
> C:\Dev-Cpp\libexec\gcc\mingw32\3.4.2
Figura B.3: Inclusión de rutas en Directories→Binaries.

En la pestaña Directories → Libraries deben estar incluidas las siguien-

tes rutas (Figura B.4):
> C:\OpenCV2.0\lib
> C:\Dev-Cpp\lib
Figura B.4: Inclusión de rutas en Directories→Libraries.

En la pestaña Directories → C includes deben estar incluidas las si-

guientes rutas (Figura B.5):
> C:\OpenCV2.0\include\opencv
> C:\Dev-Cpp\include
Figura B.5: Inclusión de rutas en Directories→C includes.

En la pestaña Directories → C++ includes deben estar incluidas las

siguientes rutas (Figura B.6):
> C:\OpenCV2.0\include\opencv
> C:\Dev-Cpp\lib\gcc\mingw32\3.4.2\include
> C:\Dev-Cpp\include\c++\3.4.2\backward
> C:\Dev-Cpp\include\c++\3.4.2\mingw32
> C:\Dev-Cpp\include\c++\3.4.2
> C:\Dev-Cpp\include
Figura B.6: Inclusión de rutas en Directories→C++ includes.
Pulsamos el botón OK y listo.

B.2.2.5. Paso 4
Todo lo necesario para poder compilar el proyecto ya está configurado.
Tan solo hace falta decirle al Dev C++ qué compilador queremos usar. Así,
cuando se vaya a compilar el proyecto, es necesario:
Sobre el nombre del proyecto (parte izquierda de la ventana) → Botón

derecho de ratón → “Project Options” .En la pestaña “Compiler”, selec-
cionar el compilador que generamos antes, el llamado “Compilador por
Defecto”.
Una última opción, no necesaria pero sí adecuada, es decirle a Dev C++ que
queremos que genere código optimizado. Para ello, en la misma ruta que el
anterior, seleccionamos “Compiler” y en “Further Optimizations”→”Best Op-
timizations” →”Yes” (Figura B.7).
Figura B.7: Optimización de código en Dev C++.

B.3. Características de la versión 2.1 209
B.2.2.6. Paso 5
Para que al compilar no se produzcan errores no deseados, es necesario

modificar una línea en un archivo fuente de OpenCV. Así pues:
En el directorio C:\ ...\include\opencv\ debe haber un fichero denomi-

nado: cxoperations.hpp.
Lo editamos, y buscamos en la línea número 67 del fichero anterior algo

similar a esto:
#include <bits/atomicity.h>
#if __GNUC__ >= 4
Localizada la línea, debemos sustituirla por ésta otra:
#include <bits/atomicity.h>
#if __GNUC__ >= 4 || __MINGW32__
B.3. Características de la versión 2.1

En la fecha de entrega del presente proyecto, se encuentra publicada la
versión 2.1 de la presente libreria. Además de la inclusión de nuevos algorit-
mos, y más optimizados, se incluye además un cambio a nivel de generación
de código para extraer el máximo rendimiento de las arquitecturas multime-
dia y multinúcleo para algoritmos de alto coste computacional. Uno de los
cambios más llamativos han sido las modificaciones en la interfaz para C++,
eliminando el prefijo cv del comienzo de los nombres de cada función.
Debido principalmente a falta de tiempo, no se ha profundizado en el

desarrollo con esta nueva versión de la libreria, aunque en lo referente a las
funciones utilizadas en las clases implementadas se comprueba que no han
sufrido proceso de mejora, por lo que es posible que no se obtenga una mejora
relativa en lo que respecta al rendimiento.
Par más información se refiere al lector a consultar el siguiente enlace web:
http://opencv.willowgarage.com/documentation/cpp/index.html.
Apéndice C
Interfaz de programación de la
cámara
A continuación se detallan las funciones utilizadas de la libreria de la cá-

mara [118].
Variables globales de la libreria de la cámara declaradas en el código de
las clases:
// Identificador de la Camara uEye

HIDS CamHandler;
// Identificador del buffer de memoria
uint32 CamBufferID;
// Puntero a buffer donde se guardan las imagenes
char* CamImagePointer;
// Información del sensor de la cámara
SENSORINFO sensorInfo;
Función de inicialización del dispositivo:
is_InitCamera (..)
Esta función acepta como parámetro de entrada el identificador de la

cámara en el sistema y un handler para una ventana de diálogo, que se
establece a nulo. La tarea de esta función es arrancar el driver y crear
la conexión. Puede devolver éxito en la inicialización o fracaso.
210
APÉNDICE C. INTERFAZ DE PROGRAMACIÓN DE LA CÁMARA 211
Función de configuración mediante archivo:
is_LoadParameters (CamHandler, ArchivoConfig)
Con esta función se inicializa la cámara con unos parámetros de con-

figuración presentes en ArchivoConfig, formateados debidamente, tales
como tasa de fps, activación del autocontraste (para adecuar el sensor a
las condiciones lumínicas de la escena), etc. Puede devolver éxito en la
configuración, o error.
Para obtener información del sensor:
is_GetSensorInfo (CamHandler, &sensorInfo);
Con esta función recuperamos el tamaño de la imagen en x e y, entre

otras cosas.
Activación del trigger de la cámara mediante evento externo:
is_SetExternalTrigger (CamHandler, IS_SET_TRIGGER_SOFTWARE)
Se establece la condición, con esta función, de que la cámara cada vez que
se llame a la función de captura devolverá la imagen recién capturada.
Además, para las condiciones de inicialización, si esta función desactiva
el trigger por software la cámara tarda en torno a 20 frames en adecuarse
a las condiciones lumínicas, mientras que con el trigger activado, tras
unos 5 frames ya se ha estabilizado el sensor. Puede devolver éxito en la
inicialización o fracaso.
Funciones de liberalización de memoria y del dispositivo de imagen:
is_FreeImageMem (CamHandler, CamImagePointer, CamBufferID);

is_ExitCamera (CamHandler);
Puede devolver éxito en la liberalización o fracaso.
Función para establecer el modo de captura de imagen:
is_SetColorMode (CamHandler, IS_CM_MONO8);

Se establece que el tipo de imagen capturada esté en escala de grises,

monocroma, de 8 bits de profundidad. Puede devolver éxito en la inicia-
lización o fracaso.
Conjunto de funciones para la reserva del buffer de memoria para las

imágenes capturadas:
is_AllocImageMem (CamHandler, ...);

is_SetImageMem (CamHandler, CamImagePointer, CamBufferID);
is_SetImageSize (CamHandler, dimX, dimY);
is_SetDisplayMode (CamHandler, IS_CM_MONO8);
Si tras la llamada a la primera función no se ha podido reservar memoria,

una macro de error derá devuelta, en cuyo caso debemos volver a intentar
la reserva. El resto de funciones son complementarias, y es necesario que
para la correcta configuración sean llamadas en el orden que se indica.
Pueden devolver éxito en la inicialización o fracaso.
Para obtener la imagen recién capturada del buffer de memoria de la

cámara se utiliza la función:
is_FreezeVideo (CamHandler, IS_WAIT)
Cada vez que esta función es llamada (1 vez por iteración del bucle) se
captura la imagen actual, con un retardo despreciable. La alternativa
a esta función se denomina is_CaptureVideo(), la cual según el manual
de la cámara sirve para realizar captura contínua, pero al transferir la
imagen al espacio de programa del usuario, el tiempo no es despreciable,
y los efectos, tal y como se explica en el capítulo 8, no son deseables.
Puede devolver éxito en la captura o fracaso.
Apéndice D
Diagrama temporal de Gantt.
214
mar 2010 abr 2010 may 2010 jun 2010 jul 2010 ago 2010 sep 2010
Id. Nombre de tarea Comienzo Fin
28/2 7/3 14/3 21/3 28/3 4/4 11/4 18/4 25/4 2/5 9/5 16/5 23/5 30/5 6/6 13/6 20/6 27/6 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9
1 Puesta en marcha 01/03/2010 25/03/2010
2 Lectura de artículos. 01/03/2010 15/03/2010
Configuración de la plataforma para

3 10/03/2010 25/03/2010
las primeras implementaciones.
Migración a la nueva plataforma de
4 desarrollo y primeras 29/03/2010 10/05/2010
aproximaciones.
5 Configuración de OpenCV 29/03/2010 02/04/2010
Asimilación de nuevos conceptos

6 05/04/2010 09/04/2010
teóricos.
7 Primeras implementaciones. 12/04/2010 19/04/2010
Lectura de manuales de
8 13/04/2010 20/04/2010
programación.
9 Primeros experimentos. 21/04/2010 27/04/2010
10 Deshecho del template matching. 27/04/2010 27/04/2010
11 Nuevas alternativas. 28/04/2010 30/04/2010
12 Comienzo con el tablero de ajedrez. 03/05/2010 10/05/2010
13 Desarrollo de la primera propuesta. 11/05/2010 15/06/2010
14 Análisis 11/05/2010 13/05/2010
15 Definición del problema. 13/05/2010 14/05/2010
16 Nuevos conceptos teóricos. 11/05/2010 10/06/2010
17 Primeras Implementaciones 17/05/2010 21/05/2010
18 Búsqueda de información. 19/05/2010 21/05/2010
19 Estudio de librería del sensor óptico. 21/05/2010 25/05/2010
20 Implementación. 25/05/2010 02/06/2010
21 Primeras pruebas. 02/06/2010 04/06/2010
22 Correcciones. 03/06/2010 07/06/2010
23 Primeros experimentos. 07/06/2010 11/06/2010
Estudio del manual de calibración de

24 20/05/2010 25/05/2010
la cámara.
25 Toma de imágenes para la calibración. 25/05/2010 28/05/2010
26 Comprobación de los resultados. 11/06/2010 11/06/2010
27 Experimentos con la plantilla. 11/06/2010 14/06/2010
28 Conclusiones. 15/06/2010 15/06/2010
29 Segunda propuesta. 17/06/2010 05/08/2010
30 Estudio de la teoría. 17/06/2010 21/06/2010
Primeras pruebas con

31 21/06/2010 25/06/2010
cvGoodFeaturesToTrack()
32 Primeras pruebas con flujo óptico. 28/06/2010 05/07/2010
33 Implementación. 05/07/2010 16/07/2010
Estudio e Implementación de la
34 descomposición de la matriz de 20/07/2010 30/07/2010
homografía.
35 Conclusiones. 02/08/2010 05/08/2010
36 Memoria 02/08/2010 17/09/2010
37 Recopilación de Información. 02/08/2010 30/08/2010
38 Redacción. 05/08/2010 10/09/2010
39 Corrección 10/09/2010 17/09/2010

Apéndice E
Diagrama de clases de la
aplicación
216
CActuador PrincipalQuadrotor CObservador
-GestorPic +datosSensor +AA
-Escalado +x +B
-Inicializado +u +C
+sensor +L
+CActuador()
+gestorPic +uk_1
+inicializa()
+actuador +yk_1
+actua()
+sensorAltura +Xk
+finaliza()
+Inicializado
+~CActuador() +main()
+leyDeControl() +CObservador()
+inicializa()
+actualizaEstado()
CGestorPic +finaliza()
-ControladorPuerto CSensor
-MedidaAltura +Hgc
-Inicializado +Inicializado
IntrinsicMatrix.xml
+CActuador () +CSensor()
+inicializa() +inicializa()
+actua() +verifica() DistortionCoeffs.xml
+finaliza() +finaliza()
+~CActuador() +leeDatos()
+~CSensor()
-fusionaDatos() ConfigHardware.ini
<<uses>>
<<uses>>
TMatrix
<<uses>>
TVector
CSensorImu CSensorCamara CSensorAltura

Librerias -Modo -CamHandler -GestorPic
comunes -Settings -CamBufferID -Altura
-RetrieveMode -CamImagePointer -Inicializado
-InterfazCmt3 -HayLecturaPrevia +CSensorAltura()
-Paquete -Inicializado +inicializa()
-DatosAnt -Img +leeDatos()
-ContadorErrorTimeOut -ImgColor +finaliza()
-ContadorErrorNoTimeOut -ParamDistorRadial
-ContadorOutliers -ParamDistorTangen
-ModoIntegracionVelocidadLineal -MatrizIntrinseca
-HayLecturaPrevia -Corners CSensorCamara1 CSensorCamara2
-Inicializado -DimX -Objeto -Objeto
-CmtCalDataAnt -DimY -PuntosImagen -H
-CmtOriQuatAnt -CoefsDistortion -PuntosImagenReproy -Mascara
+CSensorImu() -VectorRotacion -EigImg
-VectorTraslacion +verifica()
+inicializa() -calculaCalibracionExterna() -TempImg
+finaliza() -DatosAnt -ImgNext
-MatrizRotacion -muestraVisualizacion()
+verifica() -calculaHomografia() -PrevPyramid
+leeDatos() -K -Pyramid
+restauraFactoryDefaults() +CSensorCamara() -SwapTemp
+getContadorErrorTimeOut() +inicializa() -ImgPrev
+resetContadorErrorTimeOut() -inicializaModeloObjeto() -SwapCorners
+getContadorErrorNoTimeOut() +leeDatos() -ContadorInitCamara
+resetContadorErrorNoTimeOut() +finaliza() -numCaracteristicas
+getContadorOutliers() -finalizaModeloObjeto() -CornerCount
+resetContadorOutliers() -inicializaModeloCamara() -statusBuffer
+~CSensorImu() -finalizaModeloCamara() -trackError
-filtraOutliers() -inicializaDispositivoCamara() -BanderaEstado
-hardwareScan() -finalizaDispositivoCamara() -ObjetoSeleccionado
-doMtSettings() -PrimerFrameSeleccion
-seleccionInitCaracteristicas
<<uses>> <<uses>> -ModoImagen
+Tsg
-TrackingLK()
-decomposeHomography()
OpenCV Libreria Cámara

<<uses>> <<uses>>
*.so *.so *.a
homographyDecomposition.hpp seleccion.hpp
*.hpp
*.hpp
<<uses>>
<<uses>>
Bibliografía
[1] Jianhong Liang, Xusheng Lei, Song Wang, Yongliang Wu and Tianmiao
Wang. A Small Unmanned Aerial Vehicle for Polar Research. Procee-
dings of the IEEE International Conference on Automation and Logistics
Qingdao, China September 2008.
[2] Jovan D. Boskovic, Ravi Prasanth and Raman K. Mehra. A Multi-Layer

Control Architecture for Unmanned Aerial Vehicles. Proceedings of the
American Control Conference Anchorage, AK May 8-1 0,2002.
[3] Nicolas Guenard, Tarek Hamel, and Robert Mahony. A Practical Visual
Servo Control for an Unmanned Aerial Vehicle. IEEE Ttransactions on
robotics, vol. 24, no. 2, April 2008.
[4] Warren R. Dufrene, Jr. AI Techniques in Uninhabited Aerial Vehicle

Flight.
[5] Xusheng Lei, Jianhong Liang, Song Wang, Tianmiao Wang. An Inte-
grated Navigation System For A Small UAV Using Low-Cost Sensors.
Proceedings of the 2008 IEEE International Conference on Information
and Automation June 20 -23, 2008, Zhangjiajie, China.
[6] Tahir Hameed, Wang Wei Ren Zhang. Conceptual Designing – Unman-
ned Aerial Vehicle Flight Control System. The Ninth International Con-
ference on Electronic Measurement & Instruments.
[7] Nicolas Guenard, Tarek Hamel, Laurent Eck. Control Laws For The
Tele Operation Of An Unmanned Aerial Vehicle Known As An X4-
flyer. Proceedings of the 2006 IEEE/RSJ International Conference on
Intelligent Robots and Systems October 9 - 15, 2006, Beĳing, China.
[8] Peter W. Sarunic, Robin J. Evans. Control of Unmanned Aerial Vehicles

Performing Multiple Target Passive Detection and Tracking.
[9] Ondrej Spinka, Stepan Kroupa, Zdenek Hanzalek. Control System for
Unmanned Aerial Vehicles.
218
BIBLIOGRAFÍA 219
[10] Bhaskar Prasad Rimal, Hyoim Shin and Eunmi Choi. Simulation of
Nonlinear Identification and Control of Unmanned Aerial Vehicle: An
Artificial Neural Network Approach.
[11] Andon Topalov, Nikola Shakev, Severina Nikolova, Dobrin Seyzinski,

Okyay Kaynak. Trajectory Control of Unmanned Aerial Vehicle Using
Neural Nets with a Stable Learning Algorithm. 17th Mediterranean
Conference on Control & Automation Makedonia Palace, Thessaloni-
ki, Greece June 24 - 26, 2009.
[12] Warren R. Dufene, Jr., Graduate School of Computer and Information

Sciences, Nova Southeastem Universiy, Ft. Approach for autonomous
control of unmanned aerial vehicle using intelligent agents for knowledge
creation.
[13] Janne Heikkilä and Olli Silvén. A Four-step Camera Calibration Proce-
dure with Implicit Image Correction.
[14] J.-Y. Bouguet, ”Camera Calibration Toolbox for Matlab”, June 2008,
http://www.vision.caltech.edu/bouguetj/calibdoc/index.
html.
[15] B.Bishop, S.Hutchinson,M.Spong. Camera Modelling for Visual Servo

Control Applications.
[16] Ong Wei Ming Eugene. Ground Control Station for Unmanned Aerial
Vehicles.
[17] Odile Bourquardez, Robert Mahony, Tarek Hamel and François Chau-
mette. Stability and performance of image based visual servo control
using first order spherical image moments. Proceedings of the 2006
IEEE/RSJ International Conference on Intelligent Robots and Systems
October 9 - 15, 2006, Beĳing, China.
[18] Peter I. Corke, Seth A. Hutchinson. A New Hybrid Image-Based Vi-

sual Servo Control Scheme. Proceedings of the 39º IEEE Conference on
Decision and Control Sydney, Australia, December, 2000.
[19] Billibon H. Yoshimi and Peter K. Allen. Active, uncalibrated visual ser-
voing.
[20] Tarek Hamel, Robert Mahony. Image based visual servo control for a
class of aerial robotic systems.
BIBLIOGRAFÍA 220
[21] Alessandro Astolfi, Liu Hsu, Mariana S. Netto, and Romeo Ortega. Two
Solutions to the Adaptive Visual Servoing Problem. IEEE Transactions
on robotics and automation, vol. 18, no. 3, june 2002.
[22] Jian Chena, Darren M. Dawsonb, Warren E. Dixonc, Vilas K. Chitra-

karanb. Navigation function-based visual servo control.
[23] Ezio Malis and Patrick Rives. Uncalibrated Active Affine Reconstruction
closing the loop by Visual Servoing. Proceedings of the 2003 IEE/RSJ
Intl. Conference on Intelligent Robots and Sytems. Las Vegas, Nevada.
October 2003.
[24] François Chaumette, Ezio Malis. 2 1/2 D visual servoing: a possible

solution to improve image-based and position-based visual servoings.
Proceedings of the 2000 IEEE International Conference on Robotics &
Automation San Francisco, CA April 2000.
[25] Fransois-Xavier Espiau, Ezio Malis and Patrick Rives. Robust features
tracking for robotic applications: towards 21/2D visual servoing with
natural images. Proceedings of the 2002 IEEE International Conference
on Robotics & Automation Washington, DC May 2002.
[26] Ezio Malis. Tesis. 1998.
[27] Selim Benhimane, Ezio Malis. Homography-based 2D Visual Servoing.

Proceedings of the 2006 IEEE International Conference on Robotics and
Automation Orlando, Florida - May 2006.
[28] Christophe Collewet and François Chaumette. Positioning a Camera

With Respect to Planar Objects of Unknown Shape by Coupling 2-D
Visual Servoing and 3-D Estimations. IEEE Transactions on robotics
and automation, vol. 18, no. 3, june 2002.
[29] Andrew I. Comport, Eric Marchand, François Chaumette. Robust

model-based tracking for robot vision. Proceedings of 2004 IEE/RSJ
International Conference on intelligent Robots and Systems September
28 - October 2,2004, Sendai, Japan.
[30] Justin A. Borgstadt , Nicola J. Ferrier. Visual Servoing: Path Interpo-

lation by Homography Decomposition.
[31] Erdinç Altug, James P. Ostrwski, Robert Mahony. Control of a qua-

drotor Helicopter using Visual Feedback. Proceedings of the 2002 IEEE
International Conference on Robotics & Automation Washington, DC
May 2002.
BIBLIOGRAFÍA 221
[32] Nicholas Kottenstette. Constructive Non-Linear Control Design With

Applications to Quad-Rotor and Fixed-Wing Aircraft.
[33] Zhongshi Wang , Wei Wu , Xinhe Xu , Dingyu Xue. Recognition and lo-
cation of the internal corners of planar checkerboard calibration pattern
image.
[34] Hae YongKim. Rotation-discriminating template matching based on

Fourier coefficients of radial projections with robustness to scaling and
partial occlusion.
[35] Yi-Hsien Lin, Chin-Hsing Chen. Template matching using the parame-
tric template vector with translation, rotation and scale invariance.
[36] GRASP Laboratory. UAV’s Research Videos.

1: http://www.youtube.com/watch?v=icdb9ftdZOw
2: http://www.youtube.com/watch?v=MvRTALJp8DM
[37] Stanford University HUMMINGBIRD Aerospace Robotics Laboratory.

http://sun-valley.stanford.edu/~heli/
[38] Montgomery, J. F. (1999). Learning Helicopter Control Through ’tea-

ching by showing’. PhD thesis, University of Southern California, Los
Angeles, CA.
[39] Odile Bourquardez, Robert Mahony, Nicolas Guenard, François Chau-

mette, Tarek Hamel, and Laurent Eck. Image-Based Visual Servo Con-
trol of the Translation Kinematics of a Quadrotor Aerial Vehicle.
[40] Civita, M. L.. Integrated Modeling and Robust Control for Full- Enve-
lope Flight of Robotic Helicopters. PhD thesis, Carnegie Mellon Univer-
sity, Pittsburgh, PA. 2003.
[41] François Chaumette. Visual Servo Control II. Advanced Approaches.
[42] Seth Hutchinson, Gregory D. Hager and Peter I. Corke. A Tutorial on

Visual Servo Control. IEEE Transactions on robotics and automation,
vol. 12, no. 5, october 1996.
[43] G. Chesi, E. Malis and R. Cipolla. Automatic segmentation and mat-

ching of planar contours for visual servoing. Proceedings of the 2000
IEEE lntemational Conference on Robotics & Automation San Francis-
co. CA April 2000.
[44] BEAR: Berkeley Aerobot Team.

http://robotics.eecs.berkeley.edu/bear/
BIBLIOGRAFÍA 222
[45] Harris, C. and Stephens, M. 1988. A combined corner and edge detector.
In 4th Alvey Vision Conference. 147–151.
[46] Shim, H. Hierarchical Flight Control System Synthesis for Rotorcraft-

based Unmanned Aerial Vehicles. PhD thesis, University of California,
Berkeley. 2000.
[47] Amidi, O. An Autonomous Vision-Guided Helicopter. PhD thesis, Ro-

botics Institute, Carnegie Mellon University. 1996.
[48] Hrabar, S. E. Vision-Based 3D Navigation for an Autonomous Helicop-

ter. PhD thesis, University of Southern California. 2006.
[49] The Aerial Regional-scale Environmental Surveyor (Ares).

http://marsairplane.larc.nasa.gov/index.html
[50] Vincent Lepetit and Pascal Fua. Monocular Model-Based 3D Tracking

of Rigid Objects: A Survey.
[51] François Chaumette and Seth Hutchinson. Visual Servo Control Part I:
Basic Approaches.
[52] Guilherme Vianna Raffo. Tesis de Máster. 2007.
[53] Egan G.K. and Taylor B. Characterisation of Infrared Sensors for Ab-
solute Unmanned Aerial Vehicle Attitude Determination.
[54] Sentoso, F., Liu, M., and Egan, G.K.. Linear Quadratic Optimal Control
Synthesis for a UAV.
[55] A.K. Goodwin, G.K. Egan and F. Crusca. UAV Ridge Soaring in an
Unknown Environment.
[56] W.K. Kong, G.K. Egan and T. Cornall. Feature Based Navigation for
UAV’s.
[57] G.K. Egan, R.E. Cooper and B. Taylor. Unmanned Aerial Vehicle Re-
search at Monash University
[58] B. Taylor and G.K. Egan. Monash UAV Operations Manual .
[59] G.K. Egan and R.J. Cooper. An Unmanned Aerial Vehicle Autopilot.
[60] The Distributed Flight Array.

http://www.idsc.ethz.ch/Research_DAndrea/DFA
BIBLIOGRAFÍA 223
[61] Aerospace Controls Laboratory . UAV SWARM Health Management

Project.
http://vertol.mit.edu/videos.html
[62] Frédéric Jurie and Michel Dhome. Hyperplane Approximation for Tem-
plate Matching.
[63] David Suter, Tarek Hamel, Robert Mahony. Visual Servo Control using
homography estimation for the stabilization of an X4-flyer.
[64] E. Montĳano and C. Sagues. Fast Pose Estimation For Visual Navigation
Using Homographies. The 2009 IEEE/RSJ International Conference on
Intelligent Robots and Systems October 11-15, 2009 St. Louis, USA.
[65] Elan Dubrofsky. Homography Estimation.
[66] D. Santosh Kumar and C.V. Jawahar. Robust Homography-Based Con-
trol for Camera Positioning in Piecewise Planar Environments.
[67] Weibin Sun Xubo Yang Shuangjiu Xiao Wencong Hu. Robust Recogni-
tion of Checkerboard Pattern for Deformable Surface Matching in Mul-
tiple Views.
[68] Ezio Malis and Manuel Vargas. Effects of camera-calibration errors on
the homography decomposition.
[69] University of Southern California. Autonomous Flying Vehicle Project.
http://robotics.usc.edu/~avatar/images.htm
[70] John T. Feddema, C. S . George Lee and Owen Robert Mitchell. Weigh-
ted Selection of Image Features for Resolved Rate Visual Feedback Con-
trol. IEEE Transactions on robotics and automation, vol. 1, no. i , fe-
bruary 1991.
[71] Grégory Flandin François Chaumette Eric Marchand. Eye-in-hand /
Eye-to-hand Cooperation for Visual Servoing.
[72] Roger y. Tsai and Reimar k. Lenz. A New Technique for Fully Autono-
mous and Efficient 3D Robotics Hand/Eye Calibration.
[73] Brad Nelson, Pradeep K. Khosla. Integrating Sensor Placement and Vi-
sual Tracking Strategies.
[74] Nikolaos P. Papanikolopoulos,Pradeep K . Khosla and Takeo Kanade.
Visual Tracking of a Moving Target by a Camera Mounted on a Robot:
A Combination of Control and Vision. IEEE Transactions on robotics
and automation. vol. 9, no. I , february 1993.
BIBLIOGRAFÍA 224
[75] Hill, J., and Park, W.T. Real Time Control of a Robot with a Mobile
Camera. Proceedings of the 9th ISIR , Washingtong DC, March, pp.
233-246, 1979.
[76] Grasp Laboratory:

http://www.grasp.upenn.edu/
[77] Monash University:

http://www.ctie.monash.edu.au/AEROBOTICS/
[78] Lamiroy, B., Espiau, B., Andreff, N., and Horaud, R. Controlling Robots
with Two Cameras: How to Do Properly. Proc. IEEE/RSJ Int. Conf. on
Robotics and Automation, pp. 2100-2105, 2000.
[79] Lamiroy, B. Puget, C. Horaud, R. What Metric Stereo Can Do for Visual
Servoing. Proceedings of the 2000 IEEE/RSJ Int. Conf. On Intelligent
Robots and Systems, pp. 251-256, 2000.
[80] Namiki, A., Hashimoto, K., and Ishikawa, M. A Hierarchical Control

Architecture for High-Speed Visual Servoing. International Journal of
Robotics Research, vol. 22, No 10-11, pp. 873-888, 2003.
[81] Lippiello, V., Siciliano, B. and Villani, L. Position and Orientation Esti-
mation Based on Kalman Filtering of Stereo Images. Proceedings of the
2001 IEEE International Conference on Control Applications, Mexico
City, September 5-7, 2001.
[82] Deng, L., Janabi-Sharifi, F., and Wilson, W.J. Stability and Robustness
of Visual Servoing Methods. Proceedings of the 2002 IEEE International
Conference on Robotics and Automation, Washington, DC, May, 2002.
[83] Chaumette, F. Potencial Problems of Stability and Convergence in

Image-Based and Position-Based Visual Servoing. The Confluence of
Vision and Control.
[84] Martin, F., and Horaud, R. Múltiple-camera tracking of Rigid objects.

International Journal of Robotics Research. Vol. 21, No. 2, pp. 97-113.
[85] Espiau, B. Effect of Camera Calibration Errors on Visual Servoing in Ro-

botics. 3rd. International Symposium on Experimental Robotics, Kyoto,
Japan, October 1993.
[86] Jagersand, M., Nelson, R. and Fuentes, O. Experimental Evaluation of

Uncalibrated Visual Servoing for Precision Manipulation. Proceedings
of Int. Conf. Robotics & Automation, 1997.
BIBLIOGRAFÍA 225
[87] Iwatsuki, M., and Okiyama, N. A New Formulation of Visual Servoing

Based on Cylindrical Coordinate System. IEEE Trans. Robot. Auto-
mat., vol 21, Nº 2, pp. 266-273, April, 2005.
[88] Mezouar, Y., and Chaumette, F. Path Planning in Image Space for Ro-
bust Visual Servoing. Proceedings of the 2000 IEEE International Con-
ference on Robotics and Automation, San Francisco, CA. April, 2000.
[89] Malis, E., Chaumette, F., and Boudet, S. 2½D Visual Servoing. IEEE
Trans. on Robotics and Automation, 15(2), pp. 234-246, 1999.
[90] Fang, Y., Behal, A., Dixon, W.E., and Dawson, D.M. Adaptive 2.5D Vi-
sual Servoing of Kinematically Redundant Robots Manipulators. Pro-
ceedings of the 41st IEEE Conference on Decision and Control, Las
Vegas, Nevada USA, 2002.
[91] Deguchi, K. Optimal motion Control for Image-Based Visual Servoing

by Decoupling Traslation and Rotation. Proccedings of the IEEE/RSJ
Int. Conf. on Intelligent Robots and Systems, Victoria, B.C. Canada,
1998.
[92] Hutchinson, S., and Gans, N. Switching Approaches to Visual Servo

Control. Proceedings IEEE Int. Symposium, 27-30 October, 2002.
[93] Hafez, A.H.A, and Jawahar C.V. Visual Servoing by Optimization of a

2D/3D Hybrid Objective Function. Proceedings of the 2007 IEEE Int.
Conf. on Robotics and Automation, Roma, Italy, 10-14 April, 2007 .
[94] Corke, P.I., and Hutchinson, S.A., A New Partitioned Approach to

Image-Based Visual Servo Control. IEEE Transaction on Robotics and
Automation, Vol. 17, No 4, August, 2001.
[95] Cretual, A, and Chaumette, F. Positioning a Camera Parallel to a Plane

Using Dynamic Visual Servoing. IEEE Int. Conf. On Intelligent Robots
and Systems, Vol. 1, pp. 43-48, Grenoble, France, 1997.
[96] Colombo, C. Allota, B., and Darío, P. Affine Visual Servoing: A Frame-
work for Relative Positioning with a Robot. Int. Conf. on Robotics and
Automation, pp. 464-471, Nagoya, Japan, 1995.
[97] Wĳesoma, S., Wolfe, D., and Richards, R. Eye-to-Hand Coordination

for Vision-Guided Robot Control Applications. International Journal
on Robotics Research, vol. 12, No 1, pp.65-68, 1993.
BIBLIOGRAFÍA 226
[98] Papanikolopoulos, N.P., Khosla, P.K., and Kanade, T. Visual Tracking

of a Moving Target by a Camera Mounted on a Robot: A Combination
of Vision and Control. IEEE Transactions on Robotics and Automation,
vol 9, pp. 14-35, 1993.
[99] Malis, E. Survey of Vision-Based Robot Control. ENSIETA European
Naval Ship Design Short Course, Brest, France, April, 2002.
[100] Suh, I. Visual Servoing of Robot Manipulators by Fuzzy Membership
Function Based Neural Networks. K. Hashimoto editor, Visual Servoing,
pp. 285-315, World Scientific, Singapore, 1993.
[101] Mezouar, Y., and Chaumette, F. Optimal Camera Trajectory with
Image-Based Control. International Journal of Robotics and Research.
Vol. 22, No 10-11, pp. 781-803, October-November 2003.
[102] Sequeira, P.J., Mendonca, L.F., Sousa, J., and Caldas, J.R. Uncalibra-
ted Eye-to-Hand Visual Servoing Using Inverse Fuzzy Models. IEEE
Transactions on Fuzzy Systems, to appear, 2007.
[103] Dementhon, D., and Davis, D.S. Model-Based Object Pose in 25 Lines
of Code. International Journal of Computer Vision, 15(1/2), pp. 123-
141, 1995.
[104] Pari, L., Sebastián, J.M., González, C., and Angel, L. Image Based Vi-
sual Servoing: a New Method for the Estimation of the Image Jacobian
in Dynamic Environments.
[105] Kragic, D., and Christensen, H. Cue Integration for Visual Servoing.
IEEE Transactions on Robotics and Automation, vol. 17, Nº 1, February,
2001.
[106] Grosso, E., Metta, G., Oddera, A., and Sandini, G. Robust Visual Ser-
voing in 3-D Reaching Tasks. IEEE Transsactions on Robotics and Au-
tomation, 12(5): 732-742, October 1996.
[107] Wilson, W., Hull, C.W., and Janabi-Sharifi, F. Robust Image Processing
and Position-Based Visual Servoing. M. Vincze & Hager Ed. “Robust
vision for manipulation”. Spie/IEEE Series, pp. 163-220, 2000.
[108] Malis, E. Theoretical Improvements in the Stability Analysis of a New
Class of Model-Free Visual Servoing Methods. IEEE Transactions on
Robotics and Automation, Vol. 18, No 2, 2002.
[109] Anderson, R.L. Dynamic Sensing in a Ping-Pong Playing Robot. IEEE
Trans. Robotics and Automation, 5(6):723-739, 1989.
BIBLIOGRAFÍA 227
[110] Espiau, B., Chaumette, F. and Rives, P. A New Approach to Visual

Servoing in Robotics. IEEE Transactions on Robotics and Automation,
Vol. 8, No 3, 1992 .
[111] Eric Beets, Samia Boukir, and David Suter. Aircraft Pose Estimation
from Homography.
[112] Bourquardez, O., and Chaumette, F. Visual Servoing of an Airplane
for Alignment with Respect to a Runway. Proceeding of the 2007 IEEE
International Conference on Robotics and Automation, Roma, April 10-
14 2007.
[113] Namiki, A., Nakabo, Y., Ishii, I., and Ishikawa, M. 1-ms Sensory-Motor
Fusion System. IEEE/ASME Transactions on Mechatronics, vol. 5, No
3, September 2000.
[114] Moravec, H. 1979. Visual mapping by a robot rover. In Proceedings
of the International Joint Conference on Artificial Intelligence (ĲCAI).
598–600.
[115] Lowe, D. 2004. Distinctive image features from scale-invariant keypoints.
Int. J. Comput. Vision 60, 2, 91–110.
[116] Mikolajczyk, K. and Schmid, C. 2003. A performance evaluation of lo-
cal descriptors. In IEEE Conference on Computer Vision and Pattern
Recognition (CVPR). 1615–1630.
[117] Bruce D. Lucas and Takeo Kanade. An iterative image registration te-
chnique with an application to stereo vision. In Proc. of Imaging Un-
derstanding Workshop, pages 121{130, 1981}.
[118] Manual for uEye Cameras Version 3.50.00. October 2009.
[119] Cool LiteRunner-ECO PC/104 Carrier for CoreExpress® Technical Ma-
nual.
http://www.lippertembedded.com/
[120] G. Bradsky and A. Kaelher, ”Learning OpenCV. Computer Vision with
the OpenCV Library”, O’Reilly, 2008.
[121] Autonomous Helicopter Project, Carnegie Mellon University.
http://www.cs.cmu.edu/afs/cs/project/chopper/www/history.
html
[122] N. Andreff, R. Horaud and B. Espiau, ”Robot Hand-Eye Calibration
Using Structure from- Motion”, The International Journal of Robotics
Research, Vol. 20, No. 3, pp.228-248, 2001.
BIBLIOGRAFÍA 228
[123] Ezio Malis and Manuel Vargas. Deeper understanding of the homo-
graphy decomposition for vision-based control.
[124] Georgia Institute of Technology.

http://www.gatech.edu/
[125] Open Tracking Library:

http://www.opentl.org/.
[126] Weyns - A Pattern Language for Multi-Agent Systems, Danny Weins,

DistriNet Labs,2009.
[127] Craparo - Natural Language Processing for Unmanned Aerial Vehicle

Guidance Interfaces, Emily M.Craparo, MIT,2002.
[128] California Institute of Technology.

http://www.caltech.edu/
[129] Fusión Sensorial imu-Cámara. Manuel Vargas, Junio 2010.
[130] B.N.Passow, M.A.Gongora, S.Coupland, A.A.Hopgood, Real-time Evo-

lution of an Embedded Controller for an Autonomous Helicopter, Proc.
of the IEEE Congress on Evolutionary Computation, WCCI’08, Hong
Kong, 2008.
http://www.youtube.com/watch?v=JiyCXF6cnpQ
BIBLIOGRAFÍA 229

Tesis de Grado Realimentacion Visual Par

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis de Grado Realimentacion Visual Par

Cargado por

Copyright:

Formatos disponibles

Proyeecto Final de Carreraa presentaado en:

A Marta, mi novia, y mi familia, por su incomensurable paciencia.

A Rafa y Ramón, entre otros, compañeros del Departamento de Ingeniería

Y en especial a Manuel Vargas, profesor del Dpto., por haber confiado en mí

Gracias por haber estado siempre ahí.

El contexto en el que se desarrolla este proyecto es en el del

2. Estado del arte del control de plataformas UAV 11

3. Técnicas de control con realimentación visual 21

4. Localización y seguimiento del objeto de referencia 39

4.4.2. Métodos de detección no basados en puntos . . . . . . 52

5. Sensor óptico: modelado y proceso de calibración 61

6. Implementación de mecanismos para la extracción de infor-

7. Fusión sensorial 151

8. Hardware y modelado del helicóptero Quadrotor 171

9. Trabajos futuros y conclusión 184

A. Código desarrollado 194

C. Interfaz de programación de la cámara 210

D. Diagrama temporal de Gantt. 214

E. Diagrama de clases de la aplicación 216

1.1. Ejemplo de esquema del diagrama de bloques para la estimación

2.1. Ejemplo de rotor de una sola aspa. . . . . . . . . . . . . . . . 12

3.1. Ejemplo de cámara en mano. . . . . . . . . . . . . . . . . . . 22

3.12. Ejemplo de detección de líneas en entornos urbanos. . . . . . . 37

4.1. Objeto de referencia utilizado en el presente proyecto. . . . . . 40

5.1. Modelo pinhole de la cámara. . . . . . . . . . . . . . . . . . . 62

5.18. Situación de los puntos antes de realizar la corrección manual. 85

6.1. Ejemplo de realidad aumentada. . . . . . . . . . . . . . . . . . 93

6.28. Ejemplo de la técnica template matching. Se desplaza la plan-

7.1. Detalle externo del sensor inercial. . . . . . . . . . . . . . . . . 152

8.1. Esquema básico de funcionamiento del quadrotor. . . . . . . . 172

9.1. Obtención del controlador de vuelo mediante algoritmos gené-

B.1. Lista de servidores de versiones . . . . . . . . . . . . . . . . . 197

B.3. Inclusión de rutas en Directories→Binaries. . . . . . . . . . . 204

La visión para el control de un UAV implica realizar un proceso de in-

Un helicóptero autónomo posee propiedades que lo convierten en la plata-

Dichas habilidades son particularmente útiles en entornos conocidos y es-

La realización de tareas por parte de sistemas automatizados o robotizados

La utilización de un sistema de visión en la realización de una tarea por

Figura 1.1: Ejemplo de esquema del diagrama de bloques para la estimación

Los primeros estudios [70][74][75] aplicados sobre todo a procesos indus-

La ventaja de este tipo de control es su simplicidad, siendo ésta una de

en los que la tarea a realizar esté determinada y no varíe (como es el caso de

Otro aspecto importante es el número de cámaras utilizadas. En función

La propuesta presentada en esta memoria combina principalmente técnicas

1.2. Problemas en el control visual de vehícu-

Figura 1.2: Sistema de sujeción del UAV para experimentos.

El problema del control visual sobre robots terrestres es un tema que ha

Si pensamos además en que la capacidad de cómputo del sistema on-board

La visión en humanos es considerada eficiente en su interpretación y un

Aunque se haya evolucionado mucho en el tema, y la extracción de infor-

Configuración del hardware apropiado para acometer la tarea del

Algoritmos de detección y seguimiento de características :

Desarrollo del controlador adecuado :

1.3. Objetivos y propuestas

En este proyecto se aborda el problema del control visual partiendo de la

Usando técnicas desarrolladas en posteriores capítulos, se espera que el

La propuesta de control visual (que se verán en detalle en el capítulo 3)

Se aborda el problema gracias a que se desacopla el control a bajo nivel

Prácticamente la mayor parte del código desarrollado ha sido implementa-

1.4. Estructura del proyecto

Dado que en el presente proyecto se han mezclado temáticas de muy diver-

En una sola frase, se han mezclado conceptos de procesamiento digital de

La presente memoria queda estructurada como sigue:

En el capítulo 2 se describe brevemente el estado del arte del control de