Informe Aguado Emder

Facultad de Ingeniería
Departamento de Electrónica y Automática
Temas Específicos de Control 1: Visión Artificial
DETECCIÓN DE PERSONAS PARA UN ROBOT

TURTLEBOT USANDO OPENCV
Alumnos:
Pablo Aguado – 23724 – aguadopd@hotmail.com
Fabricio Emder – 23764 – elector102@gmail.com
Profesor:
Adrián Orellana - orellana@inaut.unsj.edu.ar
Abril – 2016
Índice
Índice
1. Introducción 3
2. Objetivos 3
3. Con qué se trabajó 3

3.1. ¿Qué es un TurtleBot? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. ¿Qué es un Microsoft Kinect? . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. ¿Qué es una Raspberry PI 2? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Cámara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. ¿Qué es ROS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Alternativas iniciales 7
4.1. Desarrollo de un detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Detectores integrados en OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. OpenNI Tracker de ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Skeltrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Human Tracker de ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. OpenPTrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Algoritmos evaluados 10
5.1. HOG + SVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Entrenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Cascada de clasificadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. Entrenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.3. Haar-like features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.4. LBP features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2.5. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Preprocesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Escalado inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Transformación a escala de grises . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.3. Ecualización de histograma . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.4. Filtrado por convolución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Postprocesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4.1. Estimación de la altura real . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Pruebas 18
6.1. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. Igualdad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.2. Medidas básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.3. Medidas a optimizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Sets de imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4. Parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4.1. HOG + SVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4.2. LBP + Cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Implementación 22
7.1. Conceptos generales de ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2. Información desde el TurtleBot . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3. Información desde la Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.4. Información desde una PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.5. Nodo de detección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1
Índice
8. Resultados 24
8.1. Pruebas y ajuste de parámetros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1.1. HOG + SVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1.2. LBP + Cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Pruebas con los mejores parámetros . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Pruebas sobre el set de validación . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.4. Implementaciones en línea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Conclusiones 27
9.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Mejoras al trabajo realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Mejores alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.4. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Referencias 32
A. Apéndice: Estructura de archivos 35
B. Apéndice: Nodos 36
2
1. Introducción
1. Introducción
Este es el informe del trabajo integrador final de la materia Temas Específicos de Control
I: Visión Artificial, dictada en la carrera Ingeniería Electrónica de la Universidad Nacional de
San Juan. La consigna es llevar a cabo un proyecto que en el se apliquen todos los conocimientos
adquiridos en la materia, asimilándolos con práctica y complementándolos con más conceptos.
Se planteó como objetivo principal del proyecto realizar la detección de personas desde un robot
móvil con un grado aceptable de aciertos. Para ello se probaron la eficiencia y eficacia de distintos
algoritmos que fueron implementados en OpenCV sobre un robot TurtleBot, equipado con
una cámara RGB+D Microsoft Kinect y trabajando bajo el sistema ROS (Robot Operative
System). El programa desarrollado fue luego adaptado para poder utilizarse en otras cámaras sin
información de profundidad, como una webcam de una PC o una mini-computadora Raspberry
Pi 2 con cámara.
El informe se extiende sobre algunas alternativas de trabajo, conceptos de los detectores utili-
zados y también sobre ROS, ya que fue una herramienta de uso constante. Se abordan también
las pruebas realizadas, su evaluación e interpretación, terminando con algunas conclusiones ob-
tenidas y posibles mejoras.1
2. Objetivos
El detector de personas a implementar intenta satisfacer las siguientes especificaciones:
1. Funciona en línea.
2. Detecta personas adultas
a) en posición vertical, ya sea caminando o paradas;
b) a una distancia mayor a 1 metros y menor a 7 metros.2
3. Funciona bajo condiciones normales de iluminación, entendiendo como normal el nivel de
iluminación presente en entornos cerrados donde personas circulen y/o realicen trabajos
manuales — es decir, oficinas, fábricas, laboratorios, etc.
4. Funciona bajo ROS sobre un robot TurtleBot (versión 1).
3. Con qué se trabajó

El TurtleBot trabaja bajo el sistema ROS (Robot Operating System), por lo cual la im-
plementación final deberá ser compatible con ROS. Durante el desarrollo de este trabajo tam-
bién se probó el sistema utilizando webcams de computadoras personales y también una mini-
computadora Raspberry Pi con una cámara SCI externa.
3.1. ¿Qué es un TurtleBot?

TurtleBot es un kit de robótica de bajo costo construido a partir de electrónica de consumo,
por lo que se puede replicar de forma sencilla. Es capaz de recorrer interiores con una decente
autonomía de batería y con funciones de visión tridimensional. Se le pueden sumar accesorios
para añadir funcionalidad.
El TurtleBot esta compuesto por:
Base móvil IRobot Create. [1]
Netbook Asus 1215N. [2]
Controlador Microsoft Kinect. [3] Está montado a 30 cm del suelo.
1 El código fuente de todos los programas, los sets de imágenes utilizados y
los resultados obtenidos, pueden descargarse desde https://github.com/GERUNSJ/
deteccion-de-personas-con-turtlebot-y-opencv-1
2 Originalmente el rango planteado fue de 1 a 5 metros, pero fue extendido en vista de las posibilidades de los
detectores.
3
Figura 1: Turtlebot 1
Estructura de madera y aluminio para llevar la netbook, el controlador Kinect y accesorios

que se agreguen.
3.2. ¿Qué es un Microsoft Kinect?

Es un controlador de juego y entrenamiento desarrollado por Microsoft (en adelante será
referido como el [controlador] Kinect o como la [cámara] Kinect). [4, 3, 5] El dispositivo
permite al usuario de una consola de videojuegos Xbox o una PC interactuar con juegos o
programas sin tener contacto físico con un controlador. Algunos de los componentes principales
de la versión utilizada, Kinect for Xbox 360 o Kinect v1:
Cámara RGB
Formato VGA (640 ∗ 480 px)
Resolucion 8 bits
Tasa 30 cuadros por segundo
Campo de visión 62,7 ° horizontal
Distancia focal 525 píxeles
Cámara infrarroja
Formato VGA (640 ∗ 480 px)
Resolucion 11 bits
Tasa 30 cuadros por segundo
Campo de visión 57,8 ° horizontal
Distancia focal 580 píxeles
Proyector láser infrarrojo con una matriz de difracción
Es importante notar que la Kinect está diseñada para trabajar en interiores. La presencia
de fuentes de luz infrarroja significa una disminución del rango útil de detección e
incluso puede llegar a hacerla totalmente imposible.
4
Figura 2: Sensor Kinect
(a) (b)
Figura 3: Patrón de puntos proyectado — Luz estructurada.

Obsérvese que la imagen está dividida como una matriz de 3x3 regiones, y cada una
tiene un punto brillante en su centro. Se cree que esto sirve para una orientación rápida
del sistema.
3.2.1. Funcionamiento
Para la obtención de la imagen de profundidad o mapa de profundidad no se utiliza la infor-
mación de la cámara RGB, si no que un proyector láser infrarrojo con una matriz de difracción
constante proyecta un patrón de puntos que luego es captado por la cámara infrarroja. Ver Fi-
gura 3.
Se conoce a priori cuál es la visualización del patrón ante una superficie plana a una distancia
determinada. Para conocer la profundidad de los objetos en la imagen se procede a correlacionar
cada porción del patrón observado contra todo el patrón conocido; al encontrar la coincidencia
se mide el desfasaje o disparidad, y a partir de esto y por triangulación se calcula la distancia
real de la porción en cuestión.3 [6, 7, 8, 9, 10, 11, 5, 12]
La imagen de profundidad es una imagen de un solo canal cuyos valores corresponden a dis-
tancias (en mm desde la cámara) y es transmitida como una imagen de 16 bits, pero sólo los
11 bits menos significativos son útiles. La distancia de trabajo efectiva del sensor Kinect v1 es
desde 0, 8 m a 3, 5 m, con un error de 1 cm en profundidad y de hasta 3 mm en las mediciones
de ancho y alto.
3 Elmodo real de funcionamiento no ha sido explícitamente publicado, y mucha de esta información está basada
en ingeniería inversa, análisis de expertos y patentes de la empresa PrimeSense, desarrolladora del System On
a Chip PS1080, encargado de todo el procesamiento de imágen y audio de la Kinect. Un interesante análisis
en español de la Kinect se encuentra en el Apéndice A de [5].
5
Figura 4: Modelo geométrico de las cámaras de la Kinect
3.3. ¿Qué es una Raspberry PI 2?

Raspberry PI es una serie de computadoras de placa única (Single Board Computer, SBC ),
las cuales incluyen todo en una misma placa y son del tamaño de una tarjeta de crédito. En este
proyecto se usó la Raspberry Pi 2 versión B [13], cuyas características principales son:
Procesador Quad core ARM Cortex-A7 de 900mhz
1GB de memoria RAM
17 GPIO - salida HDMI - 4 puertos USB - Ethernet
Puerto SCI para cámara.
3.3.1. Cámara
La cámara conectada a la Raspberry Pi tiene las siguientes especificaciones:
Sensor OmniVision OV5647
Formatos QVGA (320 ∗ 240 px) @ 120 FPS, VGA (640 ∗ 480 px) @ 90 FPS, 720P @ 60 FPS,
960P @ 45 FPS, 1080 @ 30 FPS, QSXGA (2592 ∗ 1944 px) @ 15 FPS
Figura 5: Imágenes de profundidad de la Kinect
(a) Original, convertida a 8 bits (b) Normalizada, convertida a 8 bits
6
4. Alternativas iniciales
Resolucion 8-/10 bits
Lente LS-2716CS
Campo de visión 81 ° horizontal
Distancia focal 4 mm
Interfaz SCI
Figura 6: Raspberry Pi 2 y cámara
3.4. ¿Qué es ROS?

A pesar de su nombre (Robot Operating System, Sistema Operativo Robótico o Sistema Opera-
tivo de Robots), no se puede decir que ROS [14, 15] sea un sistema operativo (SO) propiamente
dicho, ya que la funcionalidad de este depende de un SO base, como pueden ser : OS X, An-
droid, Windows y distintas distribuciones de Linux/UNIX — la más difundida y soportada
es Ubuntu. Se puede entonces definir a ROS como un framework (entorno de trabajo) flexible
para el desarrollo de software para robots, que provee funcionalidades de un SO en un cluster
heterogéneo. Está conformado por una colección de herramientas, bibliotecas y convenciones que
tienden a simplificar la creación de funciones robóticas complejas. ROS es de código abierto al
igual que OpenCV, lo cual, en conjunto con sus herramientas y estandarización, ha permitido un
gran crecimiento de la comunidad involucrada en robótica, facilitando y motivando el desarrollo
colaborativo.
En base a las herramientas disponibles y a los objetivos buscados, las siguientes alternativas
iniciales fueron contempladas:
4.1. Desarrollo de un detector

Desarrollo desde cero de un detector utilizando funciones básicas de OpenCV (Open Computer
Vision library)[16]. Este enfoque, iniciado y luego descartado, permitió un mejor entendimiento
del problema, a través de la búsqueda creativa de patrones y características de las imágenes que
aportaran información útil para distinguir a una persona — e incluso implicó explorar cuál es la
definición de persona, desde un punto de vista visual. El algoritmo desarrollado consistió4 en:
4 Sólo se trabajó con la imagen de profundidad.
7
1. Segmentación según el histograma de intensidad de la imagen de profundidad.

a) Generación del histograma.
b) Suavizado del histograma con varias etapas de filtros promediadores. Así se elimina
ruido y se agrupan los segmentos que están cercanos en el histograma y probablemente
corresponden al mismo objeto.
c) Búsqueda de máximos y mínimos locales del histograma.
d) Segmentación del histograma. Cada segmento corresponde a los valores de intensidad
que se encuentran entre dos mínimos consecutivos.
e) Segmentación de la imagen según los segmentos de histograma, a través de look-up
tables.
f ) Mayor segmentación de cada segmento, separando los distintos objetos que se encuen-
tran a la misma profundidad.
1) Operaciones morfológicas: etapas de apertura y cierre para eliminar bloques pe-
queños y rellenar “agujeros”.
2) Búsqueda de contornos y segmentación por contornos.
2. Filtrado por relación de aspecto.
a) Creación de rectángulo contenedor de cada contorno.
b) Cálculo de relación de aspecto y eliminación si no es similar al de una persona de pie.
c) Filtrado según la altura real estimada.
1) Estimamos la altura real del objeto a partir de la distancia respecto de la cámara,
la altura en píxeles del objeto y la distancia focal de la cámara. Ver 5.4.1.
2) Eliminación si es mayor o menor a límites de altura prefijados.
3. Filtrado según la dispersión del gradiente.
a) Cálculo de gradientes horizontales con kernel simple [−1, 0, 1], en cada zona de interés.
b) Separación en gradientes positivos y negativos.
c) Cálculo de la dispersión de los valores de gradiente.
d) Filtrado bajo la suposición de que dispersiones pequeñas implican superficies con
caras planas (eliminando así muchas mesas y sillas), mientras que dispersiones grandes
corresponden a una, cuya superficie tiene muchas irregularidades.
El proceso de segmentación y filtrado fue satisfactorio en el corto rango en que la persona se

veía completa y se veía en la imagen de profundidad — aproximadamente desde los 3 a los
4 metros desde el robot. Además de este limitado rango, las estrategias de filtrado no fueron
capaces de eliminar grandes porciones de paredes y objetos de contornos similares a los de una
persona. El filtrado por dispersión de gradiente fue probado satisfactoriamente en Matlab pero
no implementado en OpenCV; las pocas pruebas realizadas sugieren que la idea es válida siempre
y cuando haya suficiente información de profundidad. El desarrollo no fue continuado debido a
los resultados mucho más prometedores de parte de los detectores en cascada.
4.2. Detectores integrados en OpenCV

Utilización de un detector integrado en OpenCV — sin aprovechar la información existente
en las imágenes de profundidad. La biblioteca OpenCV incluye, dentro del módulo objdetect,
a los siguientes detectores:
Detector en cascada Cascada de clasificadores de complejidad en incremento, utilizando carac-
terísticas (features) tipo Haar o patrones binarios locales (Linear Binary Patterns, LBP).
[17, 18, 19]
8
Detector HOG Clasificador tipo máquina de vectores soporte (Support Vector Machine, SVM ),
utilizando como vector de características a un histograma de gradientes orientados (His-
togram of Oriented Gradients, HOG). [20, 21]5
Latent SVM Detector basado en modelos de partes deformables; usa HOG para detectar las
partes. Este sistema fue desechado porque es muy lento6 y tiene poca precisión7 , comparado
con los anteriormente nombrados. [22, 23]
Esta es la opción elegida para mayor desarrollo. Implicó profundizar el conocimiento en la biblio-
teca OpenCV, que fue la utilizada durante el cursado de la materia, y además conocer conceptos
de detectores estándar de personas (u otros objetos), como lo son los detectores en cascada y
los detectores HOG. Como se verá en las secciones siguientes, se añadió además información de
profundidad para mejorar la precisión de los detectores, pero el corto rango útil de esta perjudica
a los resultados en lugar de mejorarlos.
4.3. OpenNI Tracker de ROS

Utilizar el paquete OpenNI Tracker de ROS [24], que publica (ver conceptos de ROS en
7.1) las coordenadas de las extremidades de las personas que detecta. Utiliza OpenNI8 y el
módulo NITE9 para hacer la detección, segmentación y seguimiento. El proyecto fue adquirido
por Apple y discontinuado; la documentación remanente es escasa. Las versiones de NITE
existentes al comenzar este trabajo requerían que los usuarios se colocaran en una posición
predeterminada para detectarlos y comenzar a seguirlos. Versiones posteriores permitían usar un
archivo de configuración pre-guardado para el usuario, mientras que las últimas son capaces de
iniciar el seguimiento desde cualquier posición.
Esta posibilidad fue evaluada y desechada al comenzar este trabajo, ya que requería la coope-
ración inicial de los sujetos en escena para poder detectarlos. Si bien versiones que aparecieron
posteriormente prescinden de esta cooperación, el área de operación efectiva es muy limitada por
las limitaciones propias de la información de profundidad de la kinect.
4.4. Skeltrack
La biblioteca de código abierto Skeltrack [25]. Está basada en [26] y utiliza información
heurística para encontrar a la persona. Si bien la detección es muy rápida, tanto el trabajo original
como la implementación en Skeltrack están limitadas a un usuario en cámara y necesitan que
el usuario sea el único objeto en escena.
Esta opción fue desechada debido a las limitaciones que imponía.
4.5. Human Tracker de ROS

El paquete Human Tracker [27, 28] para ROS, disponible en los repositorios de ROS In-
dustrial. Consiste en una cascada de detectores de complejidad ascendente, y se vale tanto de
la información de color como de la de profundidad.
Tiene poca documentación y no pudo hacerse funcionar en ROS Fuerte con el controlador
Kinect. Por estas causas, la opción fue descartada en favor de los detectores de OpenCV.
4.6. OpenPTrack
El proyecto OpenPTrack [29, 27, 30, 31], que permite la detección y seguimiento de múlti-
ples personas utilizando arreglos de cámaras. Algunos de sus desarrolladores formaron parte del
equipo de Human Tracker, por lo que los algoritmos utilizados son similares.
5 [20]se refiere a la versión del algoritmo para GPUs. La versión para CPUs no está documentada pero se utiliza
de la misma manera que la de GPUs.
6 Aproximadamente 1 segundo para una imagen de 640 ∗ 480 px.
7 Ver el trabajo original de Felzenszwalb. En nuestras pruebas con OpenCV, el número de falsos positivos lo
tornaba inútil para el objetivo buscado.

8 Open Natural Interface, plataforma que facilita el desarrollo de interfaces naturales, que son aquellas basadas
en gestos del usuario. Estandariza formatos y forma de acceder a los dispositivos.

9 Plugin para OpenNI que permite el seguimiento de esqueleto e interpretación de gestos manuales. De código
cerrado, desarrollado por PrimeSense.
9
5. Algoritmos evaluados
Se pudo hacer funcionar en la instalación de ROS Indigo existente, pero ocasionalmente

se cerraba con errores. Además, el sistema está diseñado para arreglos de cámaras en altura y
orientadas hacia abajo — condición no cumplida por los 30 cm de las cámaras en el TurtleBot
— por lo que las detecciones fluctuaban al situar al robot en el suelo (que es su condición habitual).
A continuación se presentan (conceptual y superficialmente) los detectores que tuvieron mejores
resultados y se enuncian los parámetros de cada uno. También mencionamos algunas estrategias
de pre y post procesamiento que fueron probadas.
5.1. HOG + SVM

El descriptor visual o vector de características (feature vector) es un histograma de gradientes
orientados. A grandes rasgos, su construcción (según el trabajo original de Dalal y Triggs) consiste
en : [21, 20, 32]
1. Se divide una imagen en pequeños bloques.
2. Para cada bloque:
a) Se calculan los gradientes (magnitud y ángulo) en cada píxel;
1) El gradiente horizontal se puede calcular (hay diversas definiciones) como la resta
entre el valor a la derecha del píxel y el que tiene a su izquierda (o al revés, lo
importante es mantener el criterio). Como ejemplo, ver Figuras 7 y 8.
2) Análogamente para el gradiente vertical, utilizando los píxels que están arriba y
debajo del píxel de interés.
3) A partir de lo anterior se obtiene el vector gradiente. Para el ejemplo en cuestión
(ver Figura 9):
dx = 94 − 56 = 38
dy = 93 − 55 = 38
p
Gradiente = 382 + 382 ≈ 53,74
Ángulo = arctan(38/38) = 45◦
b) Se agrupan las magnitudes en un histograma de 9 clases o bins, correspondientes a un

intervalo de orientaciones o ángulos (ver Figura 10);
c) Se normalizan los valores para hacer el descriptor más robusto ante cambios de con-
traste.
3. Se agrupan los resultados de cada bloque en un único vector descriptor.

Luego este vector ingresa a una Máquina de Vector Soporte o Máquina de Soporte Vectorial [33]
(Support Vector Machine, SVM ), que es un clasificador binario — su salida es la clase “persona”
o la clase “no persona”.
10
Figura 7: Cálculo del gradiente horizontal Figura 8: Imágenes de las componentes

y vertical para un píxel específico. del vector gradiente,
normalizadas a 256 valores
(a) Gradiente horizontal
(b) Gradiente vertical
Figura 9: Vector gradiente resultante

Figura 10: HOG: Histograma de 9 clases
5.1.2. Entrenamiento
La SVM se entrena previamente con una gran cantidad de muestras positivas y negativas
etiquetadas (se indica si cada imagen tiene una persona o no)10 , a las cuales se les calcula el
vector descriptor anteriormente mencionado. El subespacio vectorial obtenido se utiliza para
optimizar un hiperplano de decisión que permita la (mejor) separación entre las clases.
Para buscar personas se recorre la imagen objetivo con una ventana patrón — dicho de otra
manera, se hace deslizar la ventana sobre la imagen objetivo. Nótese que el sistema se diseña y
entrena para un tamaño fijo de imagen. Para hacerlo multiescala se recurre a achicar la imagen en
donde se buscan los objetos, o a escalar la ventana patrón adonde se intenta detectar la persona.
10 A esto se le denomina entrenamiento supervisado.
11
5.1.3. Implementación
El detector HOG de OpenCV está en el módulo objdetect. [20]11 Su constructor es:
HOGDescriptor ( cv : : S i z e w i n S i z e ,
cv : : S i z e b l o c k S i z e ,
cv : : S i z e b l o c k S t r i d e ,
cv : : S i z e _ c e l l S i z e ,
i n t nbins ,
i n t d e r i v A p e r t u r e =1,
d o u b l e winSigma=−1,
i n t histogramNormType=HOGDescriptor : : L2Hys ,
d o u b l e L2HysThreshold =0.2 ,
b o o l gammaCorrection=f a l s e ,
i n t n l e v e l s=HOGDescriptor : : DEFAULT_NLEVELS) ;
Estos argumentos corresponden a parámetros internos del detector. La mayoría no se puede

cambiar en la versión 2.4.x ya que solo se ha implementado la versión original de Dalal y Triggs.
Sí se puede elegir el parámetro winSize, que corresponde al tamaño de la ventana patrón, y debe
coincidir con el tamaño del modelo usado. OpenCV trae dos modelos incrustados en la librería:
DefaultPeopleDetector, entrenado con imágenes de 64 ∗ 128 px. Puede usarse con

HOGDescriptor::getDefaultPeopleDetector.
DaimlerPeopleDetector, entrenado con imágenes de 48 ∗ 96 px. Puede usarse con
HOGDescriptor::getDaimlerPeopleDetector.[34]
Para detectar en una imagen, se utiliza:
v o i d d e t e c t M u l t i S c a l e ( c o n s t cv : : Mat& img ,
s t d : : v e c t o r <cv : : Rect>& f o u n d L o c a t i o n s ,
double hitThreshold = 0 ,
cv : : S i z e w i n S t r i d e = cv : : S i z e ( ) ,
cv : : S i z e padding = cv : : S i z e ( ) ,
d o u b l e s c a l e =1.05 ,
d o u b l e f i n a l T h r e s h o l d =2.0 ) ;
Los argumentos son:
img Imagen objetivo.

foundLocations Vector de cv::Rect con las personas detectadas.
hitThreshold Umbral de distancia entre los vectores de features y el (hiper)plano de clasificación
— si la distancia es menor al umbral, la muestra es rechazada. Usualmente es 0, y debe
estar especificado en los coeficientes del detector, como el último coeficiente libre. En caso
de estar omitido ahí, se puede especificar en este argumento. Es usado como parámetro
variable en este trabajo.
winStride Avance de la ventana de evaluación. Debe ser un múltiplo del parámetro blockStride
del detector. En este trabajo es Size(8,8) en todos los casos, ya que es el menor paso
posible.
padding Píxeles de relleno en los bordes de la imagen. En este trabajo es Size(0,0) .

scale Coeficiente de incremento de la ventana de detección. Es usado como parámetro variable
en este trabajo.
11 Ver nota 5.
12
Figura 11: Funcionamiento de groupRectangles
finalThreshold Umbral de cantidad para agrupación de detecciones. Hace un llamado a la función

groupRectangles12 , que agrupa los rectángulos de un vector según su cercanía espacial y
similaridad de lados. La desventaja es que usa un factor eps fijo de 0.2 — la alternativa
es usar finalThreshold = 0 y luego usar groupRectangles con los valores deseados.
finalThreshold es usado como parámetro variable en este trabajo.
5.2. Cascada de clasificadores

En inglés, cascade of boosted classifiers, aunque también se conoce como algoritmo de Viola-
Jones, en honor a los autores de la idea[18]. Consiste en una cascada o serie de clasificadores
binarios cuya complejidad va en incremento — en su trabajo los clasificadores son árboles de
decisión de al menos 2 hojas. El sistema es efectivo por el conjunto completo de clasificadores,
que ha sido entrenado previamente para detectar un objeto específico; y es eficiente porque los
objetos que son rechazados por alguna etapa no son evaluados por las etapas subsiguientes. A
diferencia del clasificador SVM, en este caso no se calcula todo el vector descriptor (o vector de
características, feature vector) antes de ingresarlo al clasificador, si no que las componentes del
vector se van generando sucesivamente — cada componente es la entrada a un clasificador —
hasta terminar el vector o hasta que la respuesta de un clasificador sea negativa. OpenCV soporta
features del tipo Haar (Haar-like) o LBP, según se comenta en las siguientes secciones.[17]
Al igual que el detector HOG, detecta personas a través de una ventana deslizante que recorre
la imagen objetivo. Para la detección multi-escala se incrementa gradualmente el tamaño de la
ventana deslizante, o se decrementa gradualmente el tamaño de la imagen objetivo, según la
implementación. El detector está entrenado con imágenes de un tamaño fijo, generalmente muy
pequeño.
12 cv::groupRectangles(vector<Rect>& rectList, int groupThreshold, double eps=0.2) — Agrupa los rec-

tángulos cuya relación entre lados sea menor a eps y crea un rectángulo promedio de los agrupados. Luego de
la agrupación o clustering, solo retiene aquellos grupos con más de groupThreshold rectángulos. Un valor de
0 en groupThreshold implica no hacer nada. Ver Figura 11.
13
Nótese que cada feature está asociada a una posición fija dentro de una imagen de tamaño fijo.
Entonces, cada feature o descriptor específico está determinado por su valor y por información
implícta no variable: su posición, su escala (no confundir con el escalado de toda la imagen o
clasificador, para la detección) y su figura — estos dos últimos solo para features Haar. Por
ejemplo, una característica podría ser del tipo 1(a) de la Figura 13, de un tamaño total de
20 ∗ 20 px y con su esquina superior en las coordenadas (2,12) de la imagen objetivo. Otra
característica podría ser del mismo tipo, pero de un tamaño de 38 ∗ 38 px y situada en (43,33).
El valor de cada una ingresa a un clasificador binario distinto, y no necesariamente ambas se
calcularán en caso de una imagen que no contiene el objeto buscado.
Figura 12: Cascada de clasificadores
5.2.2. Entrenamiento
El entrenamiento del clasificador es supervisado: se ingresa una gran cantidad de imágenes
positivas y negativas, todas etiquetadas (clase “persona” o clase “no persona”); luego el sistema se
optimiza iterativamente para reducir la diferencia entre las salidas del clasificador y las etiquetas.
Se evaluan las características o features en todas las posiciones posibles, para todas las imá-
genes; cada característica es la entrada a un clasificador binario distinto. Estos son llamados
clasificadores débiles, porque individualmente no permiten una buena clasificación, y muchas
veces apenas pueden superar a una decisión aleatoria. Sin embargo, en conjunto forman un
clasificador fuerte.
Durante las iteraciones de entrenamiento, cada feature (y en cada posición) se va pesando según
su capacidad de detección y se priorizan las imágenes que han sido incorrectamente clasificadas.
Al finalizar el entrenamiento, solamente las mejores características se retienen, pues son las que
mejor permiten la identificación del objeto — además se reduce la dimensionalidad del clasificador
y se hace más general o menos sobreentrenado. El detector de caras presentado por Viola y Jones
tiene más de 160.000 features posibles, pero sólo se utilizan alrededor de 6,000 — afirman que
con 200 ya obtienen una precisión del 95 %. [18]
5.2.3. Haar-like features

OpenCV utiliza los algoritmos y los descriptores propuestos en el trabajo de Lienhart y otros
[35], que presentan una mejora al trabajo de Viola y Jones. Los descriptores se denominan símil-
Haar o Haar-like, debido a su similitud con ondeletas Haar; por simplicidad también son llamados
features Haar.
Consisten en áreas rectangulares agrupadas en conjuntos simples. La Figura 13 muestra los
descriptores básicos propuestos en [35] — se escalan a diferentes tamaños para formar nuevos
features. Según su forma, los descriptores indicarán la presencia de líneas, bordes y puntos. En
cada caso, la suma de los valores de los píxeles bajo los rectángulos blancos es restada de la suma
de los píxeles bajo los rectángulos negros. Pueden calcularse de forma muy eficiente a través del
uso de las llamadas imágenes integrales (integral images) o tablas de áreas sumadas.
5.2.4. LBP features

Los patrones binarios locales [19] (Local Binary Patterns, LBP) son descriptores originalmente
utilizados para discriminar texturas. Naturalmente robustos ante cambios de iluminación, fueron
mejorándose para ser invariantes ante rotaciones y otros factores, e implementados de diferentes
formas para hacerlos útiles en la detección de objetos, reconocimiento facial, análisis temporal
de imágenes, entre otras aplicaciones.
14
Figura 13: Prototipos de features Haar-like usados en OpenCV
Básicamente, se analiza cada píxel de una imagen o región de una imagen, de la siguiente
manera: [36, 37, 38]
1. Se evalúa la diferencia entre cada uno de los píxeles circundantes (según la implementación,
inmediatamente adyacentes, a un radio mayor o incluso interpolando valores) y el píxel
central del análisis.
2. A los píxeles cuyo valor es mayor o igual al píxel central se les asigna un valor de 1,
mientras que aquellos cuyo valor sea menor reciben un valor de 0. Nótese que la diferencia
se mantendrá aunque cambie el contraste o el brillo.
3. Los valores obtenidos se concatenan en una única palabra binaria que es la que representa
al píxel — se reemplazó su valor original por uno que codifica la información propia y la
de su entorno.
Otras implementaciones analizan sólo conjuntos no intersectados de píxeles; es decir, cada píxel
sólo pertenece a un vecindario. También hay versiones que incluyen información multiescala,
incluyendo en el vector descriptor los valores correspondientes a más de un radio de análisis.
Figura 14: Principio de funcionamiento de los patrones binarios locales
Luego se puede computar el histograma de la “imagen” obtenida y así codificar todo en un

solo vector descriptor. Para no perder información localizada se recurre a dividir en bloques
la imagen objetivo, y se calcula el histograma de cada bloque; cada histograma es la entrada
a un clasificador de la cascada.13 En otros casos (como el reconocimiento facial) y para otros
clasificadores, todos los histogramas se concatenan en un mismo vector.
Empíricamente se ha encontrado (en el análisis de texturas) que la mayoría de la información útil
se encuentra en los patrones uniformes, que son aquellos que tienen menos de 3 transiciones
entre 1s y 0s: 00000000, 001110000, 10000000, 11111101, ... Agrupando todas las transiciones
que son equivalentes (iguales si se rotan un número de veces) como si fuesen el mismo patrón, se
logra una reducción del descriptor y además invarianza rotacional.
5.2.5. Implementación
El detector en cascada está en el módulo objdetect de OpenCV. [17] Su constructor:
CascadeClassifier () ;
13 Estimamos que es de esta manera en OpenCV, pero no podemos afirmarlo. LBP no está documentado en la
sección de detectores en cascada.
15
Se puede cargar un modelo de cascada entrenado con el método load:
detector . load ( direccion_a_cascada ) ;
El archivo cargado determinará si se utilizan features LBP o Haar-like. En este trabajo se

probaron los siguientes detectores:
haarcascade_fullbody, entrenado con imágenes de 14 ∗ 28 px, de cuerpo completo.[39]
Incluido en el código fuente de OpenCV
(opencv/data/haarcascades/ haarcascade_fullbody.xml).
haarcascade_lowerbody, entrenado con imágenes de 19 ∗ 23 px, de la parte inferior
del cuerpo.[39] Incluido en el código fuente de OpenCV
(opencv/data/haarcascades/ haarcascade_lowerbody.xml).
haarcascade_mcs_upperbody, entrenado con imágenes de 14 ∗ 20 px, de cabeza y

hombros. [39][40] Incluido en el código fuente de OpenCV
(opencv/data/haarcascades/haarcascade_mcs_upperbody.xml).
haarcascade_upperbody, entrenado con imágenes de 18∗20 px.[39] Incluido en el código
fuente de OpenCV (opencv/data/haarcascades/ haarcascade_upperbody.xml).
vision-ary.net, entrenada con imágenes de 26 ∗ 74 px. [41]

La detección multi-escala en una imagen se realiza con:
v o i d d e t e c t M u l t i S c a l e ( c o n s t Mat& image ,
v e c t o r <Rect>& o b j e c t s ,
d o u b l e s c a l e F a c t o r =1.1 ,
i n t minNeighbors =3,
i n t f l a g s =0,
S i z e m i n S i z e=S i z e ( ) ,
S i z e maxSize=S i z e ( ) ) ;
Los argumentos de la función son:

image Imagen objetivo.
objects Vector de cv::Rect con las personas detectadas.
scaleFactor Coeficiente de incremento de la ventana de detección o de la imagen objetivo. Es

usado como parámetro variable en este trabajo.
minNeighbors Umbral de cantidad para agrupar detecciones. Ver finalThreshold en 5.1.3. Es
usado como parámetro variable en este trabajo.
flags Opciones sólo documentadas en versiones antiguas (<2.0) de OpenCV. [42] En este trabajo
no se utilizarán, y por tanto flags = 0.
cv::CASCADE_DO_CANNY_PRUNING=1 — Si está activada, se utiliza un detector de bordes
tipo Canny para rechazar regiones de imagen que tengan demasiados o muy pocos bordes
y por lo tanto sea poco factible que contengan el objeto buscado. Los umbrales de esta
opción están ajustados a la detección de caras. Sirve para acelerar el procesamiento.
cv::CASCADE_SCALE_IMAGE=2 — Se escala la imagen en vez de agrandar la ventana patrón.
No puede usarse simultáneamente con ninguna de las otras opciones.
cv::CASCADE_FIND_BIGGEST_OBJECT=4 — Sólo devuelve el objeto más grande detectado,
o ninguno si no hubo detecciones.
cv::CASCADE_DO_ROUGH_SEARCH=8 — Solo puede usarse si CASCADE_FIND_BIGGEST_OBJECT
está activada y minNeighbors es mayor a 0. Cuando está activada, la función realiza una
búsqueda tosca, aproximada: no se buscarán candidatos de menor tamaño una vez que se
encontró el objeto (con suficientes detecciones vecinas) para la escala vigente.
16
minSize cv::Size, tamaño mínimo de las detecciones. Acota la búsqueda junto a maxSize. Es
usado como parámetro variable en este trabajo, proporcional a la escala inicial.
maxSize cv::Size, tamaño máximo de las detecciones. Es usado como parámetro variable en
este trabajo, proporcional a la escala inicial.
5.3. Preprocesamiento
5.3.1. Escalado inicial
Se reduce el tamaño de la imagen por un factor arbitrario. Esta función es especialmente
importante en cámaras de gran resolución, donde se puede acortar de manera importante el
tiempo de procesamiento sin que esto tenga un impacto significativo en los resultados.
5.3.2. Transformación a escala de grises

Es especialmente útil para hacer que los algoritmos sean más ágiles en procesar. También es
utilizada como etapa obligatoria previa a la ecualización de histograma en OpenCV 2.4.x.
5.3.3. Ecualización de histograma

Normalización de la imagen de forma tal que su histograma se reparta uniformemente en
todo el rango de grises. Si bien en OpenCV 2.4.x la ecualización solo puede realizarse sobre
imágenes de un único canal, podría aplicarse a imagenes en color si se trabaja en modelos de
color que separen la intensidad de la información de color, como HSV — en este caso se ecualiza
el histograma del canal de intensidad o brillo.
5.3.4. Filtrado por convolución

En el filtrado por convolución, cada píxel de una imagen es reemplazado por la suma pesada
de sí mismo y una cantidad de píxeles cercanos. El peso asignado a cada píxel y la cantidad y
posición de píxeles cercanos que influyen en cada operación son determinados por una matriz
cuadrada llamada kernel o núcleo, o simplemente filtro o matriz. La matriz de convolución se
desplaza sobre toda la imagen original, fila por fila y columna por columna, de manera tal que
al recorrer todos los píxeles se ha creado una nueva imagen filtrada.
Matemáticamente, la operación es una convolución bidimensional entre la imagen y la matriz de
convolución, que generalmente es de un tamaño mucho menor a la imagen a filtrar.
En este trabajo utilizamos kernels estándar, especificados a continuación. En todos los casos
el píxel ancla o anchor es el punto central del kernel.
Promediado (box blur ) Enfoque (sharpen) Repujado (emboss)
1 1 1 0 −1 0 0
     
−2 −1
K = 91  1 1 1  K =  −1 5 −1  K =  −1 1 1 
1 1 1 0 −1 0 0 1 2
Figura 15: Filtrado por convolución
(a) Original (b) Box blur (c) Enfoque (d) Repujado
17
6. Pruebas
5.4. Postprocesamiento
5.4.1. Estimación de la altura real
Ya que se cuenta con la imagen de profundidad, se puede estimar la altura real de cada objeto
detectado.[43] Así, se pueden eliminar objetos que sean mayores o menores a un rango de alturas
válido para personas.
Lr : Longitud real del objeto [m]
Lp : Longitud del objeto [px]
Dr : Distancia al objeto [m]
Fp : Distancia f ocal [px]
Lp ∗ Dr
Lr =
Fp
Se utilizó una distancia focal Fp = 570 px, de acuerdo a lo sugerido en [7] y otros. La medida
de distancia se toma en el centro horizontal de cada cuadro, y a 2/3 de altura desde la base.
6. Pruebas
Se evaluaron los resultados de los detectores mencionados en la sección 5, para distintas combi-
naciones de parámetros, sobre sets de imágenes tomados desde el robot TurtleBot. El objetivo
es analizar la influencia de cada parámetro y elegir la mejor combinación para implementarla en
un nodo de ROS que se ejecutará en el robot. Los resultados se presentan en la sección 8.
6.1. Metodología
Por simplicidad, los parámetros de cada detector se consideran independientes entre sí. Se
evalúa la incidencia de cada uno sobre los resultados totales, manteniendo todos los demás
constantes en valores relativamente estándar.
El programa que realiza las detecciones es dp_opencv. Este programa guarda en un archivo
csv los datos de las detecciones, y en un txt los parámetros que se utilizaron.
• Fue diseñado para que fácilmente puedan añadirse y utilizarse otros detectores. De
hecho, para extraer manualmente las coordenadas reales se utilizó una clase detectora.
El programa dp_resultados compara las detecciones de un csv con las coordenadas reales
del set. Guarda un archivo con los resultados.
Un conjunto de scripts de bash ejecuta dp_opencv y dp_resultados para distintas com-
binaciones de parámetros y junta los resultados en un único archivo para posterior visua-
lización.
6.2. Evaluación
6.2.1. Igualdad
Cada detección es un rectángulo contenido en la imagen de entrada. Sea e una detección
estimada y r el rectángulo real que contiene a una persona en una imagen,
e u r si y solo si
1. La distancia euclídea entre centros es menor a una proporción del ancho de r
q
(centroxr − centroxe )2 + (centroyr − centroye )2 < P _RADIO ∗ anchor
2. La diferencia entre anchos es menor a una proporción del ancho de r
|anchor − anchoe | < P _AN CHO ∗ anchor
18
6. Pruebas
3. La diferencia entre alturas es menor a una proporción de la altura de r
|altor − altoe | < P _ALT O ∗ altor
Se ajustaron14 los factores a:
P _RADIO = 0,5
P _AN CHO = 1
P _ALT O = 0,4
6.2.2. Medidas básicas

Presentamos algunas medidas útiles para la definición de las métricas a optimizar:
Verdadera positiva Una persona estimada que coincide con una persona real en la imagen.
En este trabajo se cuentan como verdaderas todas las detecciones que coincidan con una
persona, aunque sea la misma persona.
Falsa positiva Una detección estimada que no coincide con ninguna persona real.
Falsa negativa Una persona real que no tuvo ninguna detección que coincida.
A partir de lo anterior se definen:
Precisión Proporción verdadera de todas las detecciones realizadas.

verdaderas positivas
P recisión =
verdaderas positivas + f alsas positivas
Recuperación También llamada exhaustividad o recall. Proporción detectada de todas las per-
sonas reales marcadas.
verdaderas positivas
Recuperación =
verdaderas positivas + f alsas negativas
6.2.3. Medidas a optimizar

Las métricas que se intentarán optimizar son F1 y F0.5 , que pueden considerarse casos es-
pecíficos de Fβ , una media pesada de la precisión y la recuperación. Mide la efectividad de
recuperación para un usuario que le da β veces más importancia a la recuperación que a la
precisión. F1 es la media armónica de la precisión y la recuperación. F0.5 , entonces, prioriza la
precisión sobre la recuperación. Se consideró que para la mayoría de las posibles aplicaciones
del TurtleBot que usen este detector, es más importante la precisión que la recuperación —
especialmente si luego se hace seguimiento de la detección. Las definiciones:
precisión ∗ recuperación
Fβ = (1 + β 2 ) ∗
β 2 ∗ precisión + recuperación
F1 = (2) ∗
precisión + recuperación
F0,5 = (1 + 0,52 ) ∗
0,52 ∗ precisión + recuperación
14 Por prueba y error. Para esto desarrollamos el programa dp_cuadros, que marca las personas reales y las
estimadas. Consideramos que la inspección visual fue herramienta esencial para la detección de errores
en el programa.
19
6. Pruebas
6.3. Sets de imágenes

Se tomaron varios sets de imágenes para la optimización de parámetro y su posterior validación.
Se construyó un nodo de ROS para capturar en forma sincronizada las imágenes RGB y de
profundidad, teniendo el menor desfase temporal posible.15 Las cámaras RGB e infrarroja se
calibraron para reducir la distorsión geométrica. La alineación o registro de las imágenes de
profundidad respecto al punto de vista de la cámara RGB es realizada por la Kinect en forma
automática.
Figura 16: Calibración de cámaras
(a) RGB (b) Infrarroja
Las imágenes se tomaron con el robot TurtleBot en el suelo y el sensor Kinect en su

montaje original, a 30 cm del suelo. Las escenas son espacios interiores con sillas, mesas y otros
elementos que pueden ocluir a las personas que circulan. Las personas se marcaron manualmente;
el criterio elegido fue etiquetar si más del 50 % de la persona es visible en la imagen.
Los sets:
Set1: 24 imágenes. Una sola persona en escena. Tomado con el robot en el suelo, en una sala
cerrada, de cara a un ventanal con iluminación natural. Se utilizó en las fases iniciales de
este trabajo.
Set2: 300 imágenes. Una sola persona en escena. Tomado con el robot en el suelo en una sala
cerrada. Iluminación artificial con lámparas de bajo consumo.
Set3: 300 imágenes. Dos personas en escena. Tomado con el robot en el suelo en una sala cerrada.
Iluminación artificial con lámparas de bajo consumo.
Set4 300 imágenes. Dos personas en escena. Tomado con el robot sobre una mesa, en una sala
cerrada. Iluminación artificial con lámparas de bajo consumo. No se usó.
Set5: 300 imágenes. Dos personas en escena. Tomado con el robot en el suelo en una sala cerrada.
Set6: 300 imágenes. Dos personas en escena. Tomado con el robot en el suelo, en un laboratorio.
Set7: 300 imágenes. Dos personas en escena. Tomado con el robot en el suelo, en un laboratorio.
Set8: 300 imágenes. Dos personas en escena. Tomado con el robot en el suelo, en un pasillo
ancho. Iluminación natural a través de ventanales.
Los sets 2,3 y 5 se agruparon en uno nuevo, el set235. Este será el utilizado para las pruebas y
ajustes de parámetros. Los sets 6 y 7 se agruparon en el set67, utilizado como set de validación.
El set 8 también es usado como set de validación, pero separado del set67 debido al perjudicial
efecto de la luz solar presente (ver 3.2).
Debe aclararse que los sets son muy limitados, en el sentido de que no tienen diversidad de
personas, vestimentas, superficies, iluminación, objetos presentes, entre otros factores.
15 Losmensajes a los que el programa se suscribe son /camera/rgb/image_rect_color y
/camera/depth_registered/hw_registered/image_rect_raw
20
6. Pruebas
Figura 17: Sets de imágenes
(a) Set 1 (b) Set 2 (c) Set 3 (d) Set 4
(e) Set 5 (f) Set 6 (g) Set 7 (h) Set 8
6.4. Parámetros
6.4.1. HOG + SVM
Los parámetros variados son:
escala_inicial Ver 5.3.1

pasoEscala Ver scale en 5.1.3
umbralAgrupamiento Ver finalThreshold en 5.1.3
hit_threshold Ver hitThreshold en 5.1.3

setSVMDetector Ver setSVMDetector en 5.1.3
convertir_a_gris Ver 5.3.3
ecualizar_histograma Ver 5.3.3
blurear Ver 5.3.4

tamanio_blur Tamaño del filtro cuadrado de suavizado. Ver 5.3.4
filtro_enfoque Ver 5.3.4
filtro_repujado Ver 5.3.4

filtro_enfoque_y_repujado Aplicación del filtro de enfoque y luego del de repujado. Ver 5.3.4
filtro_repujado_y_enfoque Aplicación del filtro de repujado y luego del de enfoque. Ver 5.3.4
usar_profundidad_altura Ver 5.4.1
6.4.2. LBP + Cascada

Los parámetros variados son:
direccion_a_cascada Ver 5.2.5

escala_inicial Ver 5.3.1
21
7. Implementación
minSize Determinamos un cuadro mínimo de 50 ∗ 100 px.16 Se escala según escala_inicial.

maxSize Determinamos un cuadro máximo de 180 ∗ 360 px. Se escala según escala_inicial.
convertir_a_gris Ver 5.3.3
ecualizar_histograma Ver 5.3.3
scaleFactor Ver scaleFactor en 5.2.5
minNeighbors ver minNeighbors en 5.2.5
usar_profundidad_altura Ver 5.4.1
blurear Ver 5.3.4
tamanio_blur Tamaño del filtro cuadrado de suavizado. Ver 5.3.4
filtro_enfoque Ver 5.3.4
filtro_repujado Ver 5.3.4
filtro_enfoque_y_repujado Aplicación del filtro de enfoque y luego del de repujado. Ver 5.3.4
filtro_repujado_y_enfoque Aplicación del filtro de repujado y luego del de enfoque. Ver 5.3.4
7. Implementación
Una vez realizadas las pruebas para poder determinar qué algoritmo y qué parámetros se
adaptaban mejor a nuestro objetivo, implementamos el detector como un nodo de ROS para eje-
cutarlo en línea. Para mayor compatibilidad solo se usaron funciones de CPU, ninguna
de GPU.
7.1. Conceptos generales de ROS

ROS es un sistema diseñado para ser modular, por lo que el sistema esta compuesto de múlti-
ples nodos. Los nodos son programas que realizan alguna acción específica, y cada equipo puede
estar ejecutando varios nodos. Para poder trabajar conjuntamente necesitan comunicarse por
algún medio, este medio son los mensajes. Un mensaje es una estructura de datos estrictamente
tipificada y pueden estar formados por tipos primitivos (int, float, bool, etc), o tipos más com-
plejos, como vectores, matrices o incluso por otros mensajes o vectores de otros mensajes. Para
ordenar un poco la interacción de los nodos con los mensajes existen los topics o temas, títulos
que agrupan a mensajes del mismo tipo y significado. Múltiples nodos pueden estar publicando
mensajes en un mismo tema y más de un nodo puede estar suscripto a un mismo tema. De esta
manera la comunicación es indirecta, y generalmente los nodos no conocen quienes son los publi-
cadores o los suscriptores en un determinado topic. Hay métodos para asegurar una comunicación
directa entre nodos evitando la publicación.
Para los nodos es totalmente transparente la topología sobre la cuál se ha implementado el
sistema bajo ROS. Así, una computadora montada sobre un robot puede estar ejecutando los
nodos de control general del robot, una mini-computadora o microcontrolador ejecuta un nodo
de control específico de un componente, mientras que una computadora de escritorio con mayor
capacidad ejecuta nodos de planificación. Todos dispositivos deben estar conectados en red.
A pesar de lo que sugiere lo anterior, ROS no es un sistema distribuido, ya que requiere del
funcionamiento de un único nodo central: el nodo núcleo o core. El dispositivo que ejecute el
nodo roscore será denominado dispositivo maestro o master.
Para poder desarrollar aplicaciones de OpenCV en ROS se deben convertir los mensajes
de tipo imagen de ROS a algún tipo nativo de OpenCV. Esto se realiza mediante el paquete
CvBridge de ROS. [44]
16 De acuerdo a mediciones preliminares, teniendo en cuenta el tamaño de imagen de 640 ∗ 480 px de la Kinect,
la porción visible de la imagen (debido a la plataforma superior del Turtlebot), y el tamaño de una persona
en el rango objetivo.
22
7. Implementación
Figura 18: Funcionamiento de CvBridge de ROS
7.2. Información desde el TurtleBot

La computadora conectada al TurtleBot puede transmitir las imágenes recibidas desde la
Kinect. Para esto, desde esta computadora, se ejecutan los nodos necesarios para alimentar el
robot y el sensor, y luego transmitir las imágenes. Estando ROS instalado y configurado para el
robot TurtleBot [45], se ejecuta:17
$ r o s l a u n c h t u r t l e b o t _ b r i n g u p minimal . l a u n c h
Seguidamente se ejecuta el nodo que pone en funcionamiento la Kinect:
$ roslaunch turtlebot_bringup 3 dsensor . launch
Con esto ya se estarán publicando los mensajes con la imágenes en distintos formatos. Para la
imagen en color en este trabajo utilizaremos el topic /camera/rgb/image_rect_color y para la
imagen de profundidad será /camera/depth_registered/hw_registered/image_rect_raw.
Se pueden visualizar las imágenes publicadas con el nodo rqt_image_view:
$ r o s r u n rqt_image_view rqt_image_view
7.3. Información desde la Raspberry Pi

En esta mini-computadora se instaló Ubuntu para ARM, y ROS Indigo. Luego se utilizó
el paquete Raspicam [46], el cual contiene el driver de la cámara SCI de la Raspberry y le
agrega la interfaz para manejarlo como un nodo de ROS, con servicios y mensajes que permiten
explotar todas las funcionalidades de la cámara. Para publicar los mensajes con las imágenes, en
la Raspberry se ejecuta18 :
$ r o s r u n r a s p i c a m raspicam_node
Luego de esto se dispone dos servicios principales para usar las funcionalidades de la cámara,
los cuales se pueden llamar desde la computadora maestra o cualquier otro equipo en la red:
$ r o s s e r v i c e c a l l / camera / s t a r t _ c a p t u r e // Comienza l a c a p t u r a de
video y lo publica .
$ r o s s e r v i c e c a l l / camera / s t o p _ c a p t u r e // D e t i e n e l a c a p t u r a de v i d e o
y la publicación .
Cuando usamos el primero publica distintos mensajes con información. El topic necesario
para ver la imagen de la cámara es /camera/image. Para ver más opciones y características del
paquete, remitirse a su documentación en [46].
Nuevamente, se pueden visualizar las imágenes con rqt_image_view.
17 Esto ejecutará el nodo roscore si no está ya funcionando en alguna máquina de la red.

18 Remotamente con ssh o conectando monitor y teclado a la Raspberry.
23
8. Resultados
7.4. Información desde una PC

Como agregado se decidió incorporar un nodo capaz de publicar el video de una webcam al
sistema de ROS con el topic /camera/image. Este nodo detecta si existe una webcam conectada
y publica su contenido a 10 FPS. Para ejecutar este nodo ejecutamos:
$ rosrun detpeople publicador_video
Este nodo puede ser ejecutado en cualquier PC con sistema ROS.
7.5. Nodo de detección

El nodo desarrollado para cumplir el objetivo de detectar personas, llamado detpeople, se
suscribe al mensaje de alguno de los tres publicadores mencionados anteriormente (webcam,
Raspberry Pi 2 o TurtleBot); siempre debe ejecutarse uno de ellos. En el nodo detpeople
se implementaron los dos algoritmos con mejores resultados para probarlos en linea, en clases
separadas para aprovechar el encapsulamiento. Además se incorporaron métodos para que en caso
de que exista una imagen de profundidad (como la generada por la Kinect), se estime la altura
del objeto detectado. Con esto eliminamos de manera importante los falsos positivos a costa de
disminuir un poco la capacidad de recuperacion, como se ha demostrado en los resultados.
Este nodo de detección de personas se ejecuta de esta forma:
$ rosrun detpeople detpeople
El nodo muestra y publica la imagen con las personas detectadas marcadas para así poderlas
visualizar en cualquier otra PC o incluso desde un celular o una tablet con Android.19
Para hacer funcionar todo el entorno de ROS se debe ejecutar roscore en la computadora que
se decida como maestra. Este nodo se encargara de ejecutar todos los servicios necesarios para
que sea posible el funcionamiento del sistema.
Para mayores detalles referirse al código adjunto y al Apéndice B.
8. Resultados
8.1. Pruebas y ajuste de parámetros
8.1.1. HOG + SVM
En la Tabla 1 se observan los resultados obtenidos para el detector HOG en el set 235. 20
Algunas observaciones:
Como se preveía, en casi todos los casos un aumento de precisión implica un decremento
de recuperación, y viceversa.
El detector Daimler tuvo un peor desempeño que el Default. Manteniendo el resto de
los parámetros igual, el detector Daimler mejoró la recuperación (80 % contra 66 %) pero
tuvo un gran decremento en precisión (19 % contra 96 %). Hay que recordar (ver 5.1.3) que
están entrenados con imágenes de distinto tamaño y tal vez eso está relacionado con los
otros parámetros.
La ecualización de histograma mejora los resultados.
La mejor escala inicial no fue 1 (sin escalado) sino que fue 1,5. Sugiere una relación entre
la escala inicial y el paso de escala o factor de escalado.
La altura estimada a partir de la profundidad aumentó la precisión en 3 %, a costa de un

1 % de recuperación.
Las 2 mejores combinaciones están en la Tabla 3, una con filtrado por altura estimada y la otra
sin esta opción.
19 Ver aplicación Ros Image View, disponible en el Play Store de Google

20 Las tablas completas se encuentran en evaluacion/resultados/evaluacion/
24
Parámetro Tipo Variación Valor inicial Valor final Precisión Recuperación F1 F0.5 Mejor valor (F0.5) Tiempo
tamanio_blur int Incremento Sin blur 9 Decrece Decrece Decrece Decrece Sin blur Crece
escala_inicial float Incremento 1 3 Crece Crece y luego decrece Crece y luego decrece Crece y luego decrece 1,5 Decrece
hit_threshold float Incremento 0 4 Crece Decrece Decrece Decrece 0 Constante
umbralAgrupamiento int Incremento 1 8 Crece Decrece Crece y luego decrece Crece y luego decrece 2 Constante
pasoEscala float Incremento 1,05 4 Decrece Decrece Decrece Decrece 1,05 Decrece
clasificador - - Default Daimler - - - - Default -
filtros bool - Sin filtros Con filtros - - Decrece Decrece Sin filtros -
convertir_a_gris bool - No Sí Decrece Crece Decrece Decrece No Decrece
ecualizar_histograma bool - No Sí Constante Crece Crece Crece Sí Constante
usar_profundidad_altura bool - No Sí Crece Decrece Crece Crece Sí Constante

evaluación de parámetros
Tabla 1: HOG + SVM: Resultados de la
25
8. Resultados
Parámetro Tipo Variación Valor inicial Valor final Precisión Recuperación F1 F0.5 Mejor valor (F0.5) Tiempo
tamanio_blur int Incremento Sin blur 9 Decrece Crece Crece Decrece Sin blur Crece
cascada - Distintas cascadas - - - - - - Vision-ary -
escala_inicial float Incremento 1 4 Crece Decrece Decrece Crece y luego decrece 1,2 Decrece
filtros bool - - - Crece Decrece Decrece Decrece Sin filtros Decrece
minNeighbors int Incremento 1 8 Crece Decrece Crece y luego decrece Crece y luego decrece 5 Constante
scaleFactor float Incremento 1,05 4 Crece Decrece Decrece Crece y luego decrece 1,1 Decrece
ecualizar_histograma bool - No Sí Crece Crece Crece Crece Sí Constante
usar_profundidad_altura bool - No Sí Crece Decrece Crece Crece Sí Constante

evaluación de parámetros
Tabla 2: LBP + Cascada: Resultados de la
8. Resultados
Tabla 3: HOG+SVM: Mejores combinacio- Tabla 4: LBP + Cascada: Mejores combi-

nes en las pruebas iniciales naciones en las pruebas iniciales
Mejor Segunda Mejor Segunda
Parámetro Valor Parámetro Valor
pasoEscala 1.050000 1.050000 direccion_a_cascada vision-ary vision-ary
umbralAgrupamiento 2 2 escala_inicial 1.300000 1.300000
hit_threshold 0.000000 0.000000 tamanio_minimo [38 x 77] [38 x 77]
setSVMDetector Default Default tamanio_maximo [138 x 277] [138 x 277]
escala_inicial 1.300000 1.500000 convertir_a_gris true true
convertir_a_gris true true ecualizar_histograma true true
ecualizar_histograma true true scaleFactor 1.100000 1.100000
blurear false false minNeighbors 4 5
tamanio_blur 3 3 usar_profundidad_altura true false
filtro_enfoque false false blurear false false
filtro_repujado false false tamanio_blur 3 3
filtro_enfoque_y_repujado false false filtro_enfoque false false
filtro_repujado_y_enfoque false false filtro_repujado false false
usar_profundidad_altura true false filtro_enfoque_y_repujado false false
F0.5 0.899069 0.881625 filtro_repujado_y_enfoque false false
Tiempo promedio [ms] 59.569961 41.347358 F0.5 0.801030 0.794961
Precisión 0.993234 0.978022 Tiempo promedio [ms] 43.176355 43.099704
Recuperación 0.651865 0.632327 Precisión 0.972426 0.944923
Recuperación 0.469805 0.486271
8.1.2. LBP + Cascada

En la Tabla 2 se observan los resultados obtenidos para el detector LBP en el set235.
Algunas observaciones:
Como se preveía, en casi todos los casos un aumento de precisión implica un decremento
de recuperación, y viceversa.
El modelo entrenado de vision-ary muestra resultados mucho mejores que los del resto
de las cascadas. fullbody, lowerbody, mcs_upperbody tuvieron F0.5 de 0,26, 0,15
y 0,04 respectivamente. upperbody no tuvo detecciones. vision-ary es una cascada más
moderna y con más entrenamiento. [41]
La ecualización de histograma mejora los resultados.
La mejor escala inicial no fue 1 (sin escalado) sino que fueron 1,2 y 1,3. Sugiere una relación
entre la escala inicial y el paso de escala o factor de escalado.
La altura estimada a partir de la profundidad aumentó la precisión en 6 %, a costa de un
4 % de recuperación.
Las 2 mejores combinaciones están en la Tabla 4, una con filtrado por altura estimada y la otra
sin esta opción.
8.2. Pruebas con los mejores parámetros

En función de las variaciones observadas previamente, elegimos los mejores valores para cada
parámetro, intentando optimizar F0.5 . Las Tablas 5 y 6 muestran esas combinaciones de pará-
metros y sus resultados sobre el mismo set235.
Los resultados son aproximadamente iguales, e incluso peores, lo que demuestra que los pa-
rámetros no son totalmente independientes. Tanto como para la cascada con LBP como para
el detector HOG, las combinaciones que utilizan filtrado por altura estimada muestran mejores
resultados. El aumento en precisión que aporta supera a la disminución en recuperación que
causa.
26
9. Conclusiones
Tabla 5: HOG+SVM: Parámetros optimi- Tabla 6: LBP + Cascada: Parámetros optimizados

zados sobre set235 sobre set 235
tamanio_blur 3 3 usar_profundidad_altura false true
usar_profundidad_altura false true filtro_enfoque_y_repujado false false
8.3. Pruebas sobre el set de validación

Para validar los resultados, las mismas combinaciones de 8.2 fueron probadas sobre los sets
set67 y set8. Referirse a las Tablas 7, 8, 9 y 10.
En el set67 podemos ver que, al contrario que en las pruebas sobre el set235, F0.5 decrece al
usar la información de profundidad. Por el contrario, crece para el detector en cascada. Esto es
porque muchas de las personas en este set están parcialmente ocluidas, y la distancia que se estima
(según lo explicado en 5.4.1) es errónea. HOG tiende a tener buena precisión y recuperación, por
lo que el filtrado por altura estimada (a partir de distancia errónea) lo perjudica. Por otro lado,
el detector en cascada indicaba muchos falsos positivos en todas las pruebas, y el filtrado correcto
de estos compensa las verdaderos positivos que se pierden por estimación errónea de altura. Es
decir, el aumento en precisión supera por mucho al decremento en recuperación, mientras que
para el detector HOG la relación es inversa: la pérdida en capacidad de recuperación es mayor
al incremento en precisión.
El mismo efecto se observa en las pruebas sobre el set8. Esta vez, los sujetos no están ocluidos
pero la información de profundidad es escasa (ver 6.3) y lleva al rechazo de muchos verdaderos
positivos. Para el caso del detector en cascada, el filtrado por altura permite rechazar la detección
continua de un matafuegos cercano (ver Figura 20g), que es la causa de un F0.5 de 0.30.
8.4. Implementaciones en línea

El desempeño de las implementaciones en línea fue satisfactorio y muy similar a lo obtenido
en las pruebas.
9. Conclusiones
9.1. Resultados
Evaluamos las distintas opciones que ofrece OpenCV 2.4.x para la detección de personas
(detector en cascada con features tipo Haar, detector en cascada con features tipo LBP y el
detector HOG) para un caso específico: la detección de personas desde un robot TurtleBot
27
9. Conclusiones
Tabla 7: HOG+SVM: Parámetros optimi- Tabla 8: LBP + Cascada: Parámetros optimizados

zados sobre set67 sobre set67
Tabla 9: HOG+SVM: Parámetros optimi- Tabla 10: LBP + Cascada: Parámetros optimiza-
zados sobre set8 dos sobre set8
28
9. Conclusiones
Figura 19: Detecciones
(a) Verdadero positivo (b) Verdaderos positivos: frente y re- (c) Verdadero positivo
verso
(d) Verdaderos positivos: incompleto (e) Verdaderos positivos: perfil (f) Verdaderos positivos: personas
y ocluido cercanas
(g) Falso positivo continuo (h) Falso positivo (i) Falso negativo: vista de perfil
con sensor Kinect a 30 cm del suelo, en ambientes interiores. Se recurrió a los clasificadores
entrenados incluidos en OpenCV para los detectores Haar y HOG, mientras que el detector
LBP utilizó una cascada externa; todos están entrenados para detección de peatones, tarea que
llevan a cabo en forma muy satisfactoria.
Los resultados en el limitado set de validación son de F0.5 mayor a 0,7, con precisiones de
hasta el 90 % y recuperación del 60 %. Más pruebas en línea mostraron tendencia a error en
patas de muebles, y en reflejos y sombras sobre superficies verticales. En promedio, el detector
HOG produjo mejores resultados. El sistema es preciso, y en general los falsos positivos que se
observan no son continuos en el tiempo. Si bien consideramos que los resultados obtenidos no son
confiables para la mayoría de las posibles aplicaciones, creemos pueden mejorarse para hacerse
útiles. Algunos factores que influyeron negativamente, en orden de importancia:
1. Los clasificadores utilizados fueron entrenados para condiciones muy distintas a los obje-
tivos de este trabajo. Detectan personas completas, de pie, de frente o de espalda, con
poca tolerancia a vistas de perfil o intermedias. Suponemos fueron entrenados con imágenes
tomadas desde una altura promedio de ojos humanos o alturas superiores como las utiliza-
das para posicionar cámaras de vigilancia. Las diferencias entre esta perspectiva y la de la
cámara del TurtleBot se acentúan a corta distancia — las habituales en los ambientes
objetivo de este trabajo.
2. Los sets de imágenes utilizados para optimizar no aportaron la diversidad suficiente.
Fue variada la orientación, posición y completitud de las personas en escena, pero fueron
29
9. Conclusiones
constantes la iluminación, la vestimenta, la altura de las personas, textura y color de piso

y paredes.
3. Para simplificar el análisis, los parámetros de los detectores fueron considerados indepen-
dientes entre sí, pero en realidad existen relaciones complejas entre varios de ellos.
9.2. Mejoras al trabajo realizado

Proponemos las siguientes mejoras:
Elevar la posición de la cámara, para reducir la distancia a partir de la cual una persona se
observa completa en la imagen. Esto incrementará tanto la precisión como la recuperación.
Hacer una mejor estimación de la altura real (ver 5.4.1). En lugar de usar la profundidad de
un solo punto, debería hacerse un promedio de varios o buscar una alternativa más robusta
ante oclusiones.
Superar las limitaciones del clasificador usado, ya sea con un modelo entrenado en interiores
y con mayor tolerancia a las vistas laterales, o entrenando uno específicamente para la
aplicación. En este caso, se puede decidir elevar el sensor Kinect para que los resultados
sean aplicables a una mayor proporción de otros desarrollos.
Para el entrenamiento, sea cual sea el clasificador elegido y una vez acotado el ámbito
de acción, se debe recopilar una gran cantidad de muestras positivas, asegurándose de que
contengan diversidad de posiciones, alturas, distancias, vestimenta, oclusiones, iluminación.
De igual manera, es importante añadir una todavía mayor cantidad de muestras negativas,
asegurándose de incluir a los elementos que más pueden confundirse con una persona; en
este trabajo observamos a las patas de sillas y mesas, las sombras de personas sobre la
pared y reflejos de personas sobre superficies reflectantes.
Utilizar más de un detector, en cascada y siguiendo el concepto utilizado por el detector en
cascada. Implicaría relajar los parámetros de los detectores para que tengan mayor recu-
peración, aunque pierdan precisión, que se logra al utilizar un detector sobre los resultados
del otro.
Utilizar la información temporal disponible al trabajar con videos. Una opción es hacer un
promedio temporal de los cuadros detectados, con la intención de eliminar aquellos falsos
positivos que aparecen esporádicamente. Otra, más compleja, es detectar el movimiento de
personas a través de la diferencia entre cuadros, pero se debe limitar, conocer o estimar el
movimiento del robot.
Hacer seguimiento de las personas detectadas. Puede ser una buena alternativa combinado
con un detector muy confiable, sacrificando capacidad de recuperación, o con el uso del
filtrado temporal.
9.3. Mejores alternativas

A lo largo de este trabajo obtuvimos un mejor entendimiento del problema y de las posibles
soluciones. Algo importante fue notar que los entornos típicos de oficina o laboratorio son muy
cerrados, y la escasa distancia existente entre el robot y una persona hacen difícil obtener una
imagen completa de esta, y por tanto es difícil pretender usar efectivamente detectores de per-
sonas completas. Podría solucionarse con lentes de gran angular, pero aún así existen escenarios
en donde la persona se ve incompleta durante la mayor parte del tiempo. Creemos que es una
buena decisión acudir a herramientas avanzadas que están diseñadas para este tipo de trabajo.
OpenNI y Nite son herramientas avanzadas que permiten reconocer a una persona en
posición natural incluso con oclusiones importantes, y luego realizan seguimiento. Si bien
la documentación existente no es mucha, OpenNI ha continuado lentamente su desarrollo
y continúa siendo de código abierto. El problema es que Nite, el middleware que realiza la
detección y seguimiento de personas, desapareció al ser comprada su empresa desarrollado-
ra; todavía se pueden usar las versiones antiguas que se distribuyen de manera no oficial,
30
9. Conclusiones
pero el producto ha sido discontinuado y eso implicará falta de compatibilidad con otras
plataformas de software o hardware.
Otra alternativa es recurrir al Kinect SDK (Software Developement Kit) de Microsoft,

pero únicamente está disponible para Microsoft Windows y las últimas versiones no
soportan al sensor Kinect para Xbox 360. Sin embargo, está en activo desarrollo por
quienes crearon y comercializan los sensores Kinect, permite interacción con Matlab y
OpenCV, y se permite su uso (bajo ciertas condiciones) en aplicaciones comerciales.
OpenPTrack es una alternativa abierta muy interesante que permite arreglos multi-
cámara. Los autores nos informaron que lo han usado satisfactoriamente desde un robot,
con la cámara a 1, 3 m de altura. Otro usuario afirma que, desde 0, 5 m de altura, su
problema es perder el seguimiento al desaparecer las cabezas de las personas.
9.4. Comentarios
Para la realización de este trabajo tuvimos la necesidad de conocer y aprender a usar herra-
mientas muy útiles y de amplio uso industrial: OpenCV y ROS. Tanto el desarrollar en ellos
como buscar alternativas, nos permitieron conocer características que desconocíamos e inferir
potenciales aplicaciones.
También fue nuestra primer experiencia en Linux (usando Ubuntu, Xubuntu y Kubuntu);
pudimos apreciar sus características de primera mano. No solo desarrollamos programas com-
plejos en los entornos Eclipe y Netbeans, sino que también recurrimos a otras herramientas,
como scripts de bash, ssh, entre otros. Incluso, para la escritura de este informe, utilizamos LATEX
a través de LYX. Para el control de versiones aprendimos Git, y siempre trabajamos colaborati-
vamente con las herramientas de Github21 . Si bien todo esto significó más tiempo de trabajo y
aprendizaje, pensamos que ha sido una buena inversión dirigida a incrementar nuestras aptitudes
profesionales y capacidades personales.
Intentamos aplicar un procedimiento científico ordenado para poder lograr conclusiones con-
cretas. Si bien los resultados no fueron los esperados, esperamos que sirvan de base para mejores
implementaciones. Recomendamos acudir continuamente al consejo de personas experimentadas
en la temática, para orientar bien los esfuerzos y el tiempo invertido. Esperamos en un futuro
cercano probar las alternativas mencionadas en 9.3 para comprobar su eficacia en la aplicación
objetivo de este trabajo.
Agradecemos al Grupo Estudiantil de Robótica de la Universidad Nacional de San
Juan (GERUNSJ) por permitirnos disponer de 2 robots TurtleBot, y al profesor Adrián
Orellana por sus apoyo y útiles recomendaciones. Agradecemos también a todas las personas
que comparten día a día sus problemas, soluciones y conocimientos, en diversas comunidades de
internet.
21 El código fuente de todos los programas, los sets de imágenes utilizados y

los resultados obtenidos, pueden descargarse desde https://github.com/GERUNSJ/
deteccion-de-personas-con-turtlebot-y-opencv-1
31
Referencias
Referencias
[1] Wikipedia, “iRobot Create — Wikipedia, The Free Encyclopedia.” https://en.wikipedia.
org/wiki/IRobot_Create, 2016. [Internet; descargado abril-2016]. 3
[2] ASUS, “Asus 1215N.” https://www.asus.com/Notebooks/Eee_PC_1215N. [Internet; des-

cargado abril-2016]. 3
[3] Wikipedia, “Kinect — Wikipedia, The Free Encyclopedia.” https://en.wikipedia.org/
wiki/Kinect, 2016. [Internet; descargado marzo-2016]. 3, 4
[4] OpenKinect wiki, “Imaging Information.” https://openkinect.org/wiki/Imaging_
Information, 2013. [Internet; descargado marzo-2016]. 4
[5] M. Sebastián Magallón and E. Montijano Muñoz, “Sistema interactivo para manejo de elec-
trodomésticos en entornos domésticos.” http://zaguan.unizar.es/record/12845, 2013.
4, 5
[6] ROS wiki, “Kinect accuracy.” http://wiki.ros.org/openni_kinect/kinect_accuracy,

2011. [Internet; descargado marzo-2016]. 5
[7] K. Konolige and P. Mihelich, “Technical description of Kinect calibration.” http://wiki.
ros.org/kinect_calibration/technical, 2012. [Internet; descargado marzo-2016]. 5, 18
[8] B. Freedman, A. Shpunt, M. Machline, and Y. Arieli, “Depth mapping using projected
patterns.” http://www.google.com/patents/US20100118123, May 13 2010. US Patent
App. 12/522,171. 5
[9] D. Scharstein and R. Szeliski, “High-Accuracy Stereo Depth Maps Using Structured Light,”
in CVPR (1), (http://research.microsoft.com/pubs/75606/Scharstein-CVPR03.pdf),
pp. 195–202, IEEE Computer Society, 2003. 5
[10] Kinect for Matlab, “Modo de funcionamiento normal.” http://kinectformatlab.es.tl/

MODO-DE-FUNCIONAMIENTO-NORMAL.htm. [Internet; descargado abril-2016]. 5
[11] J. Nuño Simón, “Reconocimiento de objetos mediante sensor 3D Kinect.” http://
e-archivo.uc3m.es/handle/10016/16917, 2012. 5
[12] J. Smisek, M. Jancosek, and T. Pajdla, “3D with Kinect.,” in ICCV Workshops, (http:
//cmp.felk.cvut.cz/ftp/articles/pajdla/Smisek-CDC4CV-2011.pdf), pp. 1154–1160,
IEEE, 2011. 5
[13] R. P. Foundation, “Raspberry Pi 2 model B.” https://www.raspberrypi.org/products/
raspberry-pi-2-model-b. [Internet; descargado abril-2016]. 6
[14] Open Source Robotics Foundation, “Robot Operating System.” http://www.ros.org, 2016.
7
[15] Wikipedia, “Sistema Operativo Robótico — Wikipedia, La enciclopedia libre.” https://es.
wikipedia.org/wiki/Sistema_Operativo_Robótico, 2015. [Internet; descargado abril-
2016]. 7
[16] Itseez, “Open Source Computer Vision Library.” http://opencv.org. 7
[17] OpenCV, “OpenCV 2.4 Documentation: Cascade Classification.” http://docs.opencv.
org/2.4/modules/objdetect/doc/cascade_classification.html. [Internet; descargado
marzo-2016]. 8, 13, 15
[18] P. Viola and M. Jones, “Rapid Object Detection using a Boosted Cascade of Simple Featu-
res,” in Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition,
(Hawaii), 2001. 8, 13, 14
32
Referencias
[19] T. Ojala, M. Pietikäinen, and T. Mäenpää, “Multiresolution gray-scale and rotation in-
variant texture classification with local binary patterns,” Pattern Analysis and Machine
Intelligence, IEEE Transactions on, vol. 24, no. 7, pp. 971–987, 2002. 8, 14
[20] OpenCV, “OpenCV 2.4 Documentation: HOG.” http://docs.opencv.org/2.4/modules/
gpu/doc/object_detection.html#gpu-hogdescriptor. [Internet; descargado marzo-
2016]. 9, 10, 12
[21] N. Dalal and B. Triggs, “Histograms of Oriented Gradients for Human Detection,” in Pro-
ceedings of the IEEE Conference on Computer Vision and Pattern Recognition, (San Diego,
USA), 2005. 9, 10
[22] OpenCV, “OpenCV 2.4 Documentation: Latent SVM.” http://docs.opencv.org/2.4/
modules/objdetect/doc/latent_svm.html. [Internet; descargado marzo-2016]. 9
[23] P. F. Felzenszwalb, R. B. Girshick, D. A. McAllester, and D. Ramanan, “Object Detec-
tion with Discriminatively Trained Part-Based Models.,” IEEE Trans. Pattern Anal. Mach.
Intell., vol. 32, no. 9, pp. 1627–1645, 2010. 9
[24] Tim Field and Marcus Liebhardt, “ROS package: Openni tracker.” http://wiki.ros.org/
openni_tracker, 2013. [Internet; descargado marzo-2016]. 9
[25] Igalia, “Skeltrack.” https://github.com/joaquimrocha/Skeltrack, 2013. 9
[26] A. Baak, M. Müller, G. Bharaj, H. P. Seidel, and C. Theobalt, “A data-driven approach for
real-time full body pose reconstruction from a depth camera,” in Computer Vision (ICCV),
2011 IEEE International Conference on, pp. 1092–1099, Nov 2011. 9
[27] M. Munaro, C. Lewis, D. Chambers, P. Hvass, and E. Menegatti, “RGB-D Human Detection
and Tracking for Industrial Environments.,” in IAS (E. Menegatti, N. Michael, K. Berns, and
H. Yamaguchi, eds.), vol. 302 of Advances in Intelligent Systems and Computing, pp. 1655–
1668, Springer, 2014. 9
[28] M. Munaro, C. Lewis, D. Chambers, P. Hvass, E. Menegatti, and S. Edwards, “ROS package:
Human tracker.” https://github.com/ros-industrial/human_tracker, 2013. [Internet;
descargado marzo-2016]. 9
[29] University of California, “OpenPTrack.” http://openptrack.org, 2016. 9
[30] M. Munaro, F. Basso, and E. Menegatti, “OpenPTrack: Open source multi-camera calibra-
tion and people tracking for RGB-D camera networks.,” Robotics and Autonomous Systems,
vol. 75, pp. 525–538, 2016. 9
[31] M. Munaro, A. Horn, R. Illum, J. Burke, and R. B. Rusu, “OpenPTrack: People Tracking
for Heterogeneous Networks of Color-Depth Cameras,” 2014. 9
[32] C. McCormick, “HOG person detector tutorial.” https://chrisjmccormick.wordpress.
com/2013/05/09/hog-person-detector-tutorial, 2013. [Internet; descargado abril-
2016]. 10
[33] Wikipedia, “Máquinas de vectores de soporte — Wikipedia, La enciclopedia libre.” https:
//es.wikipedia.org/wiki/Máquinas_de_vectores_de_soporte, 2015. [Internet; descar-
gado abril-2016]. 10
[34] M. Enzweiler and D. M. Gavrila, “Monocular Pedestrian Detection: Survey and Experi-
ments,” IEEE Trans. Pattern Anal. Mach. Intell., vol. 31, no. 12, pp. 2179–2195, 2009.
12
[35] R. Lienhart, A. Kuranov, and V. Pisarevsky, “Empirical Analysis of Detection Cascades of
Boosted Classifiers for Rapid Object Detection,” in Proceedings of the 25th DAGM Sympo-
sium on Pattern Recognition, (Magdeburg, Germany), 2003. 14
[36] M. Pietikäinen, “Local Binary Patterns,” Scholarpedia, vol. 5, no. 3, p. 9775, 2010. revision
#137418 http://www.scholarpedia.org/article/Local_Binary_Patterns. 15
33
Referencias
[37] P. Wagner, “Local Binary Patterns.” http://bytefish.de/blog/local_binary_patterns,

2011. [Internet; descargado abril-2016]. 15
[38] A. Rosebrock, “Local Binary Patterns with Python and OpenCV.” http://www.
pyimagesearch.com/2015/12/07/local-binary-patterns-with-python-opencv, 2015.
[Internet; descargado abril-2016]. 15
[39] H. Kruppa, M. Castrillon-Santana, and B. Schiele, “Fast and robust face finding via local
context,” pp. 157–164, 2003. 16
[40] M. Castrillón, O. Déniz, C. Guerra, and M. Hernández, “ENCARA2: Real-time detection

of multiple faces at different resolutions in video streams.,” J. Visual Communication and
Image Representation, vol. 18, no. 2, pp. 130–140, 2007. 16
[41] Vision-Ary Team, “Boost the World: Pedestrian Detection.” http://www.vision-ary.net/
2015/03/boost-the-world-pedestrian, 2015. [Internet; descargado abril-2016]. 16, 26
[42] E. CV, “Emgu CV 1.5 Library Documentation: HAAR_DETECTION_TYPE
Enumeration.” http://www.emgu.com/wiki/files/1.5.0.0/Help/html/
e2278977-87ea-8fa9-b78e-0e52cfe6406a.htm, 2008. [Internet; descargado abril-2016].
16
[43] Wikipedia, “3D Projection — Wikipedia, The Free Encyclopedia.” https://en.wikipedia.

org/wiki/3D_projection#Diagram, 2016. [Internet; descargado abril-2016]. 18
[44] ROS wiki, “Using CvBridge to convert between ROS images
and OpenCV images.” http://wiki.ros.org/cv_bridge/Tutorials/
UsingCvBridgeToConvertBetweenROSImagesAndOpenCVImages, 2015. [Internet; des-
cargado marzo-2016]. 22
[45] ROS wiki, “Robots: TurtleBot.” http://wiki.ros.org/Robots/TurtleBot, 2015. [Inter-
net; descargado marzo-2016]. 23
[46] fpasteau, “Groovy ROS node for camera module of Raspberry Pi.” https://github.com/
fpasteau/raspicam_node, 2015. [Internet; descargado abril-2016]. 23
34
A. Apéndice: Estructura de archivos
A. Apéndice: Estructura de archivos

informe_Aguado_Emder.pdf — Este informe
evaluacion/ — Lo referido a la evaluación de algoritmos
evaluacion/clasificadores/ — Los clasificadores utilizados
evaluacion/ejecutables/ — Ejecutables compilados para Linux x64
evaluacion/resultados/ — Resultados sobre los sets de prueba
evaluacion/scripts/ — Scripts de evaluación
evaluacion/src/ — Código fuente de los programas de evaluación
implementacion/ — Nodos de ROS para funcionamiento en línea. Ver Apéndice B
otros/calibracion_turtlebot/ — Archivos de calibración de las cámaras
otros/raspicam_node-master.zip — Nodo Raspicam
resultados/ — Imágenes y videos de los resultados sobre los sets de prueba y validación
35
B. Apéndice: Nodos
B. Apéndice: Nodos
El workspace de ROS contiene el nodo de detección y un nodo publicador de video para la
webcam. Para poder ejecutarlos, primero hay que compilarlos.
Los pasos a seguir:
1. Modificar el código (src/detpeople/src/ImageConverter.cpp, líneas 48 y 51) para que

se suscriba a los mensajes de la Kinect o de la webcam o de la cámara de la Raspberry
Pi. Por defecto está suscripto a los mensajes bajo el topic /camera/image , que son los de
la webcam o de la cámara de la Raspberry.
2. Compilar:
a) Situarse dentro de la carpeta implementacion
b) Ejecutar catkin_make . Esto compila los nodos.
c) Se le informa a ROS la existencia de esos paquetes con source devel/setup.bash
3. Se ejecutan los nodos 22
con rosrun
a) [Opcional] rosrun detpeople publicador_video — Ejecuta un nodo que publica
video desde la webcam de la PC.
b) rosrun detpeople detpeople — Ejecuta el detector.
Para recibir imágenes desde el TurtleBot, ver 7.2. Para transmitir imágenes desde la Rasp-
berry Pi, referirse a 7.3; el nodo Raspicam se puede compilar de forma similar a lo realizado
en el punto 2 anterior.
22 Cada nodo se ejecuta en una terminal o consola diferente.
36

Informe Aguado Emder

Cargado por

Copyright:

Formatos disponibles

Informe Aguado Emder

Cargado por

Información del documento

Descripción original:

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

Informe Aguado Emder

Cargado por

Copyright:

Formatos disponibles

Facultad de Ingeniería

Departamento de Electrónica y Automática

Temas Específicos de Control 1: Visión Artificial

DETECCIÓN DE PERSONAS PARA UN ROBOT

3. Con qué se trabajó 3

A. Apéndice: Estructura de archivos 35

3. Con qué se trabajó

3.1. ¿Qué es un TurtleBot?

Estructura de madera y aluminio para llevar la netbook, el controlador Kinect y accesorios

3.2. ¿Qué es un Microsoft Kinect?

Figura 2: Sensor Kinect

Figura 3: Patrón de puntos proyectado — Luz estructurada.

Figura 4: Modelo geométrico de las cámaras de la Kinect

3.3. ¿Qué es una Raspberry PI 2?

Puerto SCI para cámara.

Figura 5: Imágenes de profundidad de la Kinect

(a) Original, convertida a 8 bits (b) Normalizada, convertida a 8 bits

Resolucion 8-/10 bits

Figura 6: Raspberry Pi 2 y cámara

3.4. ¿Qué es ROS?

4.1. Desarrollo de un detector

4 Sólo se trabajó con la imagen de profundidad.

1. Segmentación según el histograma de intensidad de la imagen de profundidad.

El proceso de segmentación y filtrado fue satisfactorio en el corto rango en que la persona se

4.2. Detectores integrados en OpenCV

4.3. OpenNI Tracker de ROS

4.5. Human Tracker de ROS

tornaba inútil para el objetivo buscado.

en gestos del usuario. Estandariza formatos y forma de acceder a los dispositivos.

cerrado, desarrollado por PrimeSense.

Se pudo hacer funcionar en la instalación de ROS Indigo existente, pero ocasionalmente

5.1. HOG + SVM

b) Se agrupan las magnitudes en un histograma de 9 clases o bins, correspondientes a un

3. Se agrupan los resultados de cada bloque en un único vector descriptor.

Figura 7: Cálculo del gradiente horizontal Figura 8: Imágenes de las componentes

(a) Gradiente horizontal

(b) Gradiente vertical

Figura 9: Vector gradiente resultante

Estos argumentos corresponden a parámetros internos del detector. La mayoría no se puede

DefaultPeopleDetector, entrenado con imágenes de 64 ∗ 128 px. Puede usarse con

Para detectar en una imagen, se utiliza:

Los argumentos son:

img Imagen objetivo.

padding Píxeles de relleno en los bordes de la imagen. En este trabajo es Size(0,0) .

Figura 11: Funcionamiento de groupRectangles

finalThreshold Umbral de cantidad para agrupación de detecciones. Hace un llamado a la función

5.2. Cascada de clasificadores

12 cv::groupRectangles(vector<Rect>& rectList, int groupThreshold, double eps=0.2) — Agrupa los rec-

Figura 12: Cascada de clasificadores

5.2.3. Haar-like features

5.2.4. LBP features

Figura 13: Prototipos de features Haar-like usados en OpenCV

Figura 14: Principio de funcionamiento de los patrones binarios locales

Luego se puede computar el histograma de la “imagen” obtenida y así codificar todo en un

Se puede cargar un modelo de cascada entrenado con el método load:

detector . load ( direccion_a_cascada ) ;

El archivo cargado determinará si se utilizan features LBP o Haar-like. En este trabajo se

haarcascade_mcs_upperbody, entrenado con imágenes de 14 ∗ 20 px, de cabeza y

vision-ary.net, entrenada con imágenes de 26 ∗ 74 px. [41]