UNIVERSIDAD CENTROAMERICANA

JOSÉ SIMEÓN CAÑAS

SISTEMA PARA CONTROL DE BRAZO ROBÓTICO Y

RECONOCIMIENTO AUTÓNOMO DE OBJETOS MEDIANTE
SENSORES ÓPTICOS DE REALIDAD AUMENTADA PARA
EXTREMIDADES SUPERIORES Y VISIÓN POR COMPUTADORA

TRABAJO DE GRADUACIÓN PREPARADO PARA LA

FACULTAD DE INGENIERÍA Y ARQUITECTURA

PARA OPTAR AL GRADO DE

LICENCIADO EN CIENCIAS DE LA COMPUTACIÓN

POR:
RONALDO ARMANDO CANIZALES TURCIOS
BORIS ENRIQUE FRANCO ZELAYA
ALEJANDRA GUADALUPE MOLINA FLORES
RODOLFO ENRIQUE MONGE CÓRDOVA

ANTIGUO CUSCATLÁN, EL SALVADOR, C.A.

 RECTOR
ANDREU OLIVA DE LA ESPERANZA, S.J.

SECRETARIA GENERAL
SILVIA ELINOR AZUCENA DE FERNÁNDEZ

DECANO DE LA FACULTAD DE INGENIERÍA Y ARQUITECTURA

CARLOS GONZALO CAÑAS GUTIÉRREZ

COORDINADOR DE LA CARRERA DE LICENCIATURA EN

CIENCIAS DE LA COMPUTACIÓN
ÁNGEL FERNANDO DUARTE NOVOA

DIRECTOR DEL TRABAJO

GUILLERMO ERNESTO CORTÉS VILLEDA

LECTOR
ÁNGEL FERNANDO DUARTE NOVOA
 ÍNDICE

RESUMEN........................................................................................................................................... i

ÍNDICE DE FIGURAS ....................................................................................................................... ii

ÍNDICE DE TABLAS ....................................................................................................................... vi

SIGLAS ............................................................................................................................................ viii

NOMENCLATURA ........................................................................................................................... x

CAPÍTULO 1. INTRODUCCIÓN...................................................................................................... 1
1.1 Definición del problema............................................................................................................ 1
1.2 Objetivos ................................................................................................................................... 2
1.2.1 Objetivo general ................................................................................................................. 2
1.2.2 Objetivos específicos ......................................................................................................... 2
1.3 Límites y alcances ..................................................................................................................... 3
1.4 Antecedentes ............................................................................................................................. 4
1.4.1 Antecedentes directos......................................................................................................... 4
1.4.2 Antecedentes bibliográficos ............................................................................................... 8
CAPÍTULO 2. MARCO TEÓRICO ................................................................................................. 11
2.1 Tecnología Arduino ................................................................................................................ 11
2.1.1 Hardware de Arduino ....................................................................................................... 11
2.1.2 Software de Arduino ........................................................................................................ 12
2.1.3 Comunicación serial en placas Arduino ........................................................................... 13
2.1.4 Tecnología Bluetooth ....................................................................................................... 14
2.1.4 Bus I2C ............................................................................................................................ 15
2.1.5 Pantalla LCD .................................................................................................................... 16
2.2 Sensor Kinect .......................................................................................................................... 17
2.2.1 Hardware del sensor Kinect ............................................................................................. 18
2.2.2 Kit de desarrollo de software de Kinect para Windows ................................................... 22
2.3 Sensor Leap Motion ................................................................................................................ 24
2.3.1 Estructura externa del sensor Leap Motion ...................................................................... 24
2.3.2 Hardware interno del sensor Leap Motion ....................................................................... 25
2.3.3 Software de Leap Motion ................................................................................................. 26
2.4 Realidad aumentada ................................................................................................................ 31
2.4.1 Aplicaciones de la realidad aumentada ............................................................................ 32
2.5 Visión por computadora .......................................................................................................... 35
 2.5.1 Imágenes digitales ............................................................................................................ 36
2.5.2 Open Source Computer Vision Library (OpenCV) .......................................................... 40
2.6 Funcionalidades o herramientas matemáticas de minería de datos ......................................... 40
2.6.1 Modelos de clasificación .................................................................................................. 40
2.6.2 Técnicas de agrupamiento (clustering) ............................................................................. 41
2.6.3 Medición de la precisión de un clasificador ..................................................................... 43
CAPÍTULO 3. METODOLOGÍA Y HERRAMIENTAS ................................................................. 45
3.1 Reunión inicial ........................................................................................................................ 45
3.2 Reunión con el coordinador de la carrera de ingeniería eléctrica............................................ 45
3.3 Comprensión del funcionamiento de los sensores................................................................... 45
3.4 Análisis del hardware y software del brazo robótico original ................................................. 46
3.5 Herramientas del Leap Motion ................................................................................................ 46
3.6 Gestos del Leap Motion .......................................................................................................... 47
3.7 Parámetros utilizados en Hidrología Superficial ..................................................................... 47
3.8 Especificaciones técnicas de la computadora utilizada para el desarrollo de la plataforma de
escritorio ........................................................................................................................................ 48
3.11 Utilización del sensor Kinect desde Windows Forms ........................................................... 51
3.12 Elección del lenguaje de programación y herramientas de software a utilizar ...................... 51
3.13 Cálculo empírico de la latencia en la plataforma de escritorio.............................................. 52
3.14 Cálculo del porcentaje de uso de los servomotores ............................................................... 53
CAPÍTULO 4. ANÁLISIS Y DISEÑO............................................................................................. 55
4.1 Descripción general ................................................................................................................. 55
4.2 Plataforma de escritorio........................................................................................................... 56
4.3 Panel de conexión.................................................................................................................... 57
4.3.1 Inicializar Leap Motion .................................................................................................... 57
4.3.2 Inicializar Kinect .............................................................................................................. 58
4.3.3 Inicializar Módulos Bluetooth .......................................................................................... 60
4.4 Imitación de movimientos en tiempo real ............................................................................... 60
4.4.1 Cálculos realizados con datos provistos por los sensores................................................. 61
4.4.2 Graficación de datos calculados ....................................................................................... 66
4.4.3 Ensamblaje de paquetes de datos que se enviarán al tablero indicador ............................ 67
4.4.4 Tablero indicador ............................................................................................................. 68
4.5 Grabación de movimientos para posterior reproducción ......................................................... 70
4.6 Reproducción de movimientos pre-grabados .......................................................................... 72
4.7 Reconocimiento autónomo de objetos..................................................................................... 73
 4.7.1. Diseño y elaboración de figuras (clases del modelo) ...................................................... 74
4.7.2. Obtención de imágenes o fotografías para el conjunto de entrenamiento ....................... 75
4.7.3. Extracción de características del conjunto de entrenamiento .......................................... 77
4.7.4. Generación del modelo clasificador que trabaja en base a la distancia ........................... 81
4.7.5. Generación del modelo clasificador de figuras que trabaja en base al color................... 84
4.7.6. Cálculo de la precisión del clasificador (validación del modelo matemático) ................ 86
CAPÍTULO 5. PRUEBAS Y DEPURACIÓN ................................................................................. 91
5.1 Pruebas de Imitación de movimientos en tiempo real............................................................. 91
5.2 Pruebas de Grabación de secuencias de movimientos ............................................................ 99
5.3 Pruebas de Reconocimiento de objetos ................................................................................. 101
CAPÍTULO 6. CONCLUSIONES Y RECOMENDACIONES ..................................................... 107
6.1 Conclusiones ......................................................................................................................... 107
6.2 Recomendaciones.................................................................................................................. 108
GLOSARIO .................................................................................................................................... 111
REFERENCIAS .............................................................................................................................. 113
ANEXOS
ANEXO A. Código fuente C++: clasificador en base a distancia
ANEXO B. Código fuente C++: clasificador en base a colores
ANEXO C. Código fuente Arduino: control de brazo derecho
ANEXO D. Código fuente Arduino: control de brazo izquierdo
ANEXO E. Código fuente Arduino: control de mano derecha
ANEXO F. Código fuente Arduino: control de mano izquierda
ANEXO G. Pantallas plataforma de escritorio
ANEXO H. Diagramas de circuitos del tablero indicador de ledes
 RESUMEN

El Departamento de Electrónica e Informática (DEI) de la Universidad Centroamericana “José

Simeón Cañas” (UCA) tiene a su disposición una extremidad superior robótica, resultado de un
trabajo de graduación realizado por estudiantes de la carrera de ingeniería eléctrica en el año 2017.
Su implementación física cumple con la función para la que fue diseñado, es decir,
es capaz de reproducir de manera precisa los movimientos de una persona.

El dispositivo posee un gran potencial, sin embargo su software se limita a la realización de una
única tarea: la imitación de movimientos en tiempo real. Aquí surge la necesidad de ampliar la
gama de situaciones prácticas en que este puede ser utilizado. El presente trabajo describe
detalladamente el proceso de creación de un nuevo sistema que implementa mayor cantidad de
funcionalidades, desde la etapa de diseño hasta la implementación y realización de pruebas.

Dicho sistema posee los siguientes módulos: imitación de movimientos en tiempo real,
reconocimiento de objetos y además la grabación, depuración y posterior reproducción
de secuencias de movimientos. Para esto se utilizaron dos sensores de realidad aumentada (Kinect
y Leap Motion), además de algoritmos de visión por computadora y de minería de datos.

El contenido del trabajo está estructurado en seis capítulos. En el capítulo 1 se definen los objetivos,
límites y alcances de la investigación. El capítulo 2 contiene todas las premisas necesarias para
comprender el resto del documento (realidad aumentada, sensores ópticos, visión por computadora,
minería de datos y la tecnología Arduino). El capítulo 3 menciona algunas herramientas que fueron
útiles para la elaboración del sistema así como una descripción de las etapas de concepción del
proyecto. El capítulo 4 describe detalladamente cada uno de los componentes que integran el
sistema, así como su funcionamiento teórico. El capítulo 5 muestra dieciocho pruebas realizadas al
sistema, distribuidas en sus distintos componentes con el fin de validar su comportamiento en
escenarios tanto idóneos como reales.

Finalmente, en el capítulo 6 se proponen recomendaciones tomando en cuenta las conclusiones a las

que se ha llegado después del trabajo de graduación; recomendaciones que pueden ser consideradas
para futuras investigaciones. Además se incluyen los anexos y las fuentes bibliográficas
consultadas.

i
 ÍNDICE DE FIGURAS

Figura 1.1. Brazo robótico del DEI y sus partes.................................................................................. 5

Figura 1.2. Mano y muñeca del brazo unidas a la base rotacional y al soporte base .......................... 5
Figura 1.3. Antebrazo del dispositivo ................................................................................................. 6
Figura 1.4. Estructura interna del bíceps ............................................................................................. 6
Figura 1.5. Ubicación de los dos servomotores encargados de los movimientos del hombro ............ 6
Figura 1.6. Guante con sensores de flexión......................................................................................... 7
Figura 1.7. Esquema de comunicación entre los dispositivos de control del brazo robótico del DEI 8
Figura 1.8. Estructura de la mano robótica junto con su sistema de control ....................................... 9
Figura 1.9. Imagen del robot industrial modelo Kuka KR 125/3 ...................................................... 10
Figura 2.1. Diferentes versiones de placas Arduino disponibles en el mercado ............................... 12
Figura 2.2. Ejemplo de un sketch codificado usando el IDE de Arduino.......................................... 13
Figura 2.3. Módulos de comunicación Bluetooth: ............................................................................ 15
Figura 2.4. Estructura de un bus I2C ................................................................................................. 16
Figura 2.5. Pantalla LCD modelo 1602 I2C ...................................................................................... 17
Figura 2.6. Partes del sensor Kinect .................................................................................................. 18
Figura 2.7. Ángulos de visión de la cámara del sensor Kinect .......................................................... 19
Figura 2.8. Luz infrarroja proyectada en forma de patrón de puntos ................................................ 19
Figura 2.9. Rangos de distancia interpretados por el sensor Kinect .................................................. 20
Figura 2.10. Estructura interna del motor de inclinación del sensor Kinect ..................................... 20
Figura 2.11. Ángulos de inclinación permitidos por el motor del sensor Kinect .............................. 21
Figura 2.12. Ubicación y distancia de separación de los cuatro micrófonos integrados en el sensor
Kinect ................................................................................................................................................ 21
Figura 2.13. Entorno del Kinect for Windows Developer Toolkit v1.8.0 ......................................... 23
Figura 2.14. Componentes del Developer Toolkit y del Kinect for Windows SDK ......................... 23
Figura 2.15. Kinect Management dentro de la lista de servicios de Microsoft Windows 10 ............ 24
Figura 2.16. Estructura externa del sensor Leap Motion .................................................................. 25
Figura 2.17. a) Estructura interna del sensor Leap Motion ............................................................... 25
Figura 2.18. Dimensiones del área de interacción 3D que ofrece el sensor Leap Motion ................ 26
Figura 2.19. Esquema sobre el funcionamiento de la Interfaz de Aplicación Nativa ....................... 27
Figura 2.20. Sistema de coordenadas 3D del sensor Leap Motion.................................................... 28
Figura 2.21. Representación visual de los vectores ........................................................................... 30
Figura 2.22. Representación visual de los vectores Tip Position y Direction de la API de Leap
Motion ............................................................................................................................................... 30

ii
Figura 2.23. Modelo de huesos utilizado por Leap Motion .............................................................. 31
Figura 2.24. Software VitalStream operando a través del dispositivo Google Glass ....................... 32
Figura 2.25. Feto virtual dentro del vientre de una mujer embarazada ............................................. 33
Figura 2.26. Avión virtual generado por el software Fused Reality ................................................. 34
Figura 2.27. Realidad aumentada a través de las consolas................................................................ 34
Figura 2.28. Representación de una imagen digital mediante una matriz de 35x35 ......................... 36
Figura 2.29. Imagen a) original junto con su imagen en b) escala de grises ..................................... 37
Figura 2.30. Ejemplo de una imagen binaria .................................................................................... 37
Figura 2.31. Modelo RGB................................................................................................................. 38
Figura 2.32. Imagen en escala de grises junto con su respectivo histograma ................................... 39
Figura 2.33. Imagen a) en escala de grises b) junto al resultado de su umbralización...................... 40
Figura 2.34. Ejemplo de un árbol de decisión ................................................................................... 41
Figura 2.35. Algoritmo básico de k-means ....................................................................................... 42
Figura 2.36. Clusterización de un conjunto de objetos usando k-means .......................................... 42
Figura 2.37. Ejemplos de matrices de confusión .............................................................................. 44
Figura 3.1. Herramienta interpretada por el sensor Leap Motion ..................................................... 47
Figura 3.2. Gestos que provee el Leap Motion ................................................................................. 47
Figura 3.3. Interfaz gráfica del complemento Rattle. ........................................................................ 49
Figura 3.4. Curva ROC generada utilizando la herramienta Rattle................................................... 49
Figura 3.5. Prototipo que implementa el algoritmo camshift utilizando la cámara a color del sensor
Kinect ................................................................................................................................................ 50
Figura 3.6. Archivo de valores separados por coma ......................................................................... 52
Figura 4.1. Estructura general del sistema. ....................................................................................... 55
Figura 4.2. Estructura general de la plataforma de escritorio ........................................................... 56
Figura 4.3. Diagrama de casos de uso de la plataforma de escritorio ............................................... 57
Figura 4.4. Consulta realizada al WMI ............................................................................................. 60
Figura 4.5. Proceso de imitación en tiempo real ............................................................................... 60
Figura 4.6. a) Vector Hand.Direction, b) vectores Finger.Direction, c) ángulo devuelto por la
operación Vector.AngleTo ................................................................................................................ 61
Figura 4.7. Articulaciones reconocidas por el Kinect v1 .................................................................. 62
Figura 4.8. a) Triángulo oblicuángulo, b) dos puntos en R3, c) triángulo rectángulo ...................... 62
Figura 4.9. Coordenadas de un hombro central, hombro derecho y codo derecho ........................... 64
Figura 4.10. Ángulo de abertura vertical del hombro ....................................................................... 64
Figura 4.11. Ángulo de abertura horizontal del hombro ................................................................... 65
Figura 4.12. Articulaciones interpretadas por la plataforma de escritorio ........................................ 66

iii
Figura 4.13. Huesos de las manos interpretadas por plataforma de escritorio .................................. 67
Figura 4.14. a) Programa esclavo de control del brazo, b) programa maestro de control de los
dedos, c) programa esclavo de control de los dedos ......................................................................... 67
Figura 4.15. Conversión de un flotante a un arreglo (conjunto) de bytes ......................................... 68
Figura 4.16. Interacción plataforma de escritorio y tablero indicador .............................................. 68
Figura 4.17. Estructura base del software de las placas Arduino ...................................................... 69
Figura 4.18. Proceso general de grabación de secuencias de movimientos ...................................... 70
Figura 4.19. Proceso general de reproducción de movimientos pre-grabados .................................. 72
Figura 4.20. Animación generada a partir de archivos de secuencias de movimientos .................... 72
Figura 4.21. Esquema general del proceso de reconocimiento de objetos ........................................ 73
Figura 4.22. Figuras a clasificar en base a su color ........................................................................... 74
Figura 4.23. Figuras utilizadas para la clasificación en base a distancia........................................... 75
Figura 4.24. Fotografías tomadas para entrenar clasificador en base a distancia .............................. 76
Figura 4.25. Fotografías tomadas para entrenar clasificador en base a color .................................... 77
Figura 4.26. Fotografía original a colores, no posee tratamiento alguno .......................................... 78
Figura 4.27. Regiones recortadas de imagen original ....................................................................... 78
Figura 4.28. Imágenes binarizadas utilizando umbral personalizado ................................................ 79
Figura 4.29. Contornos obtenidos a partir de imágenes binarizadas ................................................. 80
Figura 4.30. a) Rectángulo rotado de área mínima, b) envolvente convexa, c) triángulo de área
mínima, d) elipse que asemeja contorno, e) círculo de área mínima que envuelve la figura ........... 81
Figura 4.31. Programa escrito en R que grafica en 3D el conjunto de entrenamiento ...................... 81
Figura 4.32. Implementación de K-means en R ................................................................................ 82
Figura 4.33. Visualización de los clusters generados por K-means .................................................. 82
Figura 4.34. Variables que no caracterizan bien a las figuras ........................................................... 83
Figura 4.35. Variables que caracterizan muy bien cada clase de figuras .......................................... 83
Figura 4.36. Modelo de clasificación de figuras en base a distancia................................................. 84
Figura 4.37. Visualización en tres dimensiones de los datos de entrenamiento correspondientes a
los colores del margen y de las figuras.............................................................................................. 84
Figura 4.38. Componentes de los colores negro, blanco, rojo, verde y azul ..................................... 85
Figura 4.39. Distintas combinaciones de componentes de color ....................................................... 85
Figura 4.40. Modelo de clasificación de colores ............................................................................... 86
Figura 4.41. Modelo de clasificación de figuras en base a color....................................................... 86
Figura 4.42. a) Región denominada marco o fondo de la escena, b) figura que corresponde a la
silueta de un Cuadro grande ............................................................................................................. 88
Figura 5.1. Tomas realizadas a: a) 70 cm, b) 80 cm y c) 1 m............................................................ 91
Figura 5.2. Tomas realizadas a: a) 1.2 m, b) 1.5 m, c) 2 m y d) 2.5 m .............................................. 92

iv
Figura 5.3. Tomas realizadas a: a) 3.5 m, b) 3.75 m y c) 4 m ........................................................... 93
Figura 5.4. Tomas para una y ambas manos realizadas a: a) 10 cm, b) 20 cm ................................. 94
Figura 5.5. Tomas para una y ambas manos realizadas a: a) 30 cm, b) 40 cm ................................. 95
Figura 5.6. Tomas para una y ambas manos realizadas a: a) 50 cm, b) 60 cm ................................. 95
Figura 5.7. Iluminación excesiva frente a: a) sensor Kinect y b) sensor Leap Motion ..................... 96
Figura 5.8. Sensores operando bajo nula iluminación ...................................................................... 97
Figura 5.9. Superposición de objetos ................................................................................................ 98
Figura 5.10. Siluetas reflejadas en espejos........................................................................................ 99
Figura 5.11. Fotografías tomadas con excesiva iluminación .......................................................... 102
Figura 5.12. Fotografías tomadas con iluminación casi nula .......................................................... 103
Figura 5.13. Fotografías tomadas con ninguna figura en escena .................................................... 104
Figura 5.14. a) Imagen homogénea, b) imagen binarizada y c) silueta aleatoria encontrada ......... 104
Figura 5.15. Fotografías con figuras del mismo color de la escena ................................................ 105
Figura 5.16. Fotografías tomadas con iluminación casi nula .......................................................... 105

v
 ÍNDICE DE TABLAS

Tabla 2.1. Clasificación de los dispositivos Bluetooth según su potencia y rango de transmisión. .. 15
Tabla 2.2. Datos recolectados por el sensor Leap Motion................................................................. 29
Tabla 3.1. Requisitos mínimos de la computadora a utilizar............................................................. 48
Tabla 3.2. Herramientas de software utilizadas para la realización del proyecto.............................. 51
Tabla 3.3. Especificaciones técnicas servomotores. .......................................................................... 53
Tabla 4.1. Distribución del procesamiento de frames ofrecidos por el Leap Motion. ...................... 58
Tabla 4.2. Distribución del procesamiento de frames ofrecidos por el sensor Kinect. ..................... 59
Tabla 4.3. Rangos de distancia al sensor Kinect. .............................................................................. 66
Tabla 4.4. Estructura de los archivo de secuencias de movimientos. ................................................ 71
Tabla 4.5. Matriz de confusión del clasificador por distancia. .......................................................... 87
Tabla 4.6. Matriz de confusión del clasificador por color. ................................................................ 87
Tabla 4.7. Matriz de confusión del clasificador de colores aplicado a los marcos............................ 88
Tabla 4.8. Matriz de confusión del clasificador de colores aplicado a las figuras. ........................... 89
Tabla 4.9. Precisión de cada clase del clasificador de figuras por distancia. .................................... 89
Tabla 5.1. Formato de registro de realización de pruebas. ................................................................ 91
Tabla 5.2. Registro de la primer prueba realizada. ............................................................................ 92
Tabla 5.3. Registro de la segunda prueba realizada. ......................................................................... 92
Tabla 5.4. Registro de la tercer prueba realizada. ............................................................................. 93
Tabla 5.5. Registro de la cuarta prueba realizada .............................................................................. 94
Tabla 5.6. Registro de la quinta prueba realizada ............................................................................. 94
Tabla 5.7. Registro de la sexta prueba realizada ............................................................................... 95
Tabla 5.8. Registro de la séptima prueba realizada ........................................................................... 96
Tabla 5.9. Registro de la octava prueba realizada ............................................................................. 97
Tabla 5.10. Registro de la novena prueba realizada .......................................................................... 98
Tabla 5.11. Registro de la décima prueba realizada .......................................................................... 99
Tabla 5.12. Registro de la undécima prueba realizada .................................................................... 100
Tabla 5.13. Características de archivos CSV generados durante las pruebas al módulo de grabación
de secuencias de movimientos. ....................................................................................................... 100
Tabla 5.14. Registro de la décimo segunda prueba realizada .......................................................... 100
Tabla 5.15. Registro de la décimo tercer prueba realizada .............................................................. 101
Tabla 5.16. Registro de la décimo cuarta prueba realizada ............................................................. 101
Tabla 5.17. Registro de la décimo quinta prueba realizada ............................................................. 102

vi
Tabla 5.18. Registro de la décimo sexta prueba realizada .............................................................. 103
Tabla 5.19. Registro de la décimo séptima prueba realizada .......................................................... 104
Tabla 5.20. Registro de la décimo octava prueba realizada ............................................................ 105

vii
 SIGLAS

3D: Tridimensional

API: Application Programming Interface (Interfaz de programación de aplicaciones)

AR: Augmented Reality (Realidad aumentada)

AVR: Alf and Vegard's RISC processor

CC: Creative Commons (Comunes Creativos)

COM: Communication port (Puerto de comunicación)

CSV: Comma-sepparated values (Valores separados por comas)

DEI: Departamento de Electrónica e Informática

FAQ: Frequently Asked Questions (Preguntas frecuentes)

FPS: Frames per Second (Cuadros por segundo)

GNU: GNU is not Unix (GNU no es Unix)

GUI: Graphical User Interface (Interfaz gráfica de usuario)

HC: Huicheng Techonology

I2C: Inter-Integrated Circuit (Circuito Inter Integrado)

IC: Integrated Circuit (Circuito integrado)

IBM: International Business Machine Corporation

IDE: Integrated Development Environment (Entorno de desarrollo integrado)

ISM: Industrial, Scientific and Medical (Industrial, Científico y Médico)

KUKA: Keller und Knappich Augsburg (Keller y Knappich Ausburgo)

LCD: Liquid Crystal Display (Pantalla de cristal líquido)

LED: Light-emitting diode (Diodo emisor de luz)

NASA: National Aeronautics and Space Administration (Administración Nacional de la

Aeronáutica y del Espacio)

viii
NIR: Near-infrared technology (Tecnología de infrarrojo cercano)

NUI: Natural User Interface (Interfaz natural de usuario)

OpenCV: Open Computer Vision Library

OS: Operating System (Sistema operativo)

RGB: Red, Green and Blue (Rojo, verde y azul)

ROC: Receiver Operating Characteristic (Característica operativa del receptor)

SCL: Serial Clock (Señal de reloj serial)

SDA: Serial Data (Datos seriales)

SDK: Software Development Kit (Kit de desarrollo de software)

SIG: Special Interest Group (Grupo de interés especial)

UCA: Universidad Centroamericana “José Simeón Cañas”

USB: Universal Serial Bus (Bus universal en serie)

WMI: Windows Management Instrumentation (Instrumental de administración de

Windows)

WPF: Windows Presentation Foundation

ix
 NOMENCLATURA

° grado sexagesimal

µs microsegundo

Bd Baudio

Bit Binary digit (Dígito binario)

Camshift Continuously Adaptive Meanshift

GHz Gigahertz

I/O Input/Output (Entrada/Salida)

InMoov In movement (En movimiento)

Kc coeficiente de compacidad

m metro

m3 metro cúbico

mW miliWatt

mm milímetro

nm nanómetro

píxel Picture element

Rx Recepción

Rci relación de circularidad

Tx Transmisión

x
 CAPÍTULO 1. INTRODUCCIÓN

1.1 Definición del problema

Actualmente el Departamento de Electrónica e Informática (DEI) de la Universidad Centro-

americana José Simeón Cañas (UCA) tiene a su disposición un brazo robótico correspondiente a
una extremidad superior derecha. Fue elaborado por un grupo de estudiantes de ingeniería eléctrica
como trabajo de graduación durante el año 2017. Su diseño está basado en la estructura del robot de
código abierto InMoov, diseñado por el escultor francés Gaël Langevin. Las piezas se obtuvieron
mediante un proceso de impresión 3D.

El dispositivo es capaz de recrear una serie de movimientos que son realizados por una persona.
Para esto se requiere utilizar un sensor Kinect, encargado de la detección de los ángulos y
coordenadas del antebrazo, brazo y bíceps; y un guante con sensores para poder controlar la flexión
y contracción de los dedos de la mano.

Aunque el brazo robot es completamente funcional ya que todos los componentes son capaces de
realizar sus tareas correspondientes; su implementación presenta una serie de inconvenientes que
podrían ser corregidos.

Una de las principales desventajas que se ha podido identificar radica en el hardware,

específicamente la necesidad de utilizar un guante que contiene cables, sensores y una placa
microcontrolador en su interior. Esto es un proceso muy delicado y a la vez engorroso, pues existe
la posibilidad de que el usuario desconecte alguno de los componentes del circuito y que el guante
quede temporalmente inutilizable.

Con el propósito de eliminar el riesgo de desconexión, el guante con sensores será reemplazado por
un dispositivo conocido como Leap Motion, que consiste en un sensor óptico de realidad aumentada
capaz de detectar los movimientos de las manos y de sus correspondientes dedos con un alto nivel
de precisión (hasta una centésima de milímetro). Garantizando que la interacción entre el usuario y
el brazo robot sea completamente inalámbrica.

Además se ha observado una serie de problemas relacionados con el software. El primero de ellos
es que todas las funciones son manejadas a nivel de consola, de modo que carece de una interfaz

1
gráfica que sea amigable con el usuario, aumentando el nivel de complejidad requerido para su
operación y volviendo indispensable que se reciba algún tipo de entrenamiento.

El segundo de los problemas radica en que el brazo únicamente puede ser utilizado en un reducido
número de situaciones prácticas, esto debido a la limitada cantidad de opciones implementadas en el
software de control, de modo que el dispositivo solo es capaz de realizar la imitación en tiempo real
de los movimientos del usuario.

Con el fin de expandir las posibilidades de uso del brazo y que en un futuro pueda ser ocupado en
escenarios de mayor complejidad, se vuelve necesario agregar funcionalidades que estén orientadas
a la realización de tareas autónomas y de otras que involucren la repetición de secuencias de
movimientos.

Las carencias en el software anteriormente mencionadas se verán minimizadas con la creación de

un sistema centralizado que sea capaz de integrar diferentes tecnologías como los sensores Leap
Motion y Kinect, y la versatilidad de la visión por computadora en una plataforma de realidad
aumentada que sea intuitiva y fácil de manejar por el usuario promedio.

1.2 Objetivos

1.2.1 Objetivo general

Desarrollar un sistema informático basado en realidad aumentada y visión por computadora que
controle, optimice y amplíe las funcionalidades del brazo robótico del Departamento de Electrónica
e Informática de la UCA.

1.2.2 Objetivos específicos

a. Utilizar un sensor de realidad aumentada para detectar los movimientos de ambas manos,
izquierda y derecha, en reemplazo del guante con sensores de flexión originalmente
elaborado.
b. Implementar en el sistema la opción de grabar secuencias de movimientos para que estas
puedan ser reproducidas posteriormente por el brazo robótico.
c. Añadir al sistema la habilidad de clasificar objetos de forma autónoma mediante el uso de
visión por computadora.

2
 d. Diseñar una interfaz gráfica de usuario amigable e intuitiva que emplee realidad aumentada
para facilitar la interpretación de los datos.

1.3 Límites y alcances

a. Se cambió la forma de interacción entre el usuario y el brazo a través de la implementación

de un sensor conocido como Leap Motion, siendo esta la única modificación realizada en el
hardware del sistema.

b. El software de control del brazo fue totalmente rediseñado, esto incluye a la plataforma de
escritorio y a las rutinas integradas en las placas microcontroladoras. Para este fin, se
utilizaron los lenguajes de programación C#, C++ y Arduino. El nuevo software se adaptó a
la estructura del hardware que posee el brazo robótico.

c. La grabación de las secuencias de movimientos se realiza mediante archivos de valores

separados por coma (CSV) que registran los ángulos y coordenadas correspondientes a las
extremidades superiores del usuario.

d. La implementación de los algoritmos de visión por computadora se hace utilizando la

librería Open Computer Vision (OpenCV), específicamente su versión disponible para
C++. Esto se complementa con el uso de algunos modelos de minería de datos.

e. El brazo robótico actualmente disponible corresponde a una extremidad superior derecha,

sin embargo, el software a desarrollar también realiza las mediciones y cálculos para el
brazo izquierdo del usuario. De modo que el sistema garantiza la compatibilidad si en un
futuro se elabora la extremidad faltante.

f. Debido a que no se tiene acceso al brazo robótico de la tesis anterior y con la finalidad de
facilitar una futura integración con el sistema, se diseñó, construyó y trabajó con un modelo
físico del dispositivo, que respeta la estructura del hardware original.

3
1.4 Antecedentes

Los antecedentes se han clasificado en dos categorías: directos y bibliográficos. La primera, incluye
una descripción del trabajo de investigación en el que se elaboró el brazo robótico del DEI, a partir
del cual se ha desarrollado la nueva plataforma de software. Mientras que la segunda categoría hace
referencia a proyectos con temáticas similares que han sido diseñados en otras universidades y
centros de investigación.

1.4.1 Antecedentes directos

Brazo robot controlado por gestos

Consiste en una extremidad superior derecha robótica controlada por medio del reconocimiento de
gestos. Sus piezas se obtuvieron con el proceso de impresión 3D y su estructura está basada en el
diseño del proyecto de código abierto InMoov, diseñado en Francia por Gaël Langevin.

El control del brazo se logra a través del uso de un guante con sensores de flexión (flex sensors) y
un sensor Kinect, el primero está encargado de la detección de los movimientos de los cinco dedos
de la mano, mientras que el segundo se ocupa de rastrear y localizar el posicionamiento del brazo.
Fue elaborado durante el año 2017 por Federico Flamenco, Andrea Marroquín, Jaime Portillo y
Gustavo Rivas como trabajo de graduación para la carrera de ingeniería eléctrica.

Estructura del brazo robótico

El brazo robótico está formado por cinco partes: mano y muñeca, antebrazo, bíceps, hombro, pecho
y espalda; tal como se muestra en la Figura 1.1.

La mano tiene cinco dedos compuestos por tres falanges de dos piezas cada uno. Su interior posee
dos hilos de nylon amarrados a cinco servomotores ubicados en el antebrazo (le corresponde un
motor a cada dedo), simulando así, el funcionamiento de los tendones de una mano humana. Los
dedos pueden realizar los movimientos de contracción y de extensión que si bien son detectados con
mucha precisión, se reproducen a una velocidad lenta. Cabe mencionar que, dicho mecanismo es
capaz de sostener objetos livianos como un teléfono celular (Flamenco et al., 2017, p. 90).

4
 D

Figura 1.1. Brazo robótico del DEI y sus partes, a) mano y muñeca, b) antebrazo, c) bíceps, d) hombro,
e) pecho y espalda. Adaptado de Flamenco et al. (2017, p. 27).

La muñeca se conecta con la palma de la mano por medio de una pieza conocida como eje de unión,
que a su vez, se encuentra unida a una base rotacional. Por último, todos estos elementos se colocan
sobre un soporte base, como se aprecia en la Figura 1.2.

Figura 1.2. Mano y muñeca del brazo unidas a la base rotacional y al soporte base.
Tomado de Flamenco et al. (2017, p.36).

El antebrazo (Figura 1.3) se encarga de realizar los movimientos de flexión y extensión utilizando
como eje la articulación del codo. Para esto se emplea un servomotor colocado en el interior de la
parte baja del bíceps.

5
 Figura 1.3. Antebrazo del dispositivo. Tomado de Flamenco et al. (2017, pp. 36- 39).

El bíceps contiene un pistón en su interior que es controlado por un servomotor ubicado en el

hombro. Se conecta al antebrazo por medio del codo, el cual está compuesto por dos engranes y un
perno de 8 cm de largo. Estos componentes se pueden apreciar en la Figura 1.4.

A B

Figura 1.4. Estructura interna del bíceps: a) pistón y b) engranes del codo junto con el perno.
Adaptado de Flamenco et al. (2017, p. 45).

El hombro utiliza como base al pecho y la espalda. Es el encargado de realizar los movimientos de
abducción vertical, flexión, extensión y aducción horizontal utilizando dos servomotores ubicados
en el omóplato, como se muestra en la Figura 1.5.

Figura 1.5. Ubicación de los dos servomotores encargados de los movimientos del hombro.
Adaptado de Flamenco et al. (2017, pp. 49-50).

6
Funcionamiento del brazo robótico
Para controlar los movimientos de la mano se utiliza un guante que en su interior posee cinco
sensores de flexión, uno para cada dedo, como se muestra en la Figura 1.6. Al ser doblados, los
sensores cambian su valor de resistencia eléctrica y una placa microcontroladora de tipo Arduino
Leonardo lee la diferencia de voltaje, para luego enviar esta información de forma inalámbrica
mediante un módulo Bluetooth HC-05 hacia una placa Arduino Mega, que se encarga de mandar
señales hacia los cinco servomotores colocados en el antebrazo, permitiendo que estos giren y halen
de los hilos de nylon para poder ejecutar la contracción y extensión de los dedos.

Figura 1.6. Guante con sensores de flexión. Tomado de Flamenco et al. (2017, p.52).

La detección de los movimientos del hombro y del bíceps se realiza utilizando las cámaras del
dispositivo Kinect. Este sensor se encarga de recolectar datos sobre el posicionamiento del hombro
derecho, codo derecho, mano derecha y torso del usuario. Luego, los datos son enviados a una
computadora para que sean procesados mediante un software diseñado con el lenguaje de
programación Processing.

Por medio de una conexión USB 2.0, la información procesada se envía a una placa Arduino UNO,
que controla los servomotores encargados de los movimientos del hombro y bíceps.

En la Figura 1.7 se incluye un esquema donde se ilustra la forma de comunicación entre los
distintos dispositivos involucrados en el funcionamiento del brazo robótico.

7
 Figura 1.7. Esquema de comunicación entre los dispositivos de control del brazo robótico del DEI.
Tomado de Flamenco et al. (2017, p.54).

1.4.2 Antecedentes bibliográficos

En años recientes, a nivel internacional se han desarrollado distintos proyectos enfocados al uso de
sensores ópticos para la detección y rastreo del posicionamiento de las extremidades superiores
humanas y el diseño de dispositivos robóticos capaces de recrear sus movimientos. A continuación,
se muestra una descripción de algunos de estos proyectos.

Mano robótica (Mão robótica)

Trabajo elaborado en la “Escola Senai Roberto Simonsen” de São Paulo, Brasil durante el año 2016
por Matheus Da Silva, Nádia Teixeira, Renan Da Fonseca y Stella Freire, estudiantes de un curso
técnico de mecatrónica. Es una investigación multidisciplinaria que involucra las áreas de mecánica,
biomecánica y control (Da Silva et al., 2016, p. 17).

Se diseñó una mano con piezas mecánicas, simulando la estructura anatómica y el funcionamiento
de una mano humana, para que esta fuese capaz de reproducir una serie de movimientos básicos,
por ejemplo, agarrar una pelota o una taza.

Para su funcionamiento se utilizaron las placas microcontroladoras Arduino y BITalino, la primera,

encargada de controlar los servomotores para el movimiento de las piezas de la mano robótica y la
segunda, para detectar las señales de los músculos del usuario. Se puede apreciar la estructura de la
mano robótica en la Figura 1.8a y su sistema de control en la Figura 1.8b.

8
 A B

Figura 1.8. Estructura de la mano robótica junto con su sistema de control.

(Da Silva et al., 2016, p. 87-90).

Reconocimiento de gestos estáticos del lenguaje de señas usando Leap Motion

Consiste en un trabajo de tesis elaborado en la Western Carolina University para la maestría de

ciencias en la tecnología.

Se enfocó en el desarrollo de una aplicación capaz de detectar gestos correspondientes al lenguaje

de señas por medio del uso de la tecnología del infrarrojo cercano (NIR, siglas en inglés de near
infrared technology) utilizando el dispositivo Leap Motion. El objetivo principal era facilitar la
comunicación entre personas con pérdida de audición y aquellos que no conocen el lenguaje de
señas, logrando desarrollar un algoritmo que permitiera una alta precisión en el reconocimiento de
movimientos de la mano. Se buscó la compatibilidad con dispositivos como computadoras, tabletas
y teléfonos inteligentes (McNeil, 2017, p.vi).

Análisis de la precisión y robustez del Leap Motion

Es un estudio desarrollado en la Technical University of Dortmund de Alemania a inicios del año

2013. Estaba enfocado en analizar las capacidades de detección del sensor Leap Motion,
específicamente su precisión, tomando en cuenta que era un dispositivo recientemente lanzado y
que su verdadero potencial no había sido analizado adecuadamente hasta ese punto, de forma que se
le considera una investigación pionera en el tema.

Se elaboraron una serie de experimentos utilizando un robot industrial modelo Kuka KR 125/3
(Figura 1.9) que empleaba una herramienta de referencia, específicamente un lapicero o reference
pen. El objetivo principal de estas pruebas era poder determinar cómo el uso del dispositivo Leap

9
Motion permitiría mejorar el desarrollo de aplicaciones que requieren interacción entre un humano
y una computadora.

Luego de realizar las pruebas, los investigadores concluyen que el nivel de precisión promedio
logrado por el Leap Motion es de 0.7 mm, que difiere de los 0.01 mm que afirman los fabricantes
(Weichert et al., 2013, p. 6391). No obstante, se aclara que los ensayos se efectuaron usando una
versión preliminar del sensor y que la precisión puede variar para el producto lanzado al mercado
consumidor. Además, se comenta que otros sensores ópticos similares, como el Microsoft Kinect,
no son capaces de lograr estos niveles de precisión en cuanto a la detección de movimientos.

Figura 1.9. Imagen del robot industrial modelo Kuka KR 125/3.

Tomado de Weichert et al. (2013, p. 6384).

10
 CAPÍTULO 2. MARCO TEÓRICO

2.1 Tecnología Arduino

Arduino es una plataforma electrónica basada en la filosofía open-source. Se encuentra integrada

por una serie de placas microcontroladoras, un lenguaje de programación y un entorno de desarrollo
de software o IDE (Ramos, Castro y Jaworski, 2012, p.2).

El proyecto se originó en el Instituto de Interactividad y Diseño de la ciudad de Ivrea, Italia y fue

desarrollado como una bifurcación (fork) del proyecto Wiring (también desarrollado dentro del
mismo instituto). Su propósito era el de crear una herramienta de hardware de bajo costo y
fácilmente programable por usuarios no especializados en informática (Calcero Pedrera, 2014, p. 5).

Arduino ha sido utilizado en miles de proyectos y aplicaciones gracias a que proporciona una
experiencia de usuario simple y accesible. Una de las principales ventajas del software es que
resulta ser de fácil manejo para desarrolladores principiantes y lo suficientemente robusto para
cubrir las necesidades de programadores avanzados (Arduino, 2018a).

2.1.1 Hardware de Arduino

Consiste en una placa de circuito impreso que contiene un microcontrolador. A esta placa se le
pueden incorporar diversos componentes, tales como: interruptores, sensores ultrasónicos de
distancia, ledes y motores; de forma que pueda realizar una o varias tareas específicas. Las placas
Arduino son capaces de leer una serie de entradas como la luz en un sensor o un dedo presionando
un botón, para posteriormente convertirlas en salidas, por ejemplo, activar un motor o encender un
led. Schmidt (2011, p. 30) comenta que, por lo general, los microcontroladores integrados son
fabricados por la empresa Atmel, siendo los modelos más utilizados el ATmega328 o el
ATmega168.

Arduino se diferencia de otras tecnologías similares porque implementa el modelo de código abierto
(open-source), de modo que los esquemas de los circuitos son publicados bajo la licencia CC
(Creative Commons). Esto permite que los usuarios diseñen sus propias versiones de las placas e
incluso puedan mejorarlas y expandir sus funcionalidades (Arduino, 2018a).

Existe una gran diversidad de placas microcontroladoras Arduino disponibles en el mercado

(Arduino, 2018b), cada una con diferentes configuraciones que se ajustan a las necesidades de los

11
usuarios. Algunas como Arduino UNO o Arduino Leonardo, están diseñadas para un nivel
introductorio o principiante, mientras que otras como Arduino Mega 2560 o Arduino Zero han sido
elaboradas para proyectos más complejos pues poseen funcionalidades avanzadas y un rendimiento
más rápido. Incluso, existen modelos desarrollados para propósitos específicos como el caso del
Arduino LilyPad, que fue creado para incorporar placas microcontroladoras en productos textiles,
de forma que puede utilizarse en la elaboración de camisetas interactivas. Si bien cada placa
presenta diferencias en cuanto a su diseño, todas pueden ser programadas utilizando las mismas
herramientas y librerías de software. Las imágenes de los modelos antes mencionados se pueden
apreciar en la Figura 2.1.

Figura 2.1. Diferentes versiones de placas Arduino disponibles en el mercado. Adaptado de Arduino (2018b).

La comunicación entre el hardware de una placa Arduino y una computadora se efectúa por medio
de un cable USB, esta conexión puede realizarse con diversos propósitos, entre ellos: actualizar el
software de la placa, suministrar energía eléctrica o para cargar un programa que realice una
función específica.

2.1.2 Software de Arduino

Para la elaboración de programas que controlen el funcionamiento del microcontrolador de la placa

(conocido como sketches) Arduino utiliza un lenguaje basado en C/C++. Además, es posible
realizar la programación mediante AVR-C, que consiste en una versión del lenguaje C adaptado
para la familia de microcontroladores AVR, diseñados por la empresa Atmel e integrados en todas
las placas Arduino (Schmidt, 2011, p. 51). Incluso, como se especifica en el FAQ de la web oficial

12
(Arduino, 2018c) es posible programar directamente en C++ siempre y cuando las librerías sean
soportadas por el compilador avr-gcc.

Arduino proporciona un IDE para la escritura, edición y carga de código. Este se encuentra basado
en el IDE del lenguaje Processing (que también es open-source). Se encuentra disponible para los
sistemas operativos Windows, Mac OS y GNU/Linux. Alternativamente es posible usar otros
entornos como AVR Studio o el Web Editor disponible en la página oficial de Arduino. La Figura
2.2 muestra el ejemplo de un sketch escrito y compilado en el IDE de Arduino.

Figura 2.2. Ejemplo de un sketch codificado usando el IDE de Arduino.

2.1.3 Comunicación serial en placas Arduino

La comunicación serial es un método de transferencia de datos entre dispositivos electrónicos en el

que se transmite un byte a la vez. Las placas microcontroladoras Arduino implementan esta
tecnología mediante la integración de una interfaz serial USB, que facilita el intercambio de datos
con otros dispositivos, por ejemplo, las computadoras (Özkaya y Yillikçi, 2015, p. 117).

13
En el caso de la placa Arduino UNO, existen dos pines digitales: el 0 y el 1. Estos se encuentran
conectados a un circuito integrado (IC) que convierte las señales para que sean compatibles con la
conexión USB. En este caso, el pin 0 es usado para recibir (RX) y el pin 1 es usado para transmitir
(TX). Cabe aclarar que si estos pines son utilizados para comunicación serial, no será posible
usarlos para la entrada y salida (I/O) de señales digitales. En cambio, la placa Arduino Mega posee
tres puertos seriales adicionales: Serial1 en los pines 19(RX) y 18(TX), Serial2 en los pines 17(RX)
y 16(TX), Serial3 en los pines 15(RX) y 14(TX).

La librería SoftwareSerial posee diversos métodos que permiten el acceso a los datos contenidos en
el búfer serial, por ejemplo: Serial.begin(9600) inicia la comunicación serial a una velocidad de
9600 Bd; Serial.available() permite saber cuántos datos se encuentran disponibles dentro del búfer
serial; Serial.read() y Serial.peek() devuelven el primer dato recibido, con la diferencia que el
primero lo elimina de la cola serial, mientras que el segundo no. Además, a través de esta librería es
posible lograr la comunicación serial en otros pines digitales de la placa microcontroladora
Arduino, replicando esta funcionalidad mediante software (Arduino, 2018e).

2.1.4 Tecnología Bluetooth

Es un estándar de comunicación inalámbrico empleado para la interconexión de dispositivos

electrónicos como teléfonos móviles, computadoras, impresoras, teclados, reproductores de música,
relojes digitales, auriculares, entre otros (Tanenbaum y Wetherhall, 2011, p. 320).

Su creación estuvo a cargo del Bluetooth Special Interest Group (consorcio formado en 1998 por las
empresas Ericsson, IBM, Intel, Nokia y Toshiba) que también es la autoridad encargada de
establecer sus especificaciones técnicas.

Según Tanenbaum y Wetherhall, fue diseñado con el propósito de eliminar la necesidad de utilizar
cables para la transferencia de información, estableciendo un protocolo que utilice tecnología de
corto alcance, consumo eléctrico reducido y de bajo costo.

Bluetooth opera a una frecuencia de 2.4 GHz que corresponde a la banda ISM, designada para fines
industriales, médicos y científicos (Bluetooth SIG, 2018). Además, dependiendo de la potencia y el
rango de distancia en el que operan los dispositivos, estos pueden clasificarse en tres clases, tal
como se indica en la Tabla 2.1.

14
 Tabla 2.1. Clasificación de los dispositivos Bluetooth según su potencia y rango de transmisión.
Adaptado de Wright (s.f.).
Clase del Potencia de Rango óptimo/Alcance
dispositivo transmisión (mW) máximo (m)
Clase 3 1 Menor a 10
Clase 2 2.5 10
Clase 1 100 100

Las placas microcontroladoras Arduino se comunican mediante Bluetooth utilizando componentes

conocidos como módulos. Ejemplos de estos son el HC-05 y el HC-06 (Figura 2.3), ampliamente
utilizados por su bajo costo y sencilla implementación en un circuito (Kurniawan, 2017, p. 100).

A B

Figura 2.3. Módulos de comunicación Bluetooth: a) HC-05 y b) HC-06.

Adaptado de Kurniawan (2017, p. 100).

2.1.4 Bus I2C

Consiste en un bus en serie diseñado por Phillips a inicios de la década de 1980, para permitir una
comunicación de baja velocidad entre varios circuitos integrados. El protocolo fue estandarizado en
la década de 1990 y otras compañías rápidamente comenzaron a adoptarlo, lanzando sus propios
circuitos compatibles (Blum, 2013, p.164). Esta tecnología también se conoce como Circuito Inter-
Integrado (Inter-Integrated Circuit) o por las siglas I2C o IIC.

De acuerdo a Palacios, Remiro y López (2009, p. 332), el bus serie I2C está formado por dos hilos
que pueden conectar varios dispositivos mediante un hardware muy simple (Figura 2.4). Por esos
dos hilos se produce una comunicación serial, bit a bit. Dos señales son transmitidas, una por cada
línea: la primera es la Serial Clock (SCL), que es la señal de reloj utilizada para la sincronización de
los datos; la segunda es la Serial Data (SDA) que es la línea para la transferencia en serie de los
datos.

15
 Figura 2.4. Estructura de un bus I2C. Tomado de Palacios et al. (2009, p. 332).

Los dispositivos conectados al bus I2C mantienen un protocolo de comunicación del tipo
maestro/esclavo (o master/slave). Las diferencias entre las funciones del maestro y del esclavo son:

 El circuito maestro inicia y termina la transferencia de información, además de

controlar la señal de reloj. Normalmente es un microcontrolador.
 El esclavo es el circuito direccionado por el maestro.

La línea SDA es bidireccional, es decir, tanto el maestro como los esclavos pueden actuar como
transmisores o receptores de datos, dependiendo de la función del dispositivo. Así, por ejemplo, una
pantalla LCD es solo un receptor de datos mientras que una memoria recibe y transmite datos. La
generación de señales de reloj (SCL) es siempre responsabilidad del maestro.

Las placas Arduino son capaces de comunicarse con dispositivos I2C mediante el uso de librerías
(como LiquidCrystal I2C), que incluye una serie de comandos que permiten la lectura y escritura de
datos que provienen de pantallas LCD a través del protocolo I2C (Brabander, 2015).

2.1.5 Pantalla LCD

En muchos proyectos es necesario visualizar información a través de una pantalla de bajo costo. La
forma más utilizada es mediante un display o pantalla LCD (Figura 2.5).

16
 Figura 2.5. Pantalla LCD modelo 1602 I2C.

Las pantallas de cristal líquido o display LCD (Liquid Crystal Display) tienen la capacidad de
mostrar cualquier carácter alfanumérico, permitiendo representar la información generada por un
equipo electrónico de forma fácil y económica. La pantalla consta de una matriz de caracteres
distribuidos en una, dos o cuatro líneas de dieciséis, veinte y hasta cuarenta caracteres en cada línea
(Palacios et al., 2009, p. 187).

2.2 Sensor Kinect

Es un dispositivo utilizado para la detección de movimientos y el reconocimiento de gestos,

desarrollado por Microsoft en conjunto con la empresa israelí PrimeSense. Fue anunciado en junio
de 2009 y originalmente se le conoció mediante el nombre de Project Natal. Su primera versión,
compatible con la consola de videojuegos Xbox 360, fue lanzada en noviembre de 2010 con el
propósito de competir con tecnologías similares de otras compañías, tales como el Wii Remote de
Nintendo y el PlayStation Move de Sony. Luego de su lanzamiento, Kinect se convirtió en el
dispositivo electrónico con ventas más rápidas dentro del mercado (Jana, 2012, p. 7).

El objetivo de Kinect es proporcionar una Interfaz Natural de Usuario (Natural User Interface,
NUI) que permita a una persona interactuar con el sistema o las aplicaciones por medio del
reconocimiento de gestos de las manos, movimientos del cuerpo o comandos de voz; eliminando la
necesidad de utilizar un dispositivo de entrada como un control o un teclado.

Durante sus primeros meses de lanzamiento, el sensor Kinect estaba limitado al desarrollo de
videojuegos para la consola Xbox 360. Sin embargo, en febrero de 2012 Microsoft lanzó al
mercado una nueva versión del hardware y software conocido como Kinect for Windows Version 1
(Kinect V1), destinado al desarrollo de aplicaciones para el sistema operativo Windows (Kinect for
Windows Team, 2012a).

17
Nuevas revisiones del hardware serían lanzadas en años posteriores, la primera conocida como
Kinect for Xbox One, que estaba destinada al desarrollo de aplicaciones compatibles con la consola
de videojuegos de Microsoft más reciente. Su versión análoga para Windows, conocida como
Kinect for Windows Version 2 (Kinect V2), salió al mercado en julio de 2014 (Kinect for Windows
Team, 2014).

2.2.1 Hardware del sensor Kinect

El sensor posee la forma de una barra horizontal colocada sobre una base que contiene una serie de
componentes en su interior: una cámara a color, un led de color verde, un emisor de luz infrarroja,
un sensor de profundidad infrarrojo, un motor de inclinación y un arreglo de micrófonos.
La ubicación de estos elementos se muestra en la Figura 2.6.

Figura 2.6. Partes del sensor Kinect. Adaptado de Jana (2012, p. 9).

Kinect se comunica con la computadora mediante un puerto USB 2.0, sin embargo necesita de una
fuente de poder adicional debido a que el puerto USB no es capaz de abastecer el consumo de
energía del dispositivo.

1. Cámara a color

Se encarga de la captura y transmisión de los datos de video en color. Su función es detectar los
colores RGB (rojo, verde y azul) de una imagen fuente. El número de cuadros por segundo
transmitidos por Kinect varía dependiendo de la resolución para el marco de la imagen. Soporta una

18
velocidad de transmisión de datos de 30 cuadros por segundo a una resolución de 640 x 480 pixeles
y una máxima resolución de 1280 x 960 pixeles a una velocidad de 12 cuadros por segundo.

Los rangos de visión para la cámara a color (tomando como punto de inicio el centro del sensor
Kinect) son de 57° para el ángulo horizontal y de 43° para el ángulo vertical, como se puede
apreciar en la Figura 2.7.

Figura 2.7. Ángulos de visión de la cámara del sensor Kinect. Tomado de Jana (2012, p. 10).

2. Emisor y sensor de profundidad infrarrojo

Para la detección de la profundidad de los objetos, Kinect cuenta con un emisor de luz encargado de
proyectar una luz infrarroja en forma de un patrón de puntos sobre todos los objetos que se
encuentran dentro del rango de visión (Figura 2.8). Estos puntos, si bien son invisibles para el ojo
humano, pueden ser detectados por el sensor de profundidad, que se encarga de realizar mediciones
sobre las distancias de los objetos respecto al sensor. Esto se calcula en base a la longitud entre el
sensor y la ubicación en donde fue detectado cada punto de luz infrarroja. Todo este proceso es
controlado por el chip PrimeSense (Jana, 2012, pp.11-13).

Figura 2.8. Luz infrarroja proyectada en forma de patrón de puntos. Tomado de Miller (2017).

19
En base a la documentación oficial del equipo de desarrollo Kinect for Windows Team (2012b), el
rango en el que trabaja el sensor de profundidad bajo el modo por defecto (Default Mode) se
encuentra entre 800 mm (0.8 m) y 4000 mm (4 m). Es importante aclarar que el dispositivo es capaz
de detectar objetos fuera de ese intervalo, pero no se garantiza que las coordenadas de las
articulaciones de la persona estén en concordancia con los datos de la realidad. La Figura 2.9
muestra un diagrama que ilustra cómo los rangos de distancia son interpretadas por el sensor
Kinect.

Figura 2.9. Rangos de distancia interpretados por el sensor Kinect.

Adaptado de Kinect for Windows Team (2012b).

3. Motor de inclinación

El sensor Kinect posee un pequeño motor que le permite cambiar los ángulos de la cámara y del
sensor, además que conecta las partes superior e inferior del dispositivo. El motor está compuesto
por tres engranes que permiten la inclinación dentro de un específico rango de ángulos. Su
estructura puede apreciarse en la Figura 2.10.

Figura 2.10. Estructura interna del motor de inclinación del sensor Kinect.
Tomado de Jana (2012, p.13).

20
El ángulo máximo de inclinación vertical permitido por el motor es de 27° ya sea hacia arriba o
hacia abajo (Figura 2.11). Es importante mencionar que la inclinación del sensor debe manipularse
a través del software, ya que si el usuario intenta modificarla manualmente, el motor podría dañarse.

Figura 2.11. Ángulos de inclinación permitidos por el motor del sensor Kinect.
Tomado de Jana (2012, p.14).

4. Led indicador
Ubicado entre la cámara y el emisor infrarrojo. Se encarga de indicar el estado del sensor Kinect.
El led emite una luz de color verde constante cuando la computadora detecta la conexión con el
dispositivo y cuando todos los controladores o drivers han sido cargados adecuadamente.
Si el dispositivo está conectado físicamente, pero no es reconocido por la computadora, el led emite
una luz verde de forma intermitente (Jana, 2012, p. 15).

5. Arreglo de micrófonos
Conformado por cuatro micrófonos: tres de ellos se ubican en el lado derecho mientras que el
restante se encuentra del lado izquierdo. La Figura 2.12 muestra el posicionamiento de los
micrófonos y la distancia que hay entre cada uno de ellos dentro del dispositivo.

Figura 2.12. Ubicación y distancia de separación de los cuatro micrófonos integrados en el sensor Kinect.
Tomado de Jana (2012, p. 14).

21
Jana (2012, p. 211) menciona que las funciones del arreglo de micrófonos son:

 Captura de sonido de alta calidad y procesamiento de señal integrado. Esto incluye la

eliminación del ruido y la cancelación del eco.
 Identificación de la dirección de origen del sonido de entrada.

Debido a que los micrófonos están colocados en diferentes posiciones, el sonido será percibido por
cada uno de ellos en distintos intervalos de tiempo. Esto implica que existirá cierto retraso en la
recepción de sonido para cada uno de los micrófonos. Por esta razón, el sensor Kinect es capaz de
comprender de qué dirección proviene el sonido entrante y de calcular la distancia aproximada entre
la fuente del sonido y el dispositivo (Jana, 2012, p. 217).

2.2.2 Kit de desarrollo de software de Kinect para Windows

Consiste en un conjunto de herramientas de software utilizadas para el desarrollo y ejecución de

aplicaciones compatibles con el dispositivo Kinect V1. Contiene los controladores o drivers
necesarios para interactuar con el sensor (Jana, 2012, p. 19). También se le conoce como Kinect for
Windows SDK (Software Development Kit).

En la actualidad el software solo posee soporte oficial para el sistema operativo Windows,
específicamente en las versiones de Windows 7 o superiores. Además, el SDK es compatible con
los lenguajes de programación C#, C++ y Visual Basic .NET (Microsoft, 2013).

Desde su primer lanzamiento comercial en febrero de 2012, el SDK ha contado con múltiples
revisiones. La versión más reciente para Kinect V1 corresponde a la 1.8, lanzada el 19 de
septiembre de 2013. Esta se encuentra disponible para su descarga en el sitio web oficial de
Microsoft.

Es posible utilizar el Kinect for Windows SDK para crear aplicaciones compatibles con el Kinect
for Xbox 360. Sin embargo, Catuhe (2012, p.6) menciona que se producirá un mensaje de alerta,
avisando al usuario que Microsoft no garantiza la completa compatibilidad entre este dispositivo y
los programas desarrollados.

Con el objetivo de ayudar a los programadores, Microsoft provee una herramienta conocida como
Kinect Developer Toolkit, que contiene una serie de códigos de ejemplo y documentación sobre las

22
librerías disponibles en la API. En la Figura 2.13 se muestra el entorno del Kinect Developer
Toolikt.

Figura 2.13. Entorno del Kinect for Windows Developer Toolkit v1.8.0.

Tanto el Kinect for Windows Developer Toolkit como el Kinect SDK poseen su propio instalador,
esto, de acuerdo a Jana (2012, p. 23) con el fin de que las actualizaciones del primero, tales como
cambios realizados en los códigos de ejemplo, se efectúen sin la necesidad de realizar
modificaciones sobre el SDK. La Figura 2.14 muestra un esquema general de los componentes que
pertenecen tanto al Developer Toolkit como al Kinect SDK.

Figura 2.14. Componentes del Developer Toolkit y del Kinect for Windows SDK.
Adaptado de Jana (2012, p.23).

23
El SDK de Kinect también instala una herramienta conocida como Kinect Management. Este es un
servicio de Windows que se ejecuta en segundo plano (background) mientras la computadora se
comunica con el sensor Kinect. Algunas de sus funciones son la verificación de cambios en el
estado del dispositivo y el manejo de los componentes de audio mediante la interacción con los
drivers de sonido de la computadora. La Figura 2.15 muestra al Kinect Management dentro de la
lista de servicios de Windows 10.

Figura 2.15. Kinect Management dentro de la lista de servicios de Microsoft Windows 10.

2.3 Sensor Leap Motion

Es un dispositivo utilizado para el reconocimiento de gestos lanzado el 22 de julio de 2013 y

desarrollado por la empresa Leap Motion Inc. Es capaz de detectar, con una precisión de 0.01 mm y
sin una latencia visible, los movimientos de ambas manos y de sus correspondientes dedos,
transmitiendo todos estos datos a una computadora mediante una conexión USB (Leap Motion Inc.,
2013).

2.3.1 Estructura externa del sensor Leap Motion

El sensor tiene una forma rectangular, cuyas dimensiones son de 7.5 cm de largo, 3 cm de ancho y
un grosor de 1cm. Posee un led de color verde, que sirve como punto de referencia para el
posicionamiento del dispositivo. Dispone de un puerto USB 3.0 tipo micro-B en donde se conecta
un cable que establece la conexión con una computadora. Además, el sensor Leap Motion posee dos
superficies: una superior donde se ubican las cámaras y sensores encargados de la detección de los
movimientos del usuario y una inferior, donde está su logo en bajo relieve.

La Figura 2.16 muestra la imagen de un sensor Leap Motion donde se pueden apreciar su parte
superior, led indicador y cable USB.

24
 Figura 2.16. Estructura externa del sensor Leap Motion.

2.3.2 Hardware interno del sensor Leap Motion

Desde el punto de vista del hardware el sensor posee un diseño simple, compuesto por tres ledes y
dos cámaras monocromáticas como se muestra en la Figura 2.17. Al igual que el sensor Kinect, el
Leap Motion implementa la tecnología infrarroja.

Figura 2.17. a) Estructura interna del sensor Leap Motion y b) un esquema de sus componentes.
Adaptado de Weichert et al. (2013, p. 6382).

Colgan (2013) comenta que los ledes se encargan de iluminar la zona de interacción utilizando luz
infrarroja con una longitud de onda de 850 nm. Las cámaras son las encargadas de capturar las
imágenes de los objetos que reflejan la luz infrarroja emitida por los ledes y son capaces de generar
desde 20 hasta 200 cuadros por segundo dependiendo de las configuraciones del usuario y de la
capacidad de procesamiento de la computadora. Las imágenes obtenidas son enviadas a una
computadora por medio de un cable USB, en donde son analizadas por el software del sensor Leap
Motion.

El área de interacción o zona de cobertura 3D que provee el sensor tiene una dimensión de
aproximadamente 0.23 m3 distribuida de la siguiente forma: 61 cm de alto (sobre las cámaras y

25
ledes del sensor), 61 cm de ancho a cada uno de los lados (formando un ángulo de 150°) y una
profundidad de 61 cm a cada lado (con un ángulo de 120°). Como resultado de la intersección de
los campos de visión de las cámaras infrarrojas, el área posee la forma de una pirámide invertida,
tal como se puede apreciar en la Figura 2.18.

Figura 2.18. Dimensiones del área de interacción 3D que ofrece el sensor Leap Motion.
Adaptada de Colgan (2013).

2.3.3 Software de Leap Motion

El software se encarga del análisis de las imágenes capturadas y la medición de diferentes

cantidades físicas. El hardware, debido a su simplicidad en el diseño, únicamente captura imágenes
para luego transmitirlas a la computadora por medio de una conexión USB (Colgan, 2013).

Según la documentación oficial de Leap Motion Inc. (s.f.a) el software se ejecuta como un servicio
en el sistema operativo Microsoft Windows o como un demonio en Mac OS y en GNU/Linux. Las
aplicaciones compatibles acceden a este servicio o demonio para la obtención de los datos enviados
por el sensor.

1. SDK de Leap Motion

Existen dos versiones del SDK del sensor Leap Motion con soporte oficial, estas son el Leap
Motion V2 (conocido como V2 Software) y el Leap Motion Orion. Ambas trabajan utilizando el
mismo hardware, la diferencia radica en que Orion está diseñado específicamente para el desarrollo
de aplicaciones de realidad virtual y presenta mayor precisión, distancia, velocidad y menor latencia
en la detección de movimientos si se compara con V2 (Feltham, 2016). Sin embargo, para

26
desarrollar aplicaciones en Mac OS, GNU/Linux o que requieran de rastreo de objetos (object
tracking) se vuelve necesario utilizar el V2 Software (Leap Motion Inc., 2017).

El software de Leap Motion actualmente posee librerías compatibles con los lenguajes de
programación C++, C#, Objective-C, Java, Python, JavaScript, Leap C (solo para Orion) y con los
motores de juego Unreal Engine y Unity (Leap Motion Inc., s.f.b).

El SDK de Leap Motion provee dos versiones de la API, la primera es la Interfaz de Aplicación
Nativa (Native Aplication Interface) utilizada para el desarrollo de aplicaciones de escritorio,
mientras que la segunda es la Interfaz WebSocket (WebSocket Interface) empleada para la creación
de programas que implementen tecnologías web.

La interfaz de aplicación nativa consiste en una biblioteca dinámica que permite la comunicación
entre la aplicación de escritorio desarrollada por el usuario y el servicio Leap Motion. Su estructura
se encuentra ilustrada en la Figura 2.19.

Figura 2.19. Esquema sobre el funcionamiento de la Interfaz de Aplicación Nativa.

Tomado de Leap Motion Inc.(s.f.a).

Mecanismo de comunicación entre los componentes del software del Leap Motion:

1- El sensor transfiere todos los datos recolectados al servicio Leap Motion (Leap Service)
por medio del puerto USB. Luego la información es procesada y enviada a los programas o
aplicaciones compatibles.

27
 2- El servicio Leap Motion lee los ajustes de configuración establecidos por el usuario dentro
de la Leap Settings App, que es una aplicación independiente al servicio y se encuentra
disponible dentro del Panel de control de Leap Motion.
3- Las aplicaciones compatibles que se encuentran en primer plano (foreground) reciben los
datos del servicio Leap Motion.
4- Cuando una aplicación pasa a ejecutarse en segundo plano (background) automáticamente
deja de recibir datos, sin embargo, el usuario puede cambiar esta configuración y solicitar
que cierta aplicación reciba siempre datos del servicio.

2. Sistema de Coordenadas de la API de Leap Motion

Como se especifica en la documentación oficial de la API (Leap Motion Inc., s.f.c), el sensor Leap
Motion utiliza un sistema de coordenadas cartesianas diestro para poder determinar la ubicación de
los objetos en el espacio. Su origen está centrado en la parte superior del sensor (Figura 2.20).

Figura 2.20. Sistema de coordenadas 3D del sensor Leap Motion. Tomado de Leap Motion Inc. (s.f.c).

Para una correcta implementación de este sistema de coordenadas, el sensor debe colocarse en
posición estándar o normal, es decir, aquella en la cual el usuario se encuentra frente al led de color
verde (eje “z” positivo) y la computadora está en el lado opuesto (eje “z” negativo). El eje “y” es
vertical, con valores positivos hacia arriba, mientras que el eje “x” se encuentra sobre el plano
horizontal, paralelo al borde largo del sensor y posee valores positivos hacia la derecha del usuario.

El software del sensor es incapaz de detectar gestos u objetos si es colocado de lado o si las cámaras
están posicionadas hacia abajo. Dentro de la configuración, es posible ajustar el sistema de
coordenadas en caso que el usuario se encuentre en posición opuesta al led verde.

28
3. Datos recolectados por la API de Leap Motion

Las cantidades físicas que son registradas por el software del sensor Leap Motion se muestran en la
Tabla 2.2.

Tabla 2.2. Datos recolectados por el sensor Leap Motion.

Adaptado de Leap Motion Inc (s.f.c).

Cantidad física Unidad

Distancia Milímetros
Tiempo Microsegundos (salvo que se especifique lo contrario)
Velocidad Milímetros/segundo
Ángulo Radianes

4. Clases de la API de Leap Motion

La API de Leap Motion contiene diversas clases que se utilizan en el desarrollo de aplicaciones.
Algunas de las más importantes son: Frame (Cuadro), Hand (Mano), Finger (Dedo) y Bone
(Hueso).

El sensor Leap Motion rastrea manos, dedos y herramientas dentro de su campo de visión. Estos
datos están contenidos en los atributos de la clase Frame. De acuerdo a la documentación oficial,
dicha clase es esencialmente la raíz del modelo de datos de Leap Motion.

Las manos son representadas mediante la clase Hand, que registra información sobre la posición,
los dedos y el brazo de cada mano detectada. El software utiliza un modelo interno de la mano
humana para proveer seguimiento predictivo incluso cuando algunas partes de una mano no pueden
ser vistas. Los objetos de la clase Hand proporcionan la posición de los cinco dedos, no obstante el
seguimiento es óptimo cuando la silueta de una mano y todos sus dedos son claramente visibles.

Para garantizar una calidad óptima en el seguimiento de datos, se recomienda que no aparezcan más
de dos manos u objetos similares dentro del campo de visión del sensor. La orientación de la mano
es definida por los vectores PalmNormal y Direction (Figura 2.21).

29
 B
A
B

Figura 2.21. Representación visual de los vectores a) PalmNormal y b) Direction de la API de Leap Motion.
Adaptado de Leap Motion Inc. (s.f.c).

El sensor Leap Motion registra información sobre cada dedo en la clase Finger. Si todo un dedo o
una parte de él no son visibles, sus características son estimadas. Cada dedo es identificado
mediante su nombre correspondiente en inglés: thumb (pulgar), index (índice), middle (medio), ring
(anular) y pinky (meñique).

Cada objeto de la clase Finger posee un atributo denominado TipPosition, que contiene las
coordenadas de la punta del dedo al que representa. Además, se proporciona el vector Direction,
que apunta en la dirección de dicho dedo. Una representación gráfica de TipPosition y de Direction
puede apreciarse en la Figura 2.22.

Figura 2.22. Representación visual de los vectores Tip Position y Direction de la API de Leap Motion.
Tomado de Leap Motion Inc. (s.f.c).

La clase Bone describe la posición y orientación de los huesos de cada dedo. Según el modelo que
utiliza Leap Motion, cada dedo contiene cuatro huesos, desde la base hasta la punta. El software
trabaja con un esquema basado en la estructura anatómica de la mano humana (Figura 2.23). Es
importante destacar que el modelo utilizado para el dedo pulgar no coincide con el sistema de
nombres anatómico estándar, esto es debido a que, para facilitar la programación, el modelo del
pulgar del sensor Leap Motion incluye un hueso metacarpiano de longitud cero, de forma que el
número de huesos sea igual para todos los dedos. Esto implica que el metacarpiano anatómico del

30
pulgar es identificado como un falange proximal y el falange proximal anatómico es identificado
como un falange medio.

Figura 2.23. Modelo de huesos utilizado por Leap Motion.

Adaptada de Leap Motion Inc. (s.f.c).

2.4 Realidad aumentada

La realidad aumentada o AR (augmented reality) es un término aplicado a todas aquellas

tecnologías capaces de superponer o combinar información alfanumérica, simbólica y gráfica con la
visión que el usuario tiene sobre el mundo real (Aukstakalnis, 2017, p. 2).

Azuma (1997, p. 2) comenta que la AR es una variante de la realidad virtual. Si bien, ambos
términos están relacionados, existe una diferencia principal entre estas tecnologías. La realidad
virtual coloca al usuario en un ambiente generado por una computadora, es decir, totalmente
sintético y mientras se encuentre inmerso dentro de él, no puede visualizar el verdadero mundo que
lo rodea. En contraste, la realidad aumentada permite que el usuario pueda ver objetos virtuales
superpuestos sobre el mundo físico, haciendo parecer que estos coexisten en el mismo espacio que
los objetos reales. De esta forma, la realidad se ve complementada en vez de ser reemplazada
completamente.

Muchas personas asocian la combinación de elementos reales y virtuales con el uso de efectos
especiales de producciones cinematográficas como Jurassic Park. No obstante, a pesar de que las
técnicas de gráficos por computadora usadas en las películas pueden ser aplicadas dentro de la
realidad aumentada, hace falta la existencia de un componente crucial: la interactividad. Por esta

31
razón, para evitar este tipo de confusiones, Azuma menciona que un sistema que implementa la
realidad aumentada debe cumplir con las siguientes características:

 Combina lo real con lo virtual.

 Es interactivo en tiempo real.
 La información es registrada en 3D.

Schmalstieg y Höllerer (2016, p. 3) aclaran que la AR no se limita a medios visuales, ya que puede
ser aplicada al resto de sentidos humanos como el oído, tacto, gusto y olfato; aunque resultan ser
más difíciles de implementar.

2.4.1 Aplicaciones de la realidad aumentada

En el campo de la salud, la realidad aumentada se utiliza como una herramienta que ayuda a los
cirujanos en tareas de visualización médica, permitiendo obtener información 3D empleando
sensores no invasivos, como los de resonancia magnética, tomografía axial computarizada o
ultrasonografía; permitiendo que el doctor tenga una visión interna del paciente en tiempo real sin
necesidad de realizar incisiones largas (Azuma, 1997, p. 3). Un ejemplo, es el software VitalStream
(figura 2.24), que provee información médica como los signos vitales o imágenes radiográficas
dentro del campo de visión del doctor y es compatible con gafas de realidad aumentada como
Google Glass o los R7 Smart Glasses (Aukstakalnis, 2017, p. 274).

Figura 2.24. Software VitalStream operando a través del dispositivo Google Glass.
Tomado de Aukstakalnis, (2017, p. 274).

La AR también se puede utilizar en tareas de entrenamiento, otorgando a un cirujano novato

instrucciones virtuales con los procedimientos a seguir, eliminando la necesidad de apartar la vista
del paciente para tener que consultar un manual.

32
La tecnología puede ser capaz de identificar órganos y ubicaciones específicas dentro del cuerpo
humano. Existen proyectos que han investigado esta área, como el caso de la Universidad de
Carolina del Norte en Chapel Hill, donde se han conducido experimentos en los que se realizaron
escaneos del vientre de una mujer embarazada utilizando un sensor de ultrasonidos para generar una
representación tridimensional del feto dentro del vientre, que es visualizada mediante unas gafas de
realidad aumentada (figura 2.25).

Figura 2.25. Feto virtual dentro del vientre de una mujer embarazada. Tomado de Azuma (1997, p.4).

Aukstakalnis (2017, p. 280) comenta que otras aplicaciones se pueden encontrar en la industria de
la aviación. La realidad aumentada ha sido utilizada en el desarrollo de software de entrenamiento
para pilotos. Un ejemplo es el simulador Fused Reality, diseñado por la NASA y la empresa System
Technology Inc. Este programa permite realizar misiones en las que al usuario se le presenta una
escena real donde se muestra el interior de la cabina y el mundo exterior, combinando imágenes de
objetos generados por computadora. Esto facilita a los pilotos la realización de sus prácticas de
vuelo sin los riesgo de los métodos de entrenamiento tradicionales, de este modo, si se da una
colisión con un avión virtual, simplemente se deberá reiniciar la aplicación para poder comenzar de
nuevo.

La Figura 2.26 muestra cómo Fused Reality añade un avión virtual generado por computadora a una
escena real del mundo exterior. Tanto la cabina como el paisaje del fondo son objetos verdaderos.

33
 Figura 2.26. Avión virtual generado por el software Fused Reality. Tomado de Aukstakalnis (2017, p. 282).

Dentro de la industria del entretenimiento, uno de los usos más populares de la realidad aumentada
ha sido en el mercado de los videojuegos. Empresas como Nintendo y Sony han lanzado
aplicaciones interactivas para sus consolas portátiles, Nintendo 3DS (Figura 2.27a) y PlayStation
Vita (Figura 2.27b), que permiten ver personajes y objetos 3D virtuales dentro del mundo real a
través de la pantalla del dispositivo. Para ello únicamente se requiere que el usuario apunte la
cámara de la consola hacia una serie de cartas o tarjetas de realidad virtual.

Figura 2.27. Realidad aumentada a través de las consolas a) Nintendo 3DS y b) PlayStation Vita.
Adaptado de Nintendo (2018) y Hollister (2012).

34
Otros videojuegos basados en realidad aumentada han sido lanzados para plataformas como
celulares y tabletas. Unos de los más populares son Ingress y Pokemon Go, desarrollados por la
empresa Niantic. Los mundos virtuales de ambos videojuegos están directamente basados en
ubicaciones del mundo real y requieren que el usuario se desplace dentro de los espacios públicos
de las ciudades para poder cumplir con una serie de objetivos. Además, permiten la interacción con
una serie de personajes y localidades completamente digitales a través de la cámara del dispositivo
móvil (Graglia, 2016).

2.5 Visión por computadora

Es una disciplina correspondiente a la inteligencia artificial y a las ciencias de la computación. Su

objetivo consiste en el análisis de imágenes capturadas por medio de una cámara con la finalidad de
obtener información de los objetos presentes en esa escena (Universidad Carlos III de Madrid,
2016). Busca la descripción del mundo real mediante la reconstrucción de ciertas propiedades de
una o varias imágenes, como la forma, iluminación y distribución de color (Szeliski, 2010, p. 5).

Según Huang (1996) desde un enfoque biológico, la visión por computadora pretende desarrollar
modelos computacionales basados en el sistema visual humano. Mientras que desde el punto de
vista de la ingeniería, el objetivo es la elaboración de sistemas autónomos capaces de realizar (y en
muchos casos superar) las funciones correspondientes a la visión humana.

Szeliski menciona que algunas de las aplicaciones modernas de la visión por computadora son las
siguientes:

1. Reconocimiento óptico de caracteres: como el análisis e interpretación de la escritura a

mano o la identificación automática de las placas de automóviles.
2. Modelado 3D: implica convertir una o varias fotografías de un objeto o persona en un
modelo 3D.
3. Reconocimiento facial: identificación de los rasgos faciales de una persona para permitir la
autenticación dentro de un sistema informático.
4. Vigilancia: análisis del tráfico en las carreteras, monitoreo de intrusos en una zona o el
monitoreo de piscinas para evitar víctimas por ahogamiento.

35
2.5.1 Imágenes digitales

Las imágenes son el elemento central dentro de la visión por computadora. Consisten en una
representación visual de una escena del mundo tridimensional. Una imagen se define como una
matriz o vector de dos dimensiones conformada por una serie de elementos conocidos como píxeles
(picture element). Cada uno de ellos contiene el nivel de iluminación o el color de un punto en la
escena (Alegre, Pajares y De la Escalera, 2016, pp. 11-12). De esta forma, una imagen con una
resolución de 35 x 35 es una matriz que contiene 35 columnas y 35 filas, dando un total de 1255
elementos o píxeles, como se puede apreciar en la Figura 2.28.

Figura 2.28. Representación de una imagen digital mediante una matriz de 35x35.
Adaptado de Pesco y Bortolossi (s.f.).

Los valores que contiene cada píxel representan desde niveles oscuros de luminosidad hasta valores
claros. El valor más bajo del intervalo es el nivel más oscuro y viene representado por el color
negro mientras que el nivel más claro corresponde al color blanco y es el valor más alto.

1. Cuantificación de una imagen digital

Cada píxel de una imagen digital contiene información del brillo de una escena. Estos valores son
continuos pero es necesario representarlos discretamente usando valores digitales. Si una imagen se
representa utilizando b bits, se tiene un total de 2b valores para los niveles de brillo de cada píxel,
los cuales pertenecen a un rango que va desde 0 hasta 2b – 1 (Nixon y Aguado, 2012, p. 38).

36
2. Imágenes en escala de grises

Un formato de imagen digital comúnmente utilizado es el de b= 8 bits. Este formato provee niveles
de brillo que van desde 0 hasta 255 que usualmente corresponden a los colores negro y blanco
respectivamente, mientras que las tonalidades de grises toman los valores intermedios, de forma
que se tiene un total de 256 valores que se le pueden asignar a cada elemento de la matriz de una
imagen (Nixon y Aguado, 2012, p. 38). La Figura 2.29 muestra una imagen a color junto con su
correspondiente imagen a escala de grises.

Figura 2.29. Imagen a) original junto con su imagen en b) escala de grises.

3. Imágenes binarias

Son aquellas en las que solo existen dos valores para sus pixeles, generalmente el número 0
corresponde al color negro y el 1 corresponde al blanco, por esta razón son conocidas también como
imágenes a blanco y negro. Dawson-Howe (2014, p.49) comenta que estas imágenes se obtienen
mediante un proceso conocido como umbralización. Es importante no confundirlas con las
imágenes a escala de grises, anteriormente descritas. Un ejemplo de imagen binaria se presenta en
la Figura 2.30 donde se aprecia que el objeto (un triángulo) es de color negro, mientras que el fondo
es de color blanco.

Figura 2.30. Ejemplo de una imagen binaria.

37
4. Imágenes a color

Requieren de la utilización de múltiples canales para representar la información de color. Esto las
vuelve más complejas que las imágenes en escala de grises, ya que estas últimas utilizan un solo
canal, por eso se dicen que son monocromáticas (Dawson-Howe, 2014, p.13).

Aunque el color es una característica muy importante que define a los objetos del mundo real, es un
parámetro al que no se le prestó mucha atención dentro de la visión por computadora sino hasta
hace poco tiempo. Esto debido a la memoria requerida para procesar este tipo de imágenes (como
citan Alegre et al, 2016, p.50).

Existen múltiples métodos para la representación visual de color en imágenes digitales, uno de ellos
es el modelo RGB (Red, Green, Blue) que utiliza tres componentes o colores primarios: rojo, verde
y azul. De esta forma, dentro de la matriz que corresponde a una imagen digital, para poder
representar color mediante RGB, cada píxel contiene información sobre la intensidad del brillo de
cada una de las tres componentes, los cuales toman valores que van desde 0 hasta 255 (si se trabaja
con 8 bits), de modo que hay un total de 16.8 millones de colores (256 x 256 x 256) que pueden ser
representados mediante este modelo (Dawson-Howe, 2014, p.14-16).

En la Figura 2.31 se puede apreciar una imagen a color que es descompuesta en tres imágenes
diferentes, cada una corresponde a los tres canales del modelo RGB.

Figura 2.31. Modelo RGB: descomposición de una imagen en sus tres canales.

38
5. Histograma de una imagen

Los píxeles de una imagen en escala de grises poseen valores que van desde 0 hasta 255. El
histograma de la imagen es el gráfico obtenido de la representación de la frecuencia de aparición de
cada uno de esos valores. Tomando en cuenta que el color negro es representado por 0 y el blanco
por el 255, el histograma muestra desde los píxeles oscuros hasta los claros. En la Figura 2.32 se
presenta una imagen en escala de grises junto con su respectivo histograma.

Figura 2.32. Imagen en escala de grises junto con su respectivo histograma.

6. Umbralización de una imagen digital

Una imagen binaria se obtiene a partir de una imagen en escala de grises por medio del proceso
conocido como umbralización (thresholding). Sea I la imagen original e I’ su imagen umbralizada,
U el valor de intensidad establecido como umbral, cada nuevo pixel I’(i,j) se obtiene mediante el
siguiente algoritmo (Dawson-Howe, 2014, p. 49):

Para todos los pixeles (i, j)

I’(i, j) = 1, si I(i, j) >= U
= 0, si I(i, j) < U

En este proceso, se seleccionan píxeles que poseen un valor particular o que se encuentran dentro de
un rango especificado. De esta forma, se les asigna el color blanco a todos los píxeles que sean
iguales o que se encuentran sobre el umbral y el color negro a aquellos que tienen valores por
debajo del umbral especificado. Generalmente se utiliza la umbralización para separar a un objeto
de interés de su fondo, esto se muestra en la Figura 2.33.

39
 Figura 2.33. Imagen a) en escala de grises b) junto al resultado de su umbralización utilizando U = 145.

2.5.2 Open Source Computer Vision Library (OpenCV)

OpenCV es una librería de software utilizada dentro de las áreas de visión por computadora y de
aprendizaje de máquina (machine learning). A pesar de estar desarrollada nativamente en el
lenguaje de programación C++ posee implementaciones para Python, Java y MATLAB y se
encuentra disponible para los sistemas operativos Windows, Mac OS, GNU/Linux y Android
(OpenCV team, 2018).

Algunas de las actividades en las que la librería OpenCV ha sido implementada incluyen: detección
de intrusos en labores de videovigilancia, ayuda a robots en la navegación y recolección de objetos
en almacenes, arte interactivo y la inspección de etiquetas en productos de fábricas.

2.6 Funcionalidades o herramientas matemáticas de minería de datos

De acuerdo a Han y Kamber (2006, p. 21) las tareas de minerías de datos pueden ser clasificadas en
dos categorías: descripción y predicción. Las tareas de descripción caracterizan las propiedades de
los datos de una base de datos. Las tareas predictivas realizan inferencias en los datos actuales con
la finalidad de hacer predicciones.

2.6.1 Modelos de clasificación

Clasificación es el proceso encargado de encontrar un modelo (o función matemática) que describe

y distingue distintas clases de datos, con el propósito de ser capaz de usar dicho modelo para
predecir la clase de objetos cuya etiqueta de clase es desconocida. El modelo resultante está basado
en el análisis del conjunto de datos de entrenamiento, es decir, datos cuya etiqueta de clase es
conocida (Han y Kamber, 2006, p. 24).

40
Desde el punto de vista de los ejemplos, el conjunto de aprendizaje debe poseer las siguientes
características: ser significativo, debe haber un número suficiente de ejemplos y ser representativo,
es decir que las muestras deberán ser diversas. Si un conjunto de aprendizaje tiene muchos más
ejemplos de un tipo que del resto, el clasificador se especializará en dicho subconjunto de datos y
no será de aplicación general. Es importante que todas las clases estén suficientemente
representadas en el conjunto de aprendizaje (Isasi y Galván, 2004, p. 10).

El modelo resultante puede ser representado en varias formas, por ejemplo, mediante reglas de
clasificación, árboles de decisión, fórmulas matemáticas o redes de neuronas artificiales.

Un árbol de decisión es un flujograma que sigue la estructura de un árbol, donde cada nodo denota
la comparación de la variable, cada rama representa un resultado de dicha comparación y las hojas
representan clases o distribuciones de ellas. Cabe mencionar que los árboles de decisión pueden ser
convertidos fácilmente a reglas de clasificación. La Figura 2.34 muestra el ejemplo de un árbol de
decisión generado con una herramienta de software conocida como Rattle, compatible con el
lenguaje de programación R.

Figura 2.34. Ejemplo de un árbol de decisión generado con la herramienta Rattle del lenguaje R.

2.6.2 Técnicas de agrupamiento (clustering)

Contrario a los modelos de clasificación que analizan las etiquetas de clases de objetos, el clustering
analiza los datos del objeto sin consultar etiquetas de clase. En general, las etiquetas de clase no
están presenten en los datos de entrenamiento, simplemente porque éstos no se conocen a priori. El
clustering puede ser utilizado para generar dichas etiquetas de clase. Los objetos son agrupados
basándose en el principio de maximizar la similitud intra-clase y minimizar la similitud inter-clase.

41
Los clusters se forman de manera que los objetos dentro de un mismo cluster tengan alta similitud
entre ellos, mientras que son muy distintos de aquellos objetos que se encuentre en otros clusters.
Cada cluster está diseñado para ser interpretado como una clase (Han y Kamber, 2006, pp. 25-26).

Una técnica de agrupamiento muy conocida y comúnmente usada es el algoritmo de k-means

(clustering basado en centroides), dicho algoritmo toma el parámetro de entrada k, y particiona una
serie de n objetos en k grupos o clusters de forma que la similitud intra-cluster resultante sea alta
pero la similitud inter-cluster sea baja. La similitud de cada cluster es medida en función del valor
medio de los objetos en el cluster, que podría ser visualizado como el centroide o el centro de
gravedad del cluster. En otras palabras, se intenta que los cluster sean lo más compactos y separados
posible. El procedimiento de k-means es resumido en la Figura 2.35.

Figura 2.35. Algoritmo básico de k-means. Adaptado de Campos (s.f.).

El método tiene una fase de entrenamiento (Figura 2.36), que puede ser lenta dependiendo del
número de objetos a clasificar y de la dimensión del problema. Pero una vez terminado el
entrenamiento, la clasificación de nuevos datos es muy rápida, gracias a que la comparación de
distancias se realiza sólo con los prototipos o centros (Isasi y Galván, 2004, p. 206).

Figura 2.36. Clusterización de un conjunto de objetos usando k-means.

Adaptado de Isasi y Galván (2004, p. 207).

42
Según Witten y Frank (2005, pp. 187 – 188), los clusters finales son bastante sensibles a los centros
iniciales, esto implica que pequeñas variaciones pueden producir resultados completamente
diferentes. De hecho, esto es cierto en la práctica para todas las técnicas de clustering: es
prácticamente imposible encontrar clusters óptimos globales. Esto se debe a que el mínimo
encontrado es uno local y no hay garantía de que ese sea el mínimo global.

Para incrementar la probabilidad de encontrar un mínimo global, se suele ejecutar el algoritmo

muchas veces con diferentes centros iniciales y se escoge el mejor resultado final (aquel con el
menor error cuadrático medio).

Cuando se conoce desde un inicio la etiqueta de clase de cada dato del conjunto de entrenamiento,
entonces se dice que el proceso de aprendizaje del clasificador es supervisado (ya que se sabe a qué
clase pertenece cada objeto). Lo contrario sucede con el aprendizaje no supervisado (o clustering)
donde las etiquetas de clase son desconocidas y tampoco se sabe la cantidad de clases existentes
(Han y Kamber, 2006, pp. 286-287).

2.6.3 Medición de la precisión de un clasificador

Usar el conjunto de datos de entrenamiento para crear un clasificador y luego estimar la precisión
del modelo resultante puede resultar en estimaciones demasiado optimistas y erróneas, porque se
estaría probando el modelo con muestras que ya han sido visualizadas. Por el contrario, la precisión
debe ser medida en un conjunto de datos que contiene etiquetas de clase que no han sido usadas
para entrenar el modelo. La precisión del clasificador dado dicho conjunto de datos es el porcentaje
de objetos que fueron clasificados correctamente por el clasificador (Han y Kamber, 2006, p. 360).

La matriz de confusión es una herramienta útil para analizar qué tan efectivo es el proceso de
clasificación. Dada M clases, la matriz de confusión es una tabla de dimensiones de M columnas
por M filas donde se colocan, para cada clase, los objetos que han sido clasificados correcta e
incorrectamente. En un clasificador que tenga buena precisión, idealmente, la mayoría de los
objetos estaría representado a lo largo de la diagonal principal de la matriz de confusión, mientras
que el resto de las casillas debería ser cero o un valor cercano a cero. La Figura 2.37 muestra tres
ejemplos de matrices de confusión generadas con Microsoft Excel (2.37a), el lenguaje de
programación R (Figura 2.37b) y el software Neural Designer (Figura 2.37c).

43
Figura 2.37. Ejemplos de matrices de confusión generadas con a) Microsoft Excel,
b) Lenguaje de programación R y c) Neural Designer.

44
 CAPÍTULO 3. METODOLOGÍA Y HERRAMIENTAS

Se realiza una descripción de las distintas etapas o fases que conformaron el desarrollo del proyecto.
Asimismo, se presentan herramientas que se usaron para llevar a cabo el proyecto y otras que
solamente se investigaron pero no fueron implementadas en el producto final debido a que estaban
fuera de los objetivos del mismo.

3.1 Reunión inicial

Los requerimientos básicos de la aplicación a desarrollar fueron establecidos. Se especificó la

necesidad de crear un sistema que permitiese controlar los movimientos de la mano del brazo robot
del DEI mediante un dispositivo de realidad aumentada, que en este caso fue el sensor Leap Motion,
capaz de detectar movimientos de ambas manos con alta precisión. Además, se solicitó expandir el
número de funcionalidades del software que controla el brazo robótico, enfocándose en que este
fuese capaz de desarrollar tareas de forma automática. Para ello, se acordó que se utilizarían
algoritmos de visión por computador, de modo que se creara un módulo que permitiera el
reconocimiento autónomo de objetos.

3.2 Reunión con el coordinador de la carrera de ingeniería eléctrica

Se solicitó acceso a la documentación correspondiente a la tesis del brazo original, específicamente

a una copia digital del reporte y al código fuente del software elaborado para operar el dispositivo,
incluyendo los programas empleados para operar las placas microcontroladoras Arduino.

Se notificó que no se tendría acceso al brazo del trabajo de graduación precedente, pues para marzo
de 2018 este no estaba funcionando, además que sería utilizado por otro grupo de tesis durante todo
el tiempo de desarrollo del presente proyecto. De este modo, el hardware original sería respetado,
siendo la única modificación el reemplazo del guante con sensores de flexión por el sensor Leap
Motion. El proyecto se desarrollaría en base a un modelo físico del brazo, ocupando un tablero
indicador compuesto por ledes. Además, se dio autorización para poder utilizar el sensor Kinect for
Windows V1, propiedad del DEI.

3.3 Comprensión del funcionamiento de los sensores

Debido a que se trabajó con dos sensores ópticos de realidad aumentada (Kinect for Windows V1 y
Leap Motion) que poseen tecnologías diferentes y que son usados para propósitos distintos.
Se estudió detalladamente las especificaciones técnicas de ambos dispositivos, tomando en cuenta

45
las limitantes que estos presentan. Además, se analizó la forma en que estos operan a nivel de
software, para ello, fue necesario realizar la consulta de la documentación oficial, de libros
electrónicos y se revisaron múltiples tutoriales disponibles en internet.

3.4 Análisis del hardware y software del brazo robótico original

El documento de tesis y todos los archivos de código fuente del brazo robótico fueron revisados
detenidamente. Se estudiaron todos los componentes involucrados en el proceso de control de la
extremidad robótica, haciendo especial énfasis en el modo en que estos se comunican.

Para garantizar la compatibilidad entre el tablero indicador a desarrollar y la extremidad superior

original, se buscaron cuáles datos son los necesarios para que el dispositivo robótico opere. Esta
lista de datos fue la base sobre la que se diseñó y construyó la nueva plataforma de escritorio. Para
las manos se necesita calcular el ángulo de abertura de cada dedo, mientras que para el brazo es
necesario calcular tres ángulos: la abertura horizontal del antebrazo, la abertura vertical del
antebrazo y la abertura del codo; sumando ocho ángulos en total para cada extremidad superior.

Estos ángulos se tomaron en cuenta tanto en la implementación de la plataforma de escritorio, en la

creación de los archivos de secuencias de movimientos y en el desarrollo del nuevo software que
controla el tablero indicador.

3.5 Herramientas del Leap Motion

La API del sensor Leap Motion provee soporte para la detección de herramientas (Figura 3.1).
Se describe como herramienta todo objeto que sea cilíndrico, más largo y más delgado que un dedo.
Se logró implementar esta funcionalidad en un prototipo aislado, pero no se incluyó en la
plataforma de escritorio final debido que, la interacción con herramientas no está contemplada
dentro de ningún objetivo del sistema.

46
 Figura 3.1. Herramienta interpretada por el sensor Leap Motion.
Tomado de (Leap Motion Inc., s.f.g).

3.6 Gestos del Leap Motion

Otra característica que presenta el sensor Leap Motion es el reconocimiento de gestos, como los que
se presentan en la Figura 3.2. También se logró implementar esta funcionalidad en un prototipo
aislado, pero no se incluyó en la plataforma de escritorio final debido a que, el diseño de la
extremidad superior original carece de los grados de libertad suficientes para poder emular algunos
de ellos.

A
C

Figura 3.2. Gestos que provee el Leap Motion: a) dibujar un círculo, b) movimiento lineal de
un dedo, c) presionar una tecla imaginaria. Adaptado de (Leap Motion Inc., s.f.h).

3.7 Parámetros utilizados en Hidrología Superficial

Durante la realización de los modelos clasificadores de figuras (tanto en base a distancia como en
base a color) se tomó en cuenta ciertos coeficientes que se ocupan para estimar la forma de cuencas
hidrológicas. Según Breña y Jacobo (2006, p. 37), el coeficiente de compacidad Kc: es la relación
entre el perímetro de la cuenca y la circunferencia del círculo que tenga la misma superficie. Es
decir, que se puede saber qué tan compacta o cuadrada es una figura mediante la Ecuación 3.1.

47
 (Ec. 3.1)

Otro ejemplo es la relación de circularidad Rci: es el cociente entre el área de la cuenca y el área
del círculo cuya circunferencia es equivalente al perímetro de dicha cuenca. Es decir que se puede
saber qué tan circular es una figura si se calcula la Ecuación 3.2.

(Ec. 3.2)

Estos coeficientes fueron calculados para cada figura de los conjuntos de entrenamiento de ambos
clasificadores, lastimosamente no ofrecieron resultados contundentes. En otras palabras, no
caracterizaban bien las clases y arrojaban valores cercanos inclusive en objetos de distintas clases.
Por eso se decidió no utilizarlos en el modelo final de los clasificadores.

3.8 Especificaciones técnicas de la computadora utilizada para el desarrollo de la plataforma

de escritorio

La computadora en donde se desee instalar el sistema debe cumplir con ciertos requisitos mínimos,
detallados en la Tabla 3.1.

Tabla 3.1. Requisitos mínimos de la computadora a utilizar.

Sistema operativo Windows 10

Puertos USB 3.0 1 (dedicado al sensor Leap Motion)
Puertos USB 2.0 1 (dedicado al sensor Kinect)
Resolución pantalla 1366 x 768 pixeles
Procesador Intel Core i3
110 MB (para ejecución)
Espacio de almacenamiento
15 GB (para desarrollo)

Es importante mencionar que los sensores de realidad aumentada no deberán ser conectados a la
computadora mediante un hub USB. Esto debido a que el sensor Leap Motion podría no recibir la
suficiente cantidad de energía o ancho de banda para poder funcionar correctamente (Edwin, 2018).

48
3.9 Herramienta de minería de datos Rattle

Una valiosa herramienta de minería de datos es el lenguaje de programación R. Con ella es posible
realizar una amplia gama de algoritmos matemáticos. Existe un complemento gratuito para R
llamado Rattle (Figura 3.3) que permite generar modelos de clasificación tales como: árboles de
decisión, bosques de decisión, máquinas de soporte vectorial, redes de neuronas artificiales, etc.

Figura 3.3. Interfaz gráfica del complemento Rattle.

Además, Rattle es capaz de realizar diferentes algoritmos para evaluar los modelos de clasificación
generados, por ejemplo: matrices de confusión (también conocidas como matrices de errores),
curvas de costo, curvas ROC, entre otros. No obstante dicha herramienta está diseñada para trabajar
con volúmenes grandes de datos, se logró implementar algunos árboles de decisión y sus
correspondientes curvas ROC para validarlos (Figura 3.4).

Figura 3.4. Curva ROC generada utilizando la herramienta Rattle .

49
Finalmente se decidió prescindir de dichos árboles de decisión por presentar el inconveniente de no
separar las características de las clases de manera óptima, es decir, los algoritmos que implementa
Rattle funcionan de mejor manera con conjuntos de entrenamiento más representativos (con mayor
cantidad de muestras) que los utilizados en el proyecto. Por eso se decidió crear árboles de decisión
manualmente utilizando el software Microsoft Excel.

3.10 Visión por computadora

Con el propósito de implementar la funcionalidad de reconocimiento autónomo de figuras fue

necesario aprender y entender los conceptos básicos de la visión por computadora. Para esto se
recurrió a un curso en línea de la Universidad Carlos III de Madrid, llamado Introducción a la
visión por computador: desarrollo de aplicaciones con OpenCV, disponible en la plataforma edx
(Universidad Carlos III de Madrid, 2016).

Dicho curso tiene una duración de siete semanas, se imparte de manera gratuita y abarca temas
como: cámaras digitales, la biblioteca OpenCV, imágenes digitales, espacios de color, reducción de
ruido, realce y detección de bordes, detección de movimiento, umbralización, reconocimiento de
patrones, entre otros.

Es importante mencionar que en dicho curso se trata el tema del seguimiento de objetos en
secuencias de imágenes, específicamente el algoritmo conocido como camshift. Dicho algoritmo se
logró implementar exitosamente junto con la cámara a color del sensor Kinect, como se muestra en
la Figura 3.5, sin embargo no se incluyó en la plataforma de escritorio final debido a que no era de
utilidad para los objetivos del sistema.

Figura 3.5. Prototipo que implementa el algoritmo camshift utilizando la cámara a color del sensor Kinect.

50
3.11 Utilización del sensor Kinect desde Windows Forms

El lenguaje de programación C# ofrece dos posibilidades para la creación de aplicaciones de

escritorio: WinForms (Windows Forms) y WPF (Windows Presentation Foundation). Ambas
presentan las mismas características en cuanto a procesamiento y capacidad de cálculo, sin embargo
difieren en la forma en que se crean sus entornos gráficos. Se decidió optar por WinForms debido a
la sencillez de creación y mantenimiento de interfaces gráficas de usuario.

Cabe mencionar que WinForms actualmente está cayendo en desuso debido a que con WPF se
pueden crear interfaces de usuario visualmente más atractivas. Esto presenta un inconveniente, ya
que todos los tutoriales existentes en Internet que explican cómo utilizar el sensor Kinect, están
orientados al uso de WPF. Por tal razón se creó un prototipo que, a base de prueba y error,
permitiera el uso del SDK del sensor Kinect junto con la tecnología WinForms.

3.12 Elección del lenguaje de programación y herramientas de software a utilizar

Para realizar la plataforma de escritorio se eligió al lenguaje de programación C# debido a su

robustez, abundante documentación, implementación tanto del paradigma orientado a objetos como
de la programación orientada a eventos, compatibilidad con ambos sensores de realidad aumentada
(Leap Motion y Kinect) y acceso nativo a la comunicación serial vía Bluetooth de la computadora.

En la Tabla 3.2 se encuentra un conglomerado de todas las herramientas utilizadas para la

realización del sistema.

Tabla 3.2. Herramientas de software utilizadas para la realización del proyecto.

Software Versión
IDE Visual Studio Community 2015 14.0
.NET Framework 4.6
Lenguaje de programación C# 6.0
Microsoft Excel Professional Plus 2010 14.0
IDE R Studio 1.1
Lenguaje de programación R 3.4.1
Rattle 5.1.0
Leap Motion SDK 2.3.1
Kinect SDK 1.8
Arduino 1.6.9
Librerías OpenCV versión para C++ 3.4.1

51
Finalmente, para la creación de los archivos que almacenarán las secuencias de movimientos era
necesario utilizar algún formato sencillo pero robusto que fuese capaz de almacenar de manera
ordenada una gran cantidad de valores, correspondientes a coordenadas y ángulos. Se decidió
utilizar los archivos de valores separados por coma CSV (comma separated values) por su sencilla
creación, eficiente mantenimiento y completa compatibilidad con C#, Microsoft Excel, R y Rattle.
Un ejemplo de este formato de archivo se encuentra en la Figura 3.6.

Figura 3.6. Archivo de valores separados por coma abierto utilizando:

a) Bloc de notas, b) Microsoft Excel, c) R y d) Rattle.

3.13 Cálculo empírico de la latencia en la plataforma de escritorio

Con el objetivo de saber cuánto tiempo transcurre desde que el usuario realiza una acción hasta que
dicha acción se envía vía Bluetooth ya sea al tablero indicador o al brazo robótico, pasando a través
de todas las clases y estructuras de datos respectivas a la plataforma de escritorio se realizaron
3 pruebas cuya duración fue de 1 min, 5 min y 10 min respectivamente.

Durante los 16 minutos (960 segundos) fueron recibidos, procesados y enviados en total
8757 paquetes. Es decir, en promedio 9.1219 paquetes por segundo. Si se divide 1 segundo entre la
cantidad anteriormente mencionada se obtiene como resultado una latencia aproximada
de 109.5 milisegundos.

52
3.14 Cálculo del porcentaje de uso de los servomotores

En el hardware original los servomotores del brazo y de los dedos eran utilizados en un 90% y en
un 9.7% respectivamente. Dichos porcentajes pueden calcularse a partir de sus especificaciones
técnicas, reflejadas en la Tabla 3.3:

Tabla 3.3. Especificaciones técnicas servomotores.

Adaptado de SparkFun Electronics (s.f) y de TowerPro (2014).

Característica Servomotor brazo Servomotor dedos

Nombre HS-805 BB MG946R
Ángulo operación 45° / 400 μs –
Dead band (mínimo cambio) 8 μs 1 μs
Velocidad operación (4.8V) 0.19 sec / 60° 0.20 sec / 60°
Velocidad operación (6.0V) 0.14 sec / 60° 0.17 sec / 60°

La cantidad de aberturas que un servomotor es capaz de representar puede calcularse con Ec. 3.3.
Cabe mencionar que, para este caso, deadband significa la cantidad mínima de microsegundos que
deben de cambiar en la entrada para que cambie la salida. Es decir, si hay un cambio en menor
cantidad de microsegundos que los especificados en el deadband, el servomotor no se moverá.

microsegundosmáximo −microsegundosmínimo
Cantidad de aberturas = (Ec. 3.3)
deadband

Por tanto, si originalmente se utilizaban enteros, era posible representar 180 aberturas distintas.
En el caso de los servomotores del brazo eso representa un 90% del total, ya que si 45° representa
400 μs entonces 180° representarán 1600 μs, esto se divide entre 8 μs (su respectivo deadband)
resultando en 200 posibles aberturas.

En el caso de los servomotores de los dedos, ya que no se mencionan cantidades específicas de

microsegundos entonces se utilizara el valor predeterminado que sugiere la librería servo.h de
Arduino, es decir 2400 μs como máximo y 544 μs como mínimo (Arduino, 2018f), esto se divide
entre 1 μs (su respectivo deadband) resultando en 1856 posibles aberturas.

Finalmente con el aumento de cifras significativas podemos afirmar que se podrían utilizar el 100%
de las posibles aberturas en ambos casos.

53
54
 CAPÍTULO 4. ANÁLISIS Y DISEÑO

4.1 Descripción general

Desde una perspectiva muy amplia, el sistema para control de brazo robótico consta de cinco
componentes que interactúan entre ellos tal como muestra la Figura 4.1.

Figura 4.1. Estructura general del sistema.

La plataforma de escritorio es el componente central, a través de ella fluye toda la información

generada por el sistema. Se trata de una aplicación de escritorio desarrollada en C#.

Los sensores ópticos de realidad aumentada utilizados son aquellos conocidos como Leap Motion y
la cámara Kinect for Windows v1, que detectan los movimientos que el usuario realiza y proveen
coordenadas de distintas partes de su cuerpo.

Los archivos de secuencias de movimientos contienen los ángulos y coordenadas de distintos

puntos de las extremidades superiores del usuario, brindados por ambos sensores, en formato
separado por comas. Serán generados automáticamente por la plataforma. Es importante mencionar
que, aunque su contenido puede ser fácilmente editado mediante Microsoft Excel o el bloc de notas,
el usuario deberá abstenerse de hacerlo para evitar futuras inconsistencias.

El quinto componente es un tablero indicador desarrollado con la finalidad de reemplazar al brazo

robótico original, se ha diseñado y construido teniendo cuidado de respetar la estructura de su
hardware, garantizando la compatibilidad entre ellos.

55
4.2 Plataforma de escritorio

Está conformada por diez clases, cada una realiza una tarea en específico. Se encuentran
organizadas en cuatro paquetes tal como expresa la Figura 4.2.

El paquete Vistas contiene la interfaz gráfica de usuario (GUI), consta de un solo formulario y es la
encargada de unificar todos los demás componentes del sistema.

Figura 4.2. Estructura general de la plataforma de escritorio

El paquete Controladores contiene clases que interactúan directamente con el hardware, es decir,
procesan los datos crudos que se reciben de los sensores de realidad aumentada y también envían
los datos ya procesados (ángulos) a las placas Arduino del tablero indicador.

El paquete Herramientas es una colección de funciones que son utilizadas por las demás clases, es
capaz de generar y leer archivos de secuencias de movimientos, en ellos se colocan los datos ya
procesados (ángulos más las coordenadas). También contiene herramientas gráficas, como las
utilizadas para crear animaciones y guardar imágenes.

El paquete Clasificadores es el encargado de interactuar con programas escritos en C++ que utilizan
las librerías OpenCV para caracterizar objetos, es decir extraer datos útiles como áreas, perímetros,
colores de imágenes, entre otros. Además es capaz de clasificar objetos utilizando algoritmos de
minería de datos, que fueron generados utilizando Microsoft Excel y el software estadístico libre R.

56
En los siguientes apartados, se explicarán de manera detallada cada uno de los procesos que ejecuta
el sistema. Un resumen de ellos se aprecia en el diagrama de casos de uso de la Figura 4.3.

Figura 4.3. Diagrama de casos de uso de la plataforma de escritorio

4.3 Panel de conexión

La primera tarea que debe ser ejecutada es la inicialización de todos los dispositivos, para esto el
sistema posee la pestaña mostrada en el Anexo G (p. G-1). Es importante recordar que la última
tarea que debe realizar el usuario antes de cerrar el sistema es des-inicializar los dispositivos, esto
con el fin de evitar futuros inconvenientes de conexión o su recalentamiento.

4.3.1 Inicializar Leap Motion

En el paquete Controladores se encuentra una clase llamada SensorLeapMotion, encargada de

administrar todo lo referente a dicho dispositivo. La primera acción que se realiza es la
inicialización, donde se pueden diferenciar dos eventos: onConnect que ocurre cuando la
57
computadora detecta que el Leap Motion está conectado y que éste ha sido reconocido por el
servicio de Windows, también onFrame que se activa cada vez que el sensor termina de capturar y
preparar un paquete de datos y está listo para enviarlo a la plataforma de escritorio, específicamente
a la función procesarFrame.

Dicha función recibe todos y cada uno de los paquetes de datos, sin embargo solamente se procesa
uno de cada ocho como se muestra en la Tabla 4.1, debido a la siguiente limitante mencionada en la
documentación oficial: el sensor Leap Motion usa cámaras infrarrojas para la detección y
seguimiento de manos, es posible tener acceso a las fotografías tomadas con dichas cámaras
mediante la función Frame.Images. Estas imágenes pueden ser utilizadas para realidad aumentada,
visión por computadora, entre otros fines (Leap Motion Inc., s.f.d). La función Wrap devuelve las
coordenadas en pixeles correspondientes a un objeto que se encuentre en escena, esta función por lo
general no es lo suficientemente rápida para transformar coordenadas a una alta cantidad de cuadros
por segundo. Para obtener cálculos en tiempo real se requeriría el uso de un programa sombreador
(shader program) compilado por aparte y ejecutado en una unidad de procesamiento gráfico (GPU),
comúnmente conocida como tarjeta gráfica (Leap Motion Inc., s.f.e).

En caso de presentarse algún problema, el usuario deberá asegurarse de: haber conectado
apropiadamente el sensor a un puerto USB 3.0, que el led verde se encuentre encendido y que el
servicio de Windows Leap Service se esté ejecutando.

Tabla 4.1. Distribución del procesamiento de frames ofrecidos por el Leap Motion.

Estado Proceso realizado

-1 Sensor Inactivo
0 Almacenar paquete de datos actual
1 Cálculos relacionados a los dedos pulgares
2 Cálculos relacionados a los dedos índices
3 Cálculos relacionados a los dedos medios
4 Cálculos relacionados a los dedos anillos
5 Cálculos relacionados a los dedos meñiques
6 Función: Imitación (graficar datos)
7 Función: Grabación
8 Enviar datos procesados a modelo físico

4.3.2 Inicializar Kinect

Análogamente existe la clase CamaraKinect encargada de administrar todo lo referente a este

dispositivo. Sin embargo, la inicialización es un poco diferente, por tanto, primero se verifica que el

58
sensor Kinect se encuentre conectado y que el servicio de Windows lo detecte correctamente, luego
se procede a activar cada uno de los tres Streams, que consisten en flujos de datos de distinta índole.

Primero se habilita el SkeletonStream que contiene coordenadas de hasta 20 puntos del cuerpo,
luego se habilita el DepthStream que puede visualizarse como un flujo de fotografías en escala de
grises donde el color de cada pixel indica la distancia de éste a la cámara y finalmente se habilita el
ColorStream que no es más que una secuencia de fotografías comunes y corrientes a colores, con
una resolución de 640x480 pixeles y velocidad máxima de 30 cuadros por segundo.

El siguiente paso es configurar el evento AllFramesReady que se activa cada vez que el sensor
Kinect tiene disponible un cuadro actualizado de cada uno de los tres Streams, es decir, espera que
los tres estén listos para lanzar el evento. Análogo al Leap Motion existe la función procesarFrame
que distribuye el procesamiento según muestra la Tabla 4.2.

Tabla 4.2. Distribución del procesamiento de frames ofrecidos por el sensor Kinect.

Estado Proceso realizado

-1 Sensor Inactivo
0 Función: Imitación
1 Descanso
2 Descanso
3 Función: Grabación
4 Enviar datos procesados a modelo físico
5 Función: Reconocimiento Distancia
6 Tomar fotografía para clasificador distancia
7 Función: Reconocimiento Colores
8 Tomar fotografía para clasificador colores

En caso de haber inconvenientes, el usuario deberá asegurarse de que: el sensor se encuentre

alimentado por un tomacorriente, conectado a un puerto USB 2.0, que la luz verde se encuentre
constantemente encendida (no intermitente) y que el servicio de Windows, denominado Kinect
Management se esté ejecutando.

Finalmente, el usuario deberá des-inicializar el Kinect antes de cerrar la aplicación, esto con la
finalidad de detener la captura de datos y apagar las cámaras y micrófonos, ya que de no hacerlo
existe el riesgo de recalentamiento. Cabe mencionar que este proceso puede durar aproximadamente
20 segundos.

59
4.3.3 Inicializar Módulos Bluetooth

La comunicación entre el LeapMotion, Kinect y el tablero indicador se lleva a cabo mediante el uso
de cuatro receptores Bluetooth, cada uno conectado a una placa Arduino. Primero, se realiza la
búsqueda de los elementos Bluetooth activos en el sistema operativo, para esto se realizan consultas
a la herramienta conocida como Instrumental de Administración de Windows (Windows
Management Instrumentation). Donde se filtran los dispositivos en base a su Device ID, como se
puede apreciar en la Figura 4.4.

Figura 4.4. Consulta realizada al WMI.

Los dispositivos Bluetooth conectados a las placas Arduino son los módulos HC-05 y HC-06.
Estos se identifican mediante un DeviceID, obtenido a través de su alias (BTHENUM). Posterior a
la identificación de cada puerto Bluetooth, se procede a asignar a cada uno con su correspondiente
parte del tablero indicador (mano derecha, mano izquierda, brazo derecho y brazo izquierdo).

La comunicación entre los sensores y los dispositivos Bluetooth se hace mediante la conexión a un
puerto COM (puerto serial), diferente para cada elemento de los brazos. De esta manera, todo
ángulo calculado por el sistema es enviado de forma inalámbrica a cada uno de los componentes del
tablero indicador utilizando un puerto de comunicación serial en particular.

4.4 Imitación de movimientos en tiempo real

El primer proceso realizado por el sistema es la imitación en tiempo real de los movimientos
realizados por el usuario, cuya estructura es mostrada en la Figura 4.5.

Figura 4.5. Proceso de imitación en tiempo real.

60
Como puede apreciarse, la imitación de los movimientos de las manos se hace de manera
simultánea a la de los brazos pero aislada de ésta. Es decir que son dos procesos distintos que
siguen la misma estructura y se ejecutan al mismo tiempo, pero de forma independiente uno del
otro. La plataforma de escritorio realiza este proceso en la pestaña Imitación (Anexo G, p. G-2).

4.4.1 Cálculos realizados con datos provistos por los sensores

Tanto la extremidad robótica original como el tablero indicador elaborado necesitan de dos tipos de
ángulos para que puedan operar los servomotores y los ledes respectivamente. El primer tipo
corresponde a los ángulos de abertura de cada dedo respecto a la palma de la mano. Mientras que el
segundo hace referencia a los brazos, específicamente los ángulos de abertura horizontal y vertical
de cada hombro y a los ángulos de abertura de cada codo.

Para calcular los ángulos relativos a la mano se utilizan los vectores Hand.Direction y
Finger.Direction, provistos por el Leap Motion, que devuelven un vector tangente a la palma de la
mano y un vector gradiente a la punta de cada dedo, es decir un vector posicionado en la punta de
los dedos con la dirección hacia donde apuntan, respectivamente. Dichos vectores pueden
apreciarse en la Figura 4.6.

C
A

B
A
A

Figura 4.6. a) Vector Hand.Direction, b) vectores Finger.Direction, c) ángulo devuelto por la operación
Vector.AngleTo. Adaptado de Leap Motion Inc. (s.f.c) y de Flamenco et al. (2017, p. B2)

Se utilizará la operación Vector.AngleTo para calcular el ángulo de abertura de un vector respecto a

otro. Dicho ángulo es devuelto en radianes, siempre es positivo y su magnitud es menor o igual a pi
radianes o 180° (Leap Motion Inc., s.f.f). Además, para garantizar compatibilidad con la extremidad
robótica del DEI, los ángulos correspondientes a los dedos índice y meñique se limitan a [0°, 150°]
mientras que los demás se limitan a [0°, 160°] (Flamenco et al., 2017, p. B2).

61
Para calcular los ángulos relativos al brazo se utilizan las articulaciones humanas: muñecas, codos y
hombros tanto izquierdos como derechos y un punto llamado ShoulderCenter que está ubicado
ligeramente arriba del punto central de una línea imaginaria que une ambos hombros. Dichos puntos
están resaltados de color verde en la Figura 4.7.

Figura 4.7. Articulaciones reconocidas por el Kinect v1. Adaptado de (Deltakosh, 2011).

A continuación se deducirán las ecuaciones que utiliza la plataforma de escritorio en el cálculo de

dichos ángulos, para esto es necesario recordar tres ecuaciones elementales de la matemática. Para
visualizarlas se tomarán como base los triángulos de la Figura 4.8.

A B C
A A

Figura 4.8. a) Triángulo oblicuángulo, b) dos puntos en R3, c) triángulo rectángulo.

62
La primera fórmula es la ley de los cosenos (Ec. 4.1) que se utiliza para relacionar la longitud y los
ángulos de cualquier triángulo, sea éste rectángulo o no. La segunda fórmula es la correspondiente a
la distancia entre dos puntos cualesquiera en el espacio (Ec. 4.3) y finalmente el coseno (Ec. 4.4), es
decir, la relación entre el cateto adyacente y la hipotenusa de un triángulo rectángulo.

(Ec. 4.1)

(Ec. 4.2)

(Ec. 4.3)

(Ec. 4.4)

Para el cálculo del ángulo de abertura de un codo (Ec. 4.5) se tomarán las coordenadas de un
hombro, un codo y una muñeca, denominados A, B y C respectivamente. Con estos tres puntos se
puede formar un triángulo oblicuángulo en el espacio, donde los vectores AB, BC y el ángulo B
corresponden a la longitud del bíceps, antebrazo y al ángulo de abertura del codo respectivamente.
Primero se usa (Ec. 4.3) para calcular dichas longitudes y finalmente (Ec. 4.2) para encontrar el
ángulo entre ellas.

(Ec. 4.5)

Los ángulos de abertura horizontal y vertical de los hombros son un tanto más complicados de
calcular, se tomarán las coordenadas de un hombro central, hombro derecho y codo derecho y se
llamarán puntos A, B y C respectivamente, tal como se muestra en la Figura 4.9.

63
 Figura 4.9. Coordenadas de un hombro central, hombro derecho y codo derecho.

El punto resaltado en color verde que se encuentra más a la derecha en la Figura 4.9 corresponde a
una proyección del punto C en una traza del eje Z a la altura de la coordenada Z del punto B, en
otras palabras, desplazar el codo respetando la altura original, y colocarlo en un punto donde no esté
ni delante ni detrás del cuerpo. Esto con el fin de deshacerse de la abertura horizontal y quedarse
solamente con la vertical. Dicho punto se encuentra resaltado en color rojo en la Figura 4.10. Cabe
mencionar que al hacer esta proyección, se pasa del espacio XYZ al plano XY.

Figura 4.10. Ángulo de abertura vertical del hombro.

El punto resaltado en color naranja en la Figura 4.10 corresponde a aquella coordenada que forma
un triángulo rectángulo cuya altura es igual (en valor absoluto) que la diferencia de alturas entre el

64
codo y el hombro de la persona. El ángulo formado entre el cateto vertical y la hipotenusa
representa la abertura vertical del hombro y puede ser calculado usando (Ec. 4.6) en dicho triángulo
rectángulo.

(Ec. 4.6)

Para calcular el ángulo de abertura horizontal del hombro se realiza un proceso similar, proyectando
los puntos A y C de la Figura 4.9 en una traza del eje Y a la altura de la coordenada Y del punto B,
es decir, sería como estar viendo a la persona desde arriba. Esto para deshacerse de la abertura
vertical y quedarse solamente con la horizontal.

Figura 4.11. Ángulo de abertura horizontal del hombro.

La magnitud del ángulo que interesa se encuentra resaltado de color naranja en la Figura 4.11,
correspondiente al ángulo suplementario (cuya suma da 180° o pi) al ángulo A’BC’ del triángulo
proyectado, cuya expresión matemática corresponde a la Ec. 4.7. Cabe notar que el signo depende
de las coordenadas Z de los puntos B y C, es decir, el signo depende de si el codo de la persona se
encuentra más cerca o más lejos del sensor Kinect que su hombro.

(Ec. 4.7)

65
4.4.2 Graficación de datos calculados

La plataforma de escritorio genera una visualización en tiempo real de las extremidades superiores
de la persona. Dicha visualización se ve enriquecida con el uso de realidad aumentada, es decir,
para facilitar la lectura de valores calculados por el sistema, estos son dibujados sobre cada imagen
o fotograma capturado por las cámaras, volviendo el proceso intuitivo y accesible para un usuario
sin entrenamiento.

Figura 4.12. Articulaciones interpretadas por la plataforma de escritorio.

En el caso de las imágenes provistas por el sensor Kinect, sobre ellas se dibujan los 23 elementos
que se muestran en la Figura 4.12: los seis ángulos calculados en el apartado 4.4.1, teniendo el
cuidado de dibujar cada uno lo más cerca posible de la articulación que representa y ocho
segmentos de recta que unen los nueve cuadros que representan algunas articulaciones del cuerpo,
cuyo color se encuentra en función de la distancia de cada una de ellas al Kinect, esto con la
finalidad de indicar al usuario si se encuentra muy cerca, muy lejos o en el rango óptimo de trabajo
del Kinect, estos valores se listan en la Tabla 4.3.

Tabla 4.3. Rangos de distancia al sensor Kinect.

Distancia Color Rango Cálculos

Menor a 90 cm Azul Demasiado cerca No se garantiza
Entre 90cm y 2m Verde Óptimo Óptimos
Mayor a 2m Rojo Demasiado lejos No se garantiza

66
Simultáneamente se hace un proceso similar con las imágenes provistas por el sensor Leap Motion
sobre las que se dibujan hasta un máximo de 48 elementos: cada uno de los diecinueve huesos de
conforman cada mano y además, ligeramente arriba de la punta de cada dedo, se dibuja su
respectivo ángulo de abertura respecto a la palma de la mano. Como se aprecia en la Figura 4.13.

Figura 4.13. Huesos de las manos interpretadas por plataforma de escritorio.

4.4.3 Ensamblaje de paquetes de datos que se enviarán al tablero indicador

Una de las principales mejoras que proporciona la actual plataforma de escritorio respecto del
software anterior es el aumento en la cantidad de cifras significativas de los ángulos. La extremidad
superior original maneja los ángulos como cifras enteras, tanto los de las manos como los de los
brazos. Esto se evidencia en el sketch de Arduino original mostrado en la Figura 4.14.

Figura 4.14. a) Programa esclavo de control del brazo, b) programa maestro

de control de los dedos, c) programa esclavo de control de los dedos.

En cambio, la nueva plataforma de escritorio es capaz de manejar los ángulos de los dedos hasta
con seis cifras decimales y los ángulos de los brazos hasta con dos cifras decimales. El
inconveniente se presenta al momento de enviar dichas cantidades a las placas Arduino vía
Bluetooth, ya que el buffer serial sólo permite recibir datos enteros de un byte de longitud (Arduino,
2018d). Para solventar dicho inconveniente se utiliza el proceso ilustrado en la Figura 4.15, donde

67
se convierte un flotante (cuyo valor sea mayor o igual a cero y menor a mil) a cinco bytes con un
valor que en este caso oscila entre 0 y 99.

Figura 4.15. Conversión de un flotante a un arreglo (conjunto) de bytes.

El objetivo es descomponer el número flotante en diez dígitos organizados en cinco parejas: la

primera toma el valor de “01” si el ángulo alcanza el valor de la centena o “00” en caso contrario,
mientras que las demás parejas representan (de izquierda a derecha) a las “decenas y unidades”,
“décimas y centésimas”, “milésimas y diez milésimas” y “cien milésimas y millonésimas”. Este
conjunto de parejas de números puede enviarse vía Bluetooth sin inconveniente alguno ya que su
menor valor posible es 00 y el mayor es 99, respetando el rango permitido para un byte que está
comprendido entre 0 y 255.

Por lo tanto, los diez ángulos de las manos y los seis ángulos de los brazos de una persona se
descomponen en conjuntos de 50 y 18 bytes respectivamente. Para finalizar, se añade un byte al
inicio del paquete que tiene un valor de 100, dicho byte es utilizado para señalar el inicio del
paquete y se diferencia de los demás ya que se encuentra fuera de su rango de valores (que oscila
entre 0 y 99).

4.4.4 Tablero indicador

El tablero indicador está conformado internamente por cuatro placas Arduino distribuidas de la
manera que ilustra la Figura 4.16. Si bien están diseñadas para trabajar en conjunto, también es
posible que cada una opere de forma independiente a las demás.

Figura 4.16. Interacción plataforma de escritorio y tablero indicador.

68
Las placas Arduino Mega tienen anexada una pantalla LED donde se visualizan cada uno de los
ángulos designados a dicha placa, es decir, la placa Arduino que reciba el paquete de datos del Leap
Motion mostrará los ángulos de abertura de los dedos mientras que la placa que reciba el paquete de
datos del sensor Kinect mostrará los ángulos de abertura de los brazos. Es importante aclarar que es
el software y no el hardware el encargado de sincronizar los paquetes de datos brindados por los
sensores de realidad aumentada. Esto provoca que la velocidad de actualización de los paquetes no
sea necesariamente la misma para ambos sensores.

Cada placa Arduino contiene un software que sigue la estructura base que se muestra en la Figura
4.17. Es importante mencionar que dicha estructura está diseñada para ser compatible tanto con el
tablero indicador como con la extremidad superior original, de modo que la incorporación del
nuevo software debería ser tan sencilla como solamente subir el sketch a las placas embebidas en el
brazo y verificar que los pines se encuentren conectados donde deberían. Para mayor información,
el código fuente completo de las cuatro placas Arduino se encuentra en los Anexos C, D, E y F.

Figura 4.17. Estructura base del software de las placas Arduino.

En el Anexo H (p. H-1) se aprecia el circuito correspondiente al Arduino del brazo derecho. Cabe
mencionar que el circuito de la mano derecha (Anexo H, p. H-3) sería muy similar, con la única
diferencia de que la cantidad de ledes y botones se incrementaría a cinco y diez respectivamente.

Respecto al circuito correspondiente al Arduino del brazo izquierdo, su diagrama puede apreciarse
en el Anexo H (p. H-2). Análogamente, el circuito de la mano derecha (Anexo H, p. H-2) es
idéntico a excepción de la cantidad de ledes. Estos se incrementan a cinco, uno por cada dedo.

69
4.5 Grabación de movimientos para posterior reproducción

El segundo proceso realizado por el sistema es la grabación de secuencias de movimientos en

archivos de valores separados por coma (CSV), con la finalidad de que éstos sean reproducidos en
cualquier momento en el futuro. Este proceso se esquematiza en la Figura 4.18.

Figura 4.18. Proceso general de grabación de secuencias de movimientos.

Esta valiosa característica proporciona a la plataforma de escritorio varias utilidades que tienen el
potencial de ser implementadas en el futuro, como por ejemplo: almacenar posturas o gestos de
pacientes, reconocimiento de lenguaje de señas, corregir defectos de motricidad de personas, entre
otros. La plataforma de escritorio realiza este proceso en la pestaña Grabación (Anexo G, p. G-2).

El proceso de grabación comparte ciertas similitudes con el de imitación de movimientos en tiempo

real, tanto así que las etapas de cálculo y graficación de los ángulos son idénticas para ambas
funcionalidades. La diferencia entre ellas radica en el tratamiento posterior que reciben los ángulos
y coordenadas de las extremidades superiores de la persona, ya que en la grabación tanto los
ángulos como las coordenadas se almacenan en archivos de valores separados por comas, mientras
que para la imitación solamente los ángulos se envían al tablero indicador.

Otra gran diferencia radica en que durante la imitación en tiempo real, el tratamiento de los datos
referentes a las manos se da de manera independiente o aislada a la de los brazos. Esta situación
cambia durante la grabación, ya que es necesario que exista sincronización entre ambos sensores
(Kinect y Leap Motion) para poder almacenar de manera ordenada todos los ángulos y coordenadas
en dichos archivos de valores separados por coma.

De lo anterior surge la necesidad de crear una estructura de datos compartida, que sea lo
suficientemente robusta como para almacenar tanto los datos referentes a los brazos (los ángulos de
abertura de ambos brazos y las coordenadas de todas las articulaciones utilizadas para graficación)

70
como los datos referentes a las manos (los ángulos de abertura de cada dedo, las coordenadas de
cada hueso que conforma cada mano y las coordenadas de la punta de cada dedo).

Además es necesario crear una clase que administre dicha estructura de datos compartida y que
durante la grabación, vaya almacenando los datos de ambos sensores de manera ordenada y
sincronizada. Dicha clase, cuyo nombre es Grabadora, también debe ofrecer la posibilidad de
generar archivos de secuencias de movimientos teniendo el cuidado de ser lo más apegada y fiel
posible a los movimientos que la persona esté realizando.

Los archivos de secuencias de movimientos están conformados por registros de 225 datos,
distribuidos de la siguiente manera:

a. Bandera indicadora del tipo de sensor que generó el presente registro. Toma el valor de 0 o 1
si se trató del Kinect o del Leap Motion respectivamente.
b. Paquete de datos de los brazos, formado por 33 cantidades (6 ángulos y 27 coordenadas).
c. Paquete de datos de las manos, formado por 191 valores (10 ángulos de abertura, 10
coordenadas de puntos ubicados en la punta de los dedos, 1 entero que indica la cantidad de
huesos detectados y finalmente las coordenadas de cada hueso, que pueden llegar a ser un
máximo de 80).

La cantidad de registros depende de la duración de la grabación, cabe mencionar que cuando es el

sensor Kinect el que genera el paquete entonces se coloca 0 en todos los datos del Leap Motion.
Lo contrario ocurre cuando es el Leap Motion el que genera el paquete, en este caso se coloca 0 en
todos los datos del Kinect. Esto puede verse en la Tabla 4.4.

Tabla 4.4. Estructura de los archivo de secuencias de movimientos.

Bandera Datos Kinect Datos Leap Motion

0 Ángulos (brazos) Coord. (brazos) 0 0 0 0 0 0
1 0 0 0 0 0 0 Ángulos (manos) Coord. (manos)
0 Ángulos (brazos) Coord. (brazos) 0 0 0 0 0 0
1 0 0 0 0 0 0 Ángulos (manos) Coord. (manos)
1 0 0 0 0 0 0 Ángulos (manos) Coord. (manos)
0 Ángulos (brazos) Coord. (brazos) 0 0 0 0 0 0

71
4.6 Reproducción de movimientos pre-grabados

El tercer proceso realizado por el sistema es la reproducción por parte del tablero indicador de
los movimientos que se grabaron en el pasado y que se encuentran almacenados en archivos de
valores separados por coma. Esto se realiza en la pestaña Reproducción (Anexo G, p. G-2).
Dicha funcionalidad puede dividirse en las cuatro etapas que se muestran en la Figura 4.19.

Figura 4.19. Proceso general de reproducción de movimientos pre-grabados.

Durante la primera etapa la plataforma de escritorio lee, interpreta y carga en memoria todos los
datos contenidos en una secuencia pre-grabada. Dicho proceso sucede tan rápido que es
prácticamente imperceptible para el usuario.

En segundo lugar, se le ofrece al usuario la posibilidad de generar una animación a partir de dicha
secuencia pre-grabada. El proceso de graficación de dicha animación es similar al que se realiza en
el apartado de imitación en tiempo real (apartado 4.4.2), con la diferencia de que los datos
calculados (ángulos y coordenadas) son dibujados sobre un lienzo en blanco (Figura 4.20).

Figura 4.20. Animación generada a partir de archivos de secuencias de movimientos.

Una vez que el usuario ha visualizado la animación, es posible que esté conforme con ella o que
desee remover algunos cuadros de la secuencia pre-grabada. Esto podría ocurrir con mayor

72
frecuencia al inicio o al final, ya que la persona tiene que detenerse e interactuar con la plataforma
de escritorio para poder comenzar y detener la grabación, obligando a la persona a realizar algún
movimiento innecesario. Por esta razón se ha implementado la etapa llamada depuración de
secuencia pre-grabada, que el usuario puede optar por utilizar o no.

Finalmente la secuencia pre-grabada se encuentra lista para ser enviada al tablero indicador.
Este proceso es similar al descrito en el apartado 4.2 (imitación en tiempo real), con la diferencia de
que dicha acción puede ser repetida tantas veces como el usuario desee.

4.7 Reconocimiento autónomo de objetos

La cuarta funcionalidad que ofrece la plataforma de escritorio es el reconocimiento de objetos, para

ello destina la pestaña Reconocimiento (Anexo G, p. G-3). Es decir, la diferenciación de estos
respecto a su entorno. Siendo dicha tarea la que aporta el componente autónomo al sistema.
Este proceso (esquematizado en la Figura 4.21) puede realizarse bajo dos modalidades de detección:
por color y por distancia.

Figura 4.21. Esquema general del proceso de reconocimiento de objetos.

Cabe aclarar que la modalidad de detección por distancia se refiere a que el objeto se encuentre en
el rango óptimo de detección del Kinect pero no así su fondo (los objetos que lo rodean).

El reconocimiento comienza cuando el sensor Kinect toma una fotografía de los objetos que se
encuentran en escena. A continuación dicha fotografía es procesada por un programa que extrae sus
características (por ejemplo área, perímetro, entre otros) desarrollado en C++ utilizando las librerías
OpenCV, detallados en los Anexos A y B.

73
La plataforma de escritorio lee las características de cada objeto y las procesa con un algoritmo de
clasificación. Dicho algoritmo utiliza herramientas matemáticas de minería de datos (detalladas en
el apartado 4.7.4 de esta sección) para predecir la clase a la que pertenecen cada uno de los objetos.

Finalmente, teniendo ya clasificados los objetos, si se tiene una cruz roja al centro de la escena y el
usuario desea que el tablero indicador “señale” hacia las cruces o hacia los objetos rojos, bastaría
con enviar la instrucción correspondiente a “señalar hacia el centro”, almacenada como un archivo
de valores separados por coma.

4.7.1. Diseño y elaboración de figuras (clases del modelo)

La plataforma de escritorio ofrece dos modalidades distintas para la detección de objetos basado en
la idea de que en algún momento en el futuro, el software creado para el presente trabajo de
graduación se unifique con la extremidad superior derecha original reparada (para marzo de 2018
no se encontraba operativa, cabe mencionar que no se tuvo acceso a dicha extremidad durante todo
el tiempo que duró el proyecto) e integrada con una nueva extremidad superior izquierda.

De darse este suceso, el robot será capaz de reconocer tanto objetos que se encuentren entre 90cm y
2m (usando la modalidad de detección en base a distancia) como otros objetos que estén fuera de
ese rango (usando la modalidad de detección en base a colores) donde el Kinect estaría siendo
usado como una simple cámara que toma fotografías a color.

Cinco figuras fueron elegidas para realizar la detección por color, estas son: cuadro grande (5.5 cm
por lado), cuadro pequeño (2.5 cm por lado), cruz (5.5 cm de ancho y de alto), triángulo (5.5cm de
alto y 3cm de base) y círculo (3.5 cm de diámetro); mostradas en la Figura 4.22.

Figura 4.22. Figuras a clasificar en base a su color.

74
Se eligieron los colores rojo, verde y azul para imitar el modelo RGB. Además, se agregaron los
colores blanco y negro pues representan la suma y ausencia de los colores antes mencionados.

Para la clasificación de objetos en base a su distancia, se eligieron tres siluetas de cartón

correspondientes a un rectángulo (con base de 19.5 cm y altura de 48 cm), una cruz (con un ancho y
alto de 48 cm) y un triángulo (36 cm de alto y 19.5 cm de base); además de una botella opaca
(obtenida en la conferencia titulada Reducción en el uso de botellas de plástico a través de fuentes
de agua filtrada dentro del campus universitario, Hidalgo 2018) y un peluche esférico que se
asemeja a una pelota de baloncesto. Todos estos objetos se muestran en la Figura 4.23.

Figura 4.23. Figuras utilizadas para la clasificación en base a distancia.

Cabe mencionar que el color de los objetos no es relevante para la detección en base a distancia, las
figuras hechas con cartón se dejaron con su color original. De igual manera con la botella y el
peluche con forma de pelota de baloncesto. Esta modalidad de detección funciona incluso en
escenarios de nula iluminación o con objetos que poseen colores complejos o muy parecidos a los
de su entorno. Es importante mencionar que este proceso sería extremadamente difícil de realizar
sin un sensor Kinect.

4.7.2. Obtención de imágenes o fotografías para el conjunto de entrenamiento

La etapa de aprendizaje es una de las fases más importantes en los problemas de clasificación, ya
que es aquí donde se determina los tipos de objetos que podrán ser reconocidos. Esto significa que

75
la capacidad de un clasificador para distinguir entre una clase de objetos y otra está ligada de forma
fundamental al tipo de ejemplos disponibles durante el proceso de aprendizaje.

Para cumplir con los criterios mencionados en el apartado 2.6.1 (modelos de clasificación) la
cantidad de fotografías que se tomen debe ser significativa (se necesita disponer de un número
suficiente de imágenes). Además, debe ser representativa, es decir, idealmente se debe tomar la
misma cantidad de imágenes para cada clase o tipo de objeto. Por ejemplo el número de fotografías
de los triángulos debe ser igual o similar que el número de fotografías de las cruces.

Para la modalidad de clasificación a distancia se tomaron un total de cien fotografías (una muestra
se puede apreciar en la Figura 4.24), distribuidas uniformemente entre las cinco clases de objetos
(veinte para cada una). Este número se elevó considerablemente en el caso de la clasificación por
color, ya que además de tomar en cuenta la cantidad de clases de objetos, es necesario considerar
todas las combinaciones de colores del fondo y de las figuras. No es lo mismo una imagen con una
figura de color negro y fondo blanco (que podría ser tratada en escala de grises) que otra imagen
con una figura de color azul y fondo verde (pues se tiene que trabajar con sus canales de color).

Figura 4.24. Fotografías tomadas para entrenar clasificador en base a distancia.

Si se quiere tener en el conjunto de entrenamiento diez ejemplos para cada una de las cinco clases,
entonces la cantidad de muestras que se capturarían (si no se tomara en cuenta el color) es de
cincuenta. Sin embargo, este número debe ser multiplicado por la cantidad de combinaciones
posibles de color del fondo y de la figura.

76
Ahora bien, descartando los casos donde el color de la figura es el mismo que el color del fondo,
entonces la cantidad de combinaciones posibles es de veinte. Porque para cada uno de los cinco
colores disponibles para el fondo, se pueden poner figuras de los cuatro colores sobrantes. Esto nos
conduce a la cantidad total de muestras que se tomaron para entrenar al clasificador: 1000, que
resulta de multiplicar 50 (total de muestras sin tomar en cuenta el color) con 20 (cantidad de
combinaciones posibles de colores). Finalmente, un subconjunto de dichas imágenes se aprecia en
la Figura 4.25.

Figura 4.25. Fotografías tomadas para entrenar clasificador en base a color.

4.7.3. Extracción de características del conjunto de entrenamiento

A continuación se describe el proceso que toma como entrada cada una de las imágenes del
conjunto de entrenamiento y produce como salida un solo archivo de valores separados por coma
que contiene las características de todas ellas, expresadas como parámetros numéricos.

Esto es imprescindible, ya que dichas imágenes no pueden ser utilizadas directamente para entrenar
el clasificador. Para esto se codificó un programa en C++ que utiliza las librerías OpenCV. Este
proceso está conformado por las siguientes siete etapas:

En la primera etapa se carga en memoria la fotografía original provista por la cámara del Kinect
mediante la función imread (Anexo A, p.A-1), un ejemplo de ello se muestra en la Figura 4.26.

77
 Figura 4.26. Fotografía original a colores, no posee tratamiento alguno.

Durante la segunda etapa, de la imagen original se toman por separado tres secciones de 200x200
pixeles (Figura 4.27) mediante la función copyTo (Anexo A, p.A-1), que corresponden a los objetos
situados al frente, a la izquierda y a la derecha de la cámara.

Figura 4.27. Regiones recortadas de imagen original.

La tercera etapa es particularmente importante y complicada de implementar, ya que requiere la

creación de un algoritmo que calcule el mejor umbral (cuasi-óptimo) para cada modalidad de
detección de objetos, mediante la función calcularUmbral (Anexo B, p.B-1). En otras palabras,
incluso pequeñas variaciones en la iluminación de la escena podrían afectar el proceso de
umbralización y generar imágenes binarizadas de mala calidad. De esto surge la necesidad de
calcular umbrales personalizados cada vez que se quiere detectar un objeto.

El caso más sencillo es el de detección por distancia, ya que la umbralización se realiza

prácticamente desde que la clase CamaraKinect toma la fotografía. Cabe recordar que los objetos
que se encuentran en el rango óptimo de detección de la Kinect son resaltados en color verde, esto
con la finalidad de umbralizar dichas imágenes utilizando su canal verde, como se aprecia en la

78
función threshold (Anexo A, p.A-1). El valor del umbral utilizado es 128 ya que es el punto
intermedio del rango de valores aceptados en un byte (cuyo mínimo es 0 y máximo es 255).

Para la modalidad de detección por color, la dificultad de umbralizar radica en que deben tomarse
en cuenta todas las combinaciones de color que presentan la figura y el fondo. Un ejemplo son los
umbrales basados en intensidad (valores en escala de grises, implementado usando la función
cvtColor, Anexo B, p.B-4) que sirven para separar objetos de su fondo en combinaciones blanco-
negro que podrían no funcionar para combinaciones rojo-verde.

Otro ejemplo es el de los umbrales basados en algún canal de color (obtenidos mediante la función
split, Anexo B, p.B-4), ya que si se escoge el canal verde para separar objetos verdes de fondos de
otros colores; dicho umbral no sería el más adecuado para detectar objetos rojos en escenarios
azules.

El proceso a seguir es el siguiente: se toman 392 pixeles de los bordes de la imagen y 64 pixeles del
centro para calcular los promedios respectivos. Tomando en cuenta que cada pixel provee cuatro
datos (su cantidad de rojo, verde, azul y su intensidad, es decir, el promedio de las tres anteriores)
esto puede realizarse de cuatro maneras distintas. Finalmente, se busca en cuál de dichas 4
posibilidades la diferencia entre los promedios es más grande. El umbral deseado es el punto
intermedio entre ambos promedios. Esto se encuentra implementado al final de la función
calcularUmbral (Anexo B, p.B-3).

En la cuarta etapa del proceso de extracción de características se lleva a cabo la umbralización de

las imágenes obtenidas en la segunda etapa, esto con la finalidad de obtener imágenes binarizadas.
Se utiliza el umbral calculado en la tercera etapa. Esto puede ser visualizado en la Figura 4.28.

Figura 4.28. Imágenes binarizadas utilizando umbral personalizado.

79
La quinta etapa consiste en encontrar todos los contornos presentes en escena (Figura 4.29)
mediante la función findContours (Anexo B, p.B-4). En problemas de mayor complejidad es común
que este proceso arroje “basura”, es decir, detecte contornos que no son los que interesan. Esto
puede deberse a cambios bruscos de iluminación o umbralizaciones establecidas arbitrariamente.

Este inconveniente se corrige mediante el cálculo de umbrales cuasi-óptimos personalizados para

cada imagen, que se adaptan a la iluminación actual de la escena. Cabe mencionar que se utiliza el
término cuasi-óptimo para expresar que no se obtiene el valor óptimo (que requeriría de cálculos de
mayor complejidad) sino un valor razonablemente cercano a él.

Figura 4.29. Contornos obtenidos a partir de imágenes binarizadas.

La sexta etapa extrae características de los contornos obtenidos en la quita etapa (en forma de
coeficientes numéricos) con la finalidad de ofrecer al clasificador tantas variables como le sea
posible. Cabe mencionar que no se espera que el clasificador utilice todas las características
calculadas, pero sí que tenga más opciones de donde elegir.

Algunas de las características calculadas son: área, perímetro, altura y anchura (Figura 4.30a), área
de la envolvente convexa a la figura (Figura 4.30b) y el área mínima de diferentes figuras que
envuelven al objeto: triángulo (Figura 4.30c), elipse (Figura 4.30d) y círculo (Figura 4.30d).

Algunas funciones utilizadas fueron: contourArea, convexHull, minEnclosingTriangle, fitEllipse

(Anexo B, p.B-4). Cabe mencionar que para las figuras a colores también se almacenó el color
estimado de la figura y del marco (o fondo de la escena).

La última etapa corresponde al proceso de almacenar las características extraídas en un solo archivo
de valores separados por coma, llamado resultadosCaracterizacionColores.csv (Anexo B, p.B-5).

80
Dicho archivo se somete a una serie de pruebas y algoritmos de minerías de datos mediante el uso
de software especializado como Microsoft Excel y R.

A B C

D E

Figura 4.30. a) Rectángulo rotado de área mínima, b) envolvente convexa, c) triángulo de área mínima,
d) elipse que asemeja contorno, e) círculo de área mínima que envuelve la figura.

4.7.4. Generación del modelo clasificador que trabaja en base a la distancia

(análisis de muestras mediante R y Microsoft Excel)

En primera instancia, se codificó en R el programa que se muestra en la Figura 4.31 para visualizar
el conjunto de entrenamiento. Las variables que brindaron mayor separación entre cada clase de
objeto fueron el perímetro, el ancho y el alto.

Figura 4.31. Programa escrito en R que grafica en 3D el conjunto de entrenamiento.

81
Debido a la forma en que se agrupan los datos, se consideró a K-means un candidato perfecto para
realizar la clasificación. En la Figura 4.32 se aprecia un programa en R que ejecuta K-means en el
conjunto de entrenamiento, y también los centros a los que converge dicho método.

Figura 4.32. Implementación de K-means en R.

El método trabaja bastante bien, ya que ha logrado clasificar de manera casi perfecta. Esto queda en
evidencia en la Figura 4.33, que presenta a todas las muestras bien clasificadas a excepción de la
etiquetada con el número 77, que es agrupada dentro del clúster 5 a pesar de que debería pertenecer
al clúster 4.

Figura 4.33. Visualización de los clusters generados por K-means.

En un problema más complejo, el hecho de que solamente clasifica mal una muestra se consideraría
un resultado excelente. Pero se quiso profundizar más y refinar el modelo de clasificación
añadiéndole un árbol de decisión en aquellos casos que K-medias no sea contundente, es decir,
cuando la distancia a los dos centros más cercanos sea parecida.

Para generar el modelo de árbol de decisión, se graficaron las características de cada clase haciendo
uso de Microsoft Excel. Algunas variables resultaron ser poco útiles, ya que sus valores no
mostraban diferencias significativas entre una clase y las demás, tal es el caso del perímetro o el
radio del círculo de área mínima que rodea al objeto (Figura 4.34). En otras palabras, hay cuadros
que tienen el mismo perímetro que algunas cruces y algunos triángulos.

82
 Figura 4.34. Variables que no caracterizan bien a las figuras.

Mientras que unas variables sólo logran diferenciar algunas clases de otras, como el área sobrante
de la envolvente conexa respecto de la original (Figura 4.35a) y la proporción de espacio sobrante
del rectángulo de área mínima que envuelve a la figura (Figura 4.35b). Hay otras que hacen bien su
trabajo como el área (Figura 4.35c) y el área sobrante del triángulo más pequeño que envuelve a la
figura (Figura 4.35d).

A B

D C

Figura 4.35. Variables que caracterizan muy bien cada clase de figuras: a) área sobrante de la envolvente
conexa respecto de la original, b) proporción de espacio sobrante del rectángulo de área mínima que envuelve
a la figura, c) área de la silueta y d) área sobrante del triángulo más pequeño que envuelve a la figura.

Para finalizar, el proceso a seguir es el siguiente: primero se aplica k-means (Figura 4.36a) y se
verifica si el resultado ha sido contundente (esto puede suceder cuando la muestra es cercana a
algún centro de clase o cuando la distancia al centro más cercano es mucho menor que al segundo
centro más cercano), en caso contrario se aplican las reglas de clasificación obtenidas a partir del
árbol de decisión calculado (Figura 4.36b).

83
 A B

Figura 4.36. Modelo de clasificación de figuras en base a distancia: a) método de k-means,

b) reglas de decisión de un árbol de decisión.

4.7.5. Generación del modelo clasificador de figuras que trabaja en base al color

Este proceso se divide en tres etapas: separar la figura del fondo (se logra con el algoritmo de
umbralización y posterior binarización de la imagen), reconocimiento de colores (es decir, clasificar
el color del marco y la figura en uno de los cinco colores posibles) y finalmente clasificar la silueta
del objeto (que requiere de otro clasificador completamente independiente).

El primer clasificador, que se encarga de distinguir colores se obtuvo de la siguiente manera. En un

inicio, con el objetivo de visualizar los colores de las muestras, se codificó un programa en R
(Figura 4.37) para graficar cada muestra en un espacio 3D, cuyas coordenadas corresponden a
intensidad en cada canal de color: rojo, verde y azul respectivamente.

Figura 4.37. Visualización en tres dimensiones de los datos de entrenamiento

correspondientes a los colores del margen y de las figuras.

La Figura 4.37 presenta dos inconvenientes: el primero de ellos es que los colores no se agrupan
entre sí, esto imposibilita usar k-means ya que idealmente se deberían apreciar cinco grupos

84
aislados unos de otros. El segundo inconveniente es que incluso habiendo tomado las fotografías
con la misma iluminación, existen pequeños cambios en ella que se evidencian en la forma alargada
que tiene los datos, prácticamente paralela a la recta que une los colores negro y blanco perfectos.

Ya que k-means no es un método adecuado, se recurre a árboles de decisión. Nuevamente se utiliza

Microsoft Excel para visualizar el comportamiento de variables referentes al color que sirvan para
distinguir unos de otros. En la Figura 4.38 se aprecia las intensidades de cada canal de color.

Figura 4.38. Componentes de los colores negro, blanco, rojo, verde y azul.

A simple vista, dichos datos no aportan mayor utilidad. Hace falta notar pequeños detalles, como
por ejemplo: la componente roja separa los colores negro y azul de los demás (Figura 4.39a), las
componentes azul y verde difieren para el color verde (Figura 4.39a), las componentes azul y roja
difieren en los colores negro y azul (Figura 4.39b) y las componente roja y verde difieren en el
color rojo (Figura 4.39c).

Figura 4.39. Distintas combinaciones de componentes de color.

En base a las gráficas de la Figura 4.39 es posible calcular un árbol de decisión que clasifique
efectivamente los colores. Las reglas de clasificación obtenidas a partir de éste, se listan en la
Figura 4.40 y se implementan en el Anexo B, p.B-2.

85
 Figura 4.40. Modelo de clasificación de colores.

El segundo modelo clasificador, encargado de distinguir siluetas, fue generado de manera similar,
dando como resultado las reglas de clasificación que se muestran en la Figura 4.41.

Figura 4.41. Modelo de clasificación de figuras en base a color.

4.7.6. Cálculo de la precisión del clasificador (validación del modelo matemático)

La última etapa en el proceso de creación de los modelos clasificadores es la validación de los

mismos. Para eso, cada clasificador debe someterse a un nuevo conjunto de muestras, llamado
conjunto de validación.

Es de vital importancia que las muestras (en este caso, imágenes con objetos en escena) del
conjunto de validación no formen parte del conjunto de entrenamiento, ya que en ese caso se estaría
intentando probar el modelo de clasificación con una muestra para la que ya fue entrenado.
Lo anterior puede guiar a estimaciones de precisiones erróneas y demasiado optimistas.

86
Para cumplir con lo anterior, se tomó un total de 35 pruebas (siete para cada clase de figura) y 90
pruebas adicionales (uniformemente distribuidas en las cinco clases de figuras y los cinco colores
disponibles) para validar los clasificadores que detectan en base a distancia y color respectivamente.

Los resultados de las pruebas al clasificador de figuras que trabaja con detección en base a
distancia, pueden apreciarse en la Tabla 4.5. Cada fila de la tabla representa las siete pruebas
realizadas con un tipo de figura en específico, pero dentro de cada fila, los datos se colocan en la
columna correspondiente al resultado que ofrece el clasificador. Estos resultados son inesperados
pero a la vez excelentes, ya que así, el clasificador aparenta ser perfecto. En otras palabras, no se
equivocó ni siquiera una vez.

Tabla 4.5. Matriz de confusión del clasificador por distancia.

Matriz de confusión - Clasificador Formas

Rectángulo Cruz Triángulo Botella Peluche
Rectángulo 7 0 0 0 0
Cruz 0 7 0 0 0
Triangulo 0 0 7 0 0
Botella 0 0 0 7 0
Peluche 0 0 0 0 7

Los resultados de las pruebas al clasificador de figuras que trabaja con detección en base a colores,
pueden apreciarse en la Tabla 4.6. En la primera fila pueden contabilizarse las 18 pruebas realizadas
a la figura Cuadro grande, pero 3 de ellas están en la columna de la figura Cuadro pequeño
mientras que todas las demás están en la columna correcta, es decir, la del Cuadro grande.
Esto significa que en tres de las 18 ocasiones que se le presentó un Cuadro grande al clasificador,
éste arrojó una respuesta errónea, específicamente confundió la figura con un Cuadro pequeño.

Tabla 4.6. Matriz de confusión del clasificador por color.

Matriz de confusión - Clasificador Formas

Cuadro grande Cruz Triángulo Elipse Cuadro pequeño
Cuadro grande 15 0 0 0 3
Cruz 0 18 0 0 0
Triangulo 0 0 18 0 0
Elipse 0 0 0 18 0
Cuadro pequeño 0 0 0 1 17

87
Además se puede apreciar un fallo que tuvo el clasificador a la hora de enfrentarse a figuras de tipo
Cuadro pequeño, ya que predijo erróneamente que se trataba de una elipse.

Para el caso del modelo clasificador de colores, las pruebas se pueden dividir en dos tipos:
reconocimiento del color del fondo de la escena (Figura 4.42a) y reconocimiento del color de la
figura (Figura 4.42b). De manera análoga al clasificador de figuras, se realizaron noventa pruebas
distribuidas en dieciocho para cada color.

Figura 4.42. a) Región denominada marco o fondo de la escena,

b) figura que corresponde a la silueta de un Cuadro grande.

La Tabla 4.7 muestra los resultados de las pruebas de clasificación de colores correspondientes al
marco de la figura. Estos resultados son inesperados pero a la vez excelentes, ya que así, el
clasificador aparenta ser perfecto. En otras palabras, no se equivocó ni siquiera una vez.

Tabla 4.7. Matriz de confusión del clasificador de colores aplicado a los marcos.

Matriz de confusión - Clasificador Colores Marco

Rojo Verde Azul Blanco Negro
Rojo 18 0 0 0 0
Verde 0 18 0 0 0
Azul 0 0 18 0 0
Blanco 0 0 0 18 0
Negro 0 0 0 0 18

Para el caso de la clasificación de colores correspondientes a la figura puesta en escena, los

resultados se encuentran plasmados en la Tabla 4.8. Nuevamente el clasificador aparenta ser

88
perfecto, hecho que se visualiza en la matriz de confusión ya que todos los valores están colocados
en las casillas que forman la diagonal principal.

Tabla 4.8. Matriz de confusión del clasificador de colores aplicado a las figuras.

Matriz de confusión - Clasificador Colores Figuras

Rojo Verde Azul Blanco Negro
Rojo 18 0 0 0 0
Verde 0 18 0 0 0
Azul 0 0 18 0 0
Blanco 0 0 0 18 0
Negro 0 0 0 0 18

Finalmente, la precisión del modelo clasificador de color aparenta ser del 100%, mientras que para
el caso del modelo clasificador de figuras, su cálculo debe estimarse para cada clase, estos cálculos
se realizan en la Tabla 4.9.

Tabla 4.9. Precisión de cada clase del clasificador de figuras por distancia.

Clase Aciertos Fallos Total Precisión

Cuadro grande 15 3 18 83%
Cruz 18 0 18 100%
Triangulo 18 0 18 100%
Elipse 18 0 18 100%
Cuadro pequeño 17 1 18 94%

En base a los datos anteriores, se concluye que ambos modelos son aceptables y generan
predicciones acertadas.

89
90
 CAPÍTULO 5. PRUEBAS Y DEPURACIÓN

La realización de pruebas es una etapa indispensable de todo sistema, ya que durante ellas se
observa el funcionamiento de éste en circunstancias reales. En otras palabras, durante el diseño e
implementación de los sistemas, éstos son probados una infinidad de veces pero, la mayoría de estas
pruebas se dan en ambientes controlados, semejantes a circunstancias ideales.

Dichos escenarios ideales raramente suceden en la vida real, razón que otorga mucha importancia a
las pruebas que se detallan a continuación. Pero antes de ello, se ha definido un formato que permite
documentar toda la información relacionada a cada una de las pruebas. En la Tabla 5.1 se presentan
los componentes del formato establecido.

Tabla 5.1. Formato de registro de realización de pruebas.

Prueba #Correlativo Nombre de la prueba

Objetivo Propósito de realización de la prueba
Descripción Conjunto de acciones que deben de ser
realizadas durante la prueba.
Resultado esperado Consecuencia que se prevé obtener
antes de la realización de la prueba
Resultado obtenido Consecuencia real de llevar a cabo la
prueba

5.1 Pruebas de Imitación de movimientos en tiempo real

Las primeras tres pruebas realizadas consisten en corroborar de manera experimental, el rango de
distancia con el que trabaja el sensor Kinect que aparece en su documentación oficial. Para ello se
hicieron varias tomas de datos a diferentes distancias del Kinect. En la Tabla 5.2 se presentan los
experimentos realizados alrededor del límite inferior del rango oficial de trabajo.

A B C

Figura 5.1. Tomas realizadas a: a) 70 cm, b) 80 cm y c) 1 m.

91
 Tabla 5.2. Registro de la primer prueba realizada.

Prueba #01 Imitación de movimientos muy cerca del sensor Kinect

Objetivo Encontrar la distancia mínima hacia el sensor Kinect que
realiza detección de movimiento correctamente.
Descripción Tomando en cuenta que el límite inferior oficial de detección
es 80 cm, se realizaron tomas a 70 cm, 80 cm y 1m de distancia.
Resultado esperado Basados en la documentación oficial y en la experiencia propia,
no se espera que las mediciones a 70 cm y 80 cm funcionen de
manera óptima, mientras que la de 1 m sí debería de hacerlo.
Resultado obtenido La toma realizada a 70 cm (Figura 5.1a) es completamente errónea,
mientras que las realizadas a 80 cm (Figura 5.1b) y 1 m (Figura 5.1c)
presentan alta calidad y precisión.

En la Tabla 5.3 se presentan los experimentos realizados respetando el rango oficial de trabajo.
Este es el caso donde se presentan las circunstancias ideales.

Tabla 5.3. Registro de la segunda prueba realizada.

Prueba #02 Imitación de movimientos en el rango óptimo del sensor Kinect

Objetivo Comprobar que el sensor Kinect realiza correctamente la
detección de movimientos en su distancia ideal de trabajo.
Descripción Tomando en cuenta la comodidad para realizar mediciones
simultáneas con ambos sensores de realidad aumentada.
Para el sensor Kinect, dicha distancia ronda desde un poco
más de 1 m hasta los 2 m. Por lo tanto, las tomas se realizarán
a 1.2 m, 1.5 m, 2 m y 2.5 m del Kinect.
Resultado esperado Basados en la documentación oficial y en la experiencia propia
se espera que todas las tomas sean fieles a la realidad.
Resultado obtenido Todas las tomas mostradas en la Figura 5.2 resultados exitosas.

A B C D

Figura 5.2. Tomas realizadas a: a) 1.2 m, b) 1.5 m, c) 2 m y d) 2.5 m.

92
En la Tabla 5.4 se presentan los experimentos realizados alrededor del límite superior del rango
oficial de trabajo.

Tabla 5.4. Registro de la tercer prueba realizada.

Prueba #03 Imitación de movimientos muy lejos del sensor Kinect

Objetivo Encontrar la distancia máxima hacia el sensor Kinect que
realiza detección de movimiento correctamente.
Descripción Tomando en cuenta que el límite superior oficial de detección
es 4 m, se realizaron tomas a 3.5 m, 3.75 m y 4 m de distancia.
Resultado esperado Basados en la documentación oficial y en la experiencia propia,
no se espera que las mediciones a 3.75 m y 4 m funcionen de
manera óptima, mientras que la de 3.5 m sí debería de hacerlo.
Resultado obtenido La toma realizada a 3.5 m (Figura 5.3a) fue exitosa. Por el contrario,
la realizada a 3.75 m (Figura 5.3b) es completamente errónea y
de manera inesperada, la toma desde 4m (Figura 5.3c)
ni siquiera logra reconocer la silueta humana.

A B C

Figura 5.3. Tomas realizadas a: a) 3.5 m, b) 3.75 m y c) 4 m.

Análogamente, el siguiente trío de pruebas intenta corroborar de manera experimental, el rango de

distancia con que trabaja el Leap Motion que aparece en su documentación oficial. Para ello se
hicieron varias tomas de datos a distintas distancias del sensor. En la Tabla 5.5 se presentan los
experimentos realizados alrededor del límite inferior del rango oficial de trabajo.

93
 Tabla 5.5. Registro de la cuarta prueba realizada

Prueba #04 Imitación de movimientos muy cerca del sensor Leap Motion
Objetivo Encontrar la menor distancia hacia el sensor Leap Motion, que sea cómoda para
usarse junto con el sensor Kinect y que detecte ambas manos de forma correcta.
Descripción Se realizaron tomas a 10 cm y 20 cm de distancia.
Resultado Basados en la documentación oficial y en la experiencia propia, se espera que
esperado ambas mediciones funciones correctamente.
Resultado La toma realizada a 10 cm (Figura 5.4a) resulta ser precisa para detectar una sola
obtenido mano, pero no así para ambas. Por el contrario, la toma realizada a 20 cm (Figura
5.4b) presenta alta calidad y precisión para ambas manos.

A B

Figura 5.4. Tomas para una y ambas manos realizadas a: a) 10 cm, b) 20 cm.

En la Tabla 5.6 se presentan los experimentos realizados respetando el rango oficial de trabajo.
Este es el caso donde se presentan las circunstancias ideales.

Tabla 5.6. Registro de la quinta prueba realizada

Prueba #05 Imitación de movimientos en el rango óptimo del sensor Leap Motion
Objetivo Comprobar que el sensor Leap Motion realiza correctamente la
detección de movimientos en su distancia ideal de trabajo.
Descripción Tomando en cuenta la comodidad para realizar mediciones
simultáneas con ambos sensores de realidad aumentada.
Para el sensor Leap Motion, de forma empírica se maneja
que dicha distancia ronde los 35 cm. Por lo tanto, las tomas se
realizaron a 30 cm y 40 cm del Leap Motion.
Resultado esperado Basados en la documentación oficial y en la experiencia propia
se espera que ambas tomas sean fieles a la realidad.
Resultado obtenido Todas las tomas mostradas en la Figura 5.5 resultados exitosas,
tanto las que detectan una mano como las que detectan ambas.

94
 A B

Figura 5.5. Tomas para una y ambas manos realizadas a: a) 30 cm, b) 40 cm.

En la Tabla 5.7 se presentan los experimentos realizados alrededor del límite superior del rango
oficial de trabajo.

Tabla 5.7. Registro de la sexta prueba realizada

Prueba #06 Imitación de movimientos muy lejos del sensor Leap Motion
Objetivo Encontrar la distancia máxima hacia el sensor Leap Motion
que realiza detección de movimiento correctamente.
Descripción Tomando en cuenta que el límite superior oficial de detección
es 61 cm, se realizaron tomas a 50 cm y 60 cm de distancia
Resultado esperado Basados en la documentación oficial se espera que todas
las tomas sean fieles a la realidad.
Resultado obtenido Las tomas realizadas a 50 cm (Figura 5.6a) fueron exitosas.
Por el contrario, la toma desde 60 cm (Figura 5.6b) no logra
detectar una ni ambas manos. De manera inesperada,
pues contradice la documentación oficial.

A B

Figura 5.6. Tomas para una y ambas manos realizadas a: a) 50 cm, b) 60 cm.

95
Además de experimentar con diferentes distancias, otro caso real al que pueden enfrentarse los
sensores de realidad aumentada utilizados en el sistema es precisamente variaciones de iluminación
del ambiente. Por tal motivo, se realizaron las siguientes dos pruebas, donde se corrobora de manera
experimental el comportamiento de los sensores frente a iluminaciones drásticamente distintas. En
la Tabla 5.8 se presenta el caso de iluminación excesiva.

Tabla 5.8. Registro de la séptima prueba realizada

Prueba #07 Imitación de movimientos con iluminación excesiva

Objetivo Someter a los sensores de realidad aumentada a
condiciones de alta luminosidad con el fin de observar
su comportamiento.
Descripción Conseguir una fuente muy luminosa (en este caso, una
lámpara de 990 lumens) y colocarla a muy poca
distancia de ambos sensores mientras éstos se
encuentren operativos.
Resultado esperado Que las mediciones de las coordenadas de las
articulaciones se vean ligeramente afectadas.
Resultado obtenido No se aprecia efecto alguno debido a la iluminación
excesiva, como puede verse en la Figura 5.7.

Figura 5.7. Iluminación excesiva frente a: a) sensor Kinect y b) sensor Leap Motion.

96
En la Tabla 5.9 se presentan los experimentos realizados con iluminación prácticamente nula. Es
decir, cuando la escena está en completa oscuridad.

Tabla 5.9. Registro de la octava prueba realizada

Prueba #08 Imitación de movimientos con iluminación nula

Objetivo Someter a los sensores de realidad aumentada a
condiciones de nula luminosidad con el fin de observar
su comportamiento.
Descripción Realizar detección de extremidades superiores en
escenas con nula luminosidad o durante la noche.
Resultado esperado Que las mediciones de las coordenadas de las
articulaciones se vean afectadas.
Resultado obtenido No se aprecia efecto alguno causado por la falta de
luminosidad, como puede verse en la Figura 5.8.

A B

Figura 5.8. Sensores operando bajo nula iluminación: a) Kinect, b) Leap Motion.

Para finalizar los experimentos con los sensores de realidad aumentada, se decidió hacer dos
pruebas un tanto peculiares. La primera de ellas (Tabla 5.10) muestra el comportamiento de los
sensores ante superposición de extremidades o manos.

97
 Tabla 5.10. Registro de la novena prueba realizada

Prueba #09 Imitación de movimientos con superposición de

extremidades o manos
Objetivo Verificar si los sensores de realidad aumentada continúan
detectando personas aún si objetos han sido superpuestos.
Descripción Colocar objetos entre los sensores de realidad aumentada
y las extremidades superiores y manos de la persona.
Para el caso del Kinect se usó un tubo PVC, mientras que
para el Leap Motion se utilizaron un lapicero y un plumón.
Resultado esperado Que las mediciones de las coordenadas de las
articulaciones se vean ligeramente afectadas.
Resultado obtenido Tal como se aprecia en la Figura 5.9a, el tubo PVC no
produjo efecto alguno en la detección del sensor Kinect.
Lo mismo sucedió cuando se sostuvo un lapicero (Figura 5.9b).
Caso contrario ocurre cuando se sostiene dos objetos con la
misma mano, entonces el sensor Leap Motion no es capaz de
funcionar apropiadamente, como muestra la Figura 5.9c.

A C

Figura 5.9. Superposición de objetos: a) tubo PVC situado entre persona y Kinect,
b) mano sosteniendo un lapicero y c) mano sosteniendo un lapicero y un plumón.

En la Tabla 5.11 se presenta el último experimento relacionado con sensores de realidad aumentada.
La presencia de espejos y la detección de las extremidades superiores y manos mediante el reflejo
que éstos proyectan, podrían dar pie a alguna funcionalidad útil en el futuro.

98
 Tabla 5.11. Registro de la décima prueba realizada

Prueba #10 Imitación de movimientos a través de espejos

Objetivo Intentar detectar extremidades superiores y manos mediante su reflejo en espejos.
Descripción Para el caso del sensor Kinect, es necesario conseguir un espejo del tamaño de una
persona. En cambio, para el Leap Motion bastará reflejar una mano en un espejo
de tamaño normal para intentar replicar dos manos.
Resultado No se espera que los sensores de realidad aumentada logren detectar de manera
esperado correcta las coordenadas de las articulaciones de la persona, debido a que dichos
cálculos se hacen en base a la profundidad gracias a las cámaras infrarrojas que
poseen.
Resultado Como puede apreciarse en la Figura 5.10 ambos sensores fueron capaces de
obtenido detectar de manera aceptable las siluetas de las personas.

A B

Figura 5.10. Siluetas reflejadas en espejos: a) extremidades superiores, b) mano derecha.

5.2 Pruebas de Grabación de secuencias de movimientos

El segundo módulo de la plataforma de escritorio corresponde a la grabación de secuencias de

movimientos y a su posterior almacenamiento en archivos de valores separados por coma. Las
siguientes tres pruebas pretenden observar el comportamiento de dichos archivos ante grabaciones
de distintos intervalos de tiempo. La grabación de un minuto se presenta en la Tabla 5.12.

99
 Tabla 5.12. Registro de la undécima prueba realizada

Prueba #11 Grabación de movimientos durante 1 minuto

Objetivo Grabar secuencias de movimientos durante un minuto consecutivo con el fin de
observar las características de los archivos de valores separados por coma
resultantes.
Descripción Con la ayuda de un cronómetro, grabar simultáneamente movimientos de las
extremidades superiores y de las manos durante un minuto exacto.
Resultado La plataforma de escritorio es capaz de generar dicho archivo de manera exitosa,
esperado veloz y sin ocupar mucho espacio en disco.
Resultado La grabación se dio de manera fluida, veloz y el archivo resultante tiene las
obtenido características que se muestran en la Tabla 5.13.

Tabla 5.13. Características de archivos CSV generados durante las

pruebas al módulo de grabación de secuencias de movimientos.

Duración Tamaño archivo Cantidad registros Registros Kinect Registros Leap Motion
1 min 598 KB 525 234 291
5 min 3.09 MB 2919 1336 1583
10 min 5.26 MB 5313 2288 3025

En la Tabla 5.14 se presenta el caso de que el usuario del sistema desee grabar secuencias de
movimiento durante cinco minutos de manera consecutiva.

Tabla 5.14. Registro de la décimo segunda prueba realizada

Prueba #12 Grabación de movimientos durante 5 minutos

Objetivo Grabar secuencias de movimientos durante
cinco minuto consecutivos con el fin de observar
las características de los archivos de valores
separados por coma resultantes.
Descripción Con la ayuda de un cronómetro, grabar
simultáneamente movimientos de las extremidades
superiores y de las manos durante cinco minutos exactos.
Resultado esperado La plataforma de escritorio es capaz de generar dicho
archivo de manera exitosa, veloz y sin ocupar mucho
espacio en disco.
Resultado obtenido La grabación se dio de manera fluida, veloz y el
archivo resultante tiene las características que se
muestran en la Tabla 5.13.

Finalmente, en la Tabla 5.15 se presenta la situación poco probable de que la persona desee grabar
durante diez minutos consecutivos.

100
 Tabla 5.15. Registro de la décimo tercer prueba realizada

Prueba #13 Grabación de movimientos durante 10 minutos

Objetivo Grabar secuencias de movimientos durante diez minutos
consecutivos con el fin de observar las características de los
archivos de valores separados por coma resultantes.
Descripción Con la ayuda de un cronómetro, grabar simultáneamente
movimientos de las extremidades superiores y de las manos
durante diez minutos exactos.
Resultado esperado La plataforma de escritorio es capaz de generar dicho archivo de
manera exitosa, veloz y sin ocupar mucho espacio en disco.
Resultado obtenido La grabación fue exitosa, pero se tardó aproximadamente veinte
segundos en almacenar todos los datos en el archivo resultante.
Dicho archivo tiene las características que se muestran en la
Tabla 5.13.

5.3 Pruebas de Reconocimiento de objetos

Para terminar las pruebas realizadas al sistema, es necesario realizar experimentos con el módulo
correspondiente al reconocimiento de objetos. Cabe mencionar que se realizaron 90 pruebas en
circunstancias ideales, dichas pruebas se encuentran documentadas con amplio detalle en el literal 6
del apartado 4.4.7.

Las siguientes dos pruebas corroboran de manera experimental la clasificación de figuras y colores
frente a iluminaciones drásticamente distintas. En la Tabla 5.16 se presenta el caso de iluminación
excesiva.

Tabla 5.16. Registro de la décimo cuarta prueba realizada

Prueba #14 Reconocimiento de objetos con iluminación excesiva

Objetivo Someter al modelo clasificador que reconoce en base
a colores a condiciones de alta luminosidad con el
fin de observar su comportamiento.
Descripción Conseguir una fuente muy luminosa (en este caso,
una lámpara de 990 lumens) y colocarla a corta
distancia de la escena donde se encuentran las
figuras al momento de tomar la fotografía que servirá
para clasificar sus colores y siluetas.
Resultado esperado No se espera que el clasificador de colores
funcione apropiadamente. Por el contrario, el clasificador
de figuras debería funcionar bien debido al algoritmo de
umbralización personalizada.
Resultado obtenido Ambos clasificadores (tanto de siluetas como de colores
de marco y de figura) funcionaron a la perfección para los
seis casos que se muestran en la Figura 5.11.

101
 Figura 5.11. Fotografías tomadas con excesiva iluminación.

En la Tabla 5.17 se presentan los experimentos realizados con iluminación prácticamente nula. Es
decir, cuando la escena está en casi completa oscuridad.

Tabla 5.17. Registro de la décimo quinta prueba realizada

Prueba #15 Reconocimiento de objetos con iluminación casi nula

Objetivo Someter al modelo clasificador que reconoce en base a colores a
condiciones de luminosidad casi nulas con el fin de observar su
comportamiento.
Descripción Realizar reconocimiento de objetos en escenas con casi nula luminosidad o
durante la noche.
Resultado esperado No se espera que el clasificador de colores funcione apropiadamente. Por
el contrario, el clasificador de figuras debería funcionar bien debido al
algoritmo de umbralización personalizada.
Resultado obtenido Para las seis fotografías que se muestran en la Figura 5.12 el clasificador
de colores falla en el 91.67% de los casos, logrando únicamente una
clasificación correcta (el color verde de la elipse). Por el contrario, el
clasificador de siluetas hace su trabajo de manera impecable, logrando una
inesperada tasa de 100% de precisión.

102
 Figura 5.12. Fotografías tomadas con iluminación casi nula.

Las siguientes dos pruebas se relacionan con la ausencia de figuras a reconocer. En la Tabla 5.18 se
presentan los resultados de intentar clasificar figuras inexistentes.

Tabla 5.18. Registro de la décimo sexta prueba realizada

Prueba #16 Reconocimiento de objetos con ninguna figura en escena

Objetivo Intentar clasificar una escena en la que no se encuentren
figuras, con el fin de observar el comportamiento del
modelo clasificador.
Descripción Se realiza un proceso de reconocimiento pero sin colocar
figuras en la escena (Figura 5.13).
Resultado esperado Se espera que el clasificador de colores funcione
apropiadamente. Además el clasificador de siluetas devuelve
Ninguna para cada fotografía vacía que se le entregue.
Resultado obtenido Tanto para los colores del marco, como los del objeto (el
modelo siempre asume que hay una figura en el centro) la
clasificación fue exitosa. Por el contrario, la clasificación de
figuras en el 66% de los casos el clasificador devolvió
Ninguna y en el 33% restante se devolvió Cruz. Lo anterior
es causado por binarizaciones aleatorias que se
originan debido a umbrales calculados para diferenciar
dos colores que se encuentran muy cercanos (originados
por pequeños cambios de luz imperceptibles al ojo humano).
Este proceso se ilustra en la Figura 5.14.

103
 Figura 5.13. Fotografías tomadas con ninguna figura en escena.

Figura 5.14. a) Imagen homogénea, b) imagen binarizada y c) silueta aleatoria encontrada.

En la Tabla 5.19 se muestra el comportamiento del clasificador de figuras cuando se intenta

reconocer figuras que tienen el mismo color del fondo. Si bien este escenario no debería ocurrir en
la práctica, es interesante ver cómo reacciona el algoritmo.

Tabla 5.19. Registro de la décimo séptima prueba realizada

Prueba #17 Reconocimiento de figuras cuyo color es el mismo que el de la escena

Objetivo Intentar clasificar una fotografía que contiene objetos del mismo
color que la escena, con el fin de observar el comportamiento del
modelo clasificador.
Descripción Se colocan objetos sobre la escena, teniendo el cuidado de que ambos
tengan el mismo color (Figura 5.15).
Resultado esperado Se espera que el clasificador de colores funcione
apropiadamente. Además el clasificador de siluetas devuelve
Ninguna para cada fotografía que se le entregue.
Resultado obtenido El resultado es muy similar al devuelto por la prueba #16.
Las clasificaciones tanto de los colores del marco, como los del objeto
fueron exitosas. Por el contrario, la clasificación de figuras sólo
acertó el 33% de los casos. La razón de este fenómeno se ilustra en
la Figura 5.14.

104
 Figura 5.15. Fotografías con figuras del mismo color de la escena.

La última prueba realizada se refiere al clasificador de figuras que detecta en base a distancia.
Cabe mencionar que se realizaron 35 pruebas en circunstancias ideales, dichas pruebas se
encuentran documentadas con amplio detalle en el literal 6 del apartado 4.4.7.

A continuación se corrobora de manera experimental la clasificación de figuras en base a distancia

frente a iluminaciones drásticamente distintas.

Tabla 5.20. Registro de la décimo octava prueba realizada

Prueba #18 Reconocimiento de figuras en base a distancia en escenas

con iluminación prácticamente nula
Objetivo Someter al modelo clasificador que reconoce en base a distancia
a condiciones de luminosidad casi nulas con el fin de observar
su comportamiento.
Descripción Realizar reconocimiento de objetos en escenas con nula
luminosidad o durante la noche (Figura 5.16).
Resultado esperado Basado en la experiencia propia, se espera que el proceso de
clasificación no se vea afectado.
Resultado obtenido El clasificador de siluetas hace su trabajo de manera impecable,
logrando una tasa de precisión del 100%.

Figura 5.16. Fotografías tomadas con iluminación casi nula.

105
106
 CAPÍTULO 6. CONCLUSIONES Y RECOMENDACIONES

6.1 Conclusiones

 Los sensores de realidad aumentada proveen mediciones con un alto grado de precisión, por lo
que se pueden realizar cálculos con mayor cantidad de cifras significativas, tanto en la
plataforma de escritorio como en el software de cada placa Arduino.

 Mediante la utilización de cinco cifras decimales en el cálculo de los ángulos de las manos y dos
cifras en el caso de los brazos se utiliza el 100% de la precisión de ambos tipos de servomotores.
Mientras que anteriormente se utilizaban el 90% y el 9.7% de la precisión de los brazos y manos
respectivamente.

 El tiempo de retraso desde que el usuario realiza una acción hasta que esta se visualiza en el
tablero indicador es de 109.5 ms aproximadamente.

 La creación de archivos de valores separados por coma permite almacenar en disco duro gran
cantidad de coordenadas y ángulos de las extremidades superiores de la persona. Esta
información tiene un inmenso potencial en futuras aplicaciones, como por ejemplo: corrección
de la postura, traducción de lenguaje de señas, terapias de recuperación de la motricidad fina y
gruesa de gente que ha sufrido accidentes, entre otros.

 La imitación en tiempo real de secuencias de movimientos tanto para brazos como para manos,
se realiza de manera exitosa. Cumpliéndose para ambas extremidades superiores.

 La detección y el reconocimiento de figuras tanto en base al color como a la distancia, funciona

correctamente en la mayoría de los casos. El margen de error es lo suficientemente pequeño
como para afirmar la fiabilidad del módulo de clasificación de objetos.

 El algoritmo de umbralización personalizada es robusto frente a una amplia gama de variaciones

de iluminación.

 Se demostró que es posible integrar tecnologías distintas entre sí para cumplir un único fin,
y lograr que trabajen en conjunto de manera ordenada. Referente a hardware, dos sensores de
realidad aumentada y un tablero indicador implementado usando Arduino. Y respecto a

107
 software, una plataforma de escritorio desarrollada en dos lenguajes de programación diferentes
(C# y C++) donde se implementan modelos de minería de datos y visión por computadora.

 La sustitución del guante de control por el sensor Leap Motion presenta una serie de ventajas,
que incluyen mayor precisión en la toma de datos y rango de movimientos detectados; así como
menor precio e incomodidad para el usuario a la hora de interactuar con él. De esta forma,
se logró reducir el precio a un tercio del original (si tuvieran que construirse dos guantes).

 Mediante la implementación de un software completamente nuevo, se logra sacar más provecho

a las características del brazo inclusive utilizando el mismo hardware.

6.2 Recomendaciones

 Ante la necesidad de realizar tareas que requieren de mayor precisión o de un mayor rango de
interacción que el ofrecido por la actual plataforma de escritorio, se recomienda realizar pruebas
con el SDK Orion del sensor Leap Motion.

 Para que la detección de los movimientos de las extremidades superiores se realice con mayor
precisión y que los datos obtenidos sean más confiables, se deben estudiar las ventajas que la
implementación de un sensor Kinect for Windows Versión 2 podría aportar al sistema.

 Para la realización de tareas de clasificación de objetos más complejas, se recomienda el uso de

algoritmos matemáticos más robustos, por ejemplo, las máquinas de soporte vectorial, que es
una herramienta de minería de datos que se puede implementar directamente desde la librería
OpenCV.

 La implementación de métodos numéricos o de redes de neuronas artificiales permitiría suavizar

las secuencias de movimientos capturadas por los sensores, evitando así ordenarle al brazo que
realice movimientos bruscos que podrían dañarlo.

 Debido a la estructura centralizada de la nueva plataforma de escritorio, Se abre la posibilidad de

que en el futuro se diseñe un lenguaje de programación (con su respectivo compilador) capaz de
operar el brazo robótico de forma completamente automática. Dicho lenguaje podría ser
orientado a la realización de tareas de alta complejidad que requieren de mucha precisión, por
ejemplo, la automatización de procesos en la industria. Por el contrario, el lenguaje podría ser
diseñado de tal forma que sea muy sencillo de utilizar y esté orientado a tareas pedagógicas.

108
 Se recomienda la construcción de un segundo brazo robot que corresponda a la extremidad
superior izquierda, para poder utilizar todos los datos que provee la plataforma de escritorio
desarrollada en este proyecto.

 Se considera al algoritmo de umbralización personalizada como un aporte valioso a ser tomado

en cuenta en futuras aplicaciones de visión por computadora que realice el DEI.

 Se recomienda al Departamento de Electrónica e Informática de la UCA que para futuros

proyectos se brinde acceso al equipo disponible para una mejor implementación

 Se recomienda añadir a los clasificadores de objetos, la capacidad de detectar la ausencia de

figuras. Esto puede lograrse añadiendo una clase que represente Ningún objeto al conjunto de
entrenamiento. Para el caso del clasificador en base a la distancia, otra forma sería calcular una
cota mínima de pixeles que identifique escenarios donde no se encuentren objetos presentes.
Finalmente, en el caso del clasificador de colores, se podría añadir una cláusula que indique que
no hay figuras al detectar colores muy parecidos entre el marco y el centro.

109
110
 GLOSARIO

Baudio: en telecomunicaciones, es una unidad que mide la velocidad de transmisión de la

información sobre un canal de datos. Se expresa en símbolos por segundo.

Bifurcación: elaboración de un software a partir de un código fuente existente. El nuevo proyecto

posee un desarrollo independiente del original. Se le conoce también a través del término en inglés
fork.

Clase (programación): abstracción de un ente del mundo real. Contiene una serie de características
y tareas, conocidas como atributos y métodos respectivamente. Define una plantilla que permite la
creación de otros elementos conocidos como objetos.

Clase (clustering): grupo de muestras que poseen características similares dentro de una serie de
datos.
D

Demonio: en los sistemas operativos Unix, es un proceso informático que se ejecuta en segundo
plano y de manera indefinida. Se encarga de realizar tareas específicas de forma periódica o como
respuesta a ciertos eventos del sistema. No posee interacción directa con el usuario.

Led: dispositivo emisor de luz, frecuentemente utilizado para comprobar el funcionamiento de los
circuitos.

Microcontrolador: circuito integrado programable que posee una memoria donde almacena una
serie de instrucciones que controla el funcionamiento de una tarea específica.

Objeto (programación): instancia de una clase. Representa una entidad en particular del mundo real.

Open-source: modelo de distribución de software y hardware que permite el libre acceso al código
fuente de ciertos programas, de forma que estos puedan ser modificados sin las restricciones que
impone una licencia. Se le conoce también como código abierto.

111
 P

Píxel: unidad mínima que compone una imagen digital que es representada mediante una matriz
bidimensional. Contiene información sobre el brillo y color de una escena.

Radián: en trigonometría, consiste en una unidad de ángulo plano que pertenece al sistema
internacional de unidades. Equivale a un ángulo con un arco que posee la misma longitud que el
radio de una circunferencia.

112
 REFERENCIAS

AUKSTAKALNIS, S. (2017). Practical Augmented Reality: a Guide to the Technologies,

Applications and human factors for AR and VR. Estados Unidos: Pearson.

CAMPOS, W. O. (s.f.). Método de las K-medias en Minería de Datos. Curso de métodos

exploratorios y predictivos en minería de datos. Universidad Centroamericana “José Simeón
Cañas”, Antiguo Cuscatlán, La Libertad.

CATUHE, D. (2012). Programming with the Kinect for Windows Software Developtment Kit.
Redmond: Microsoft Press.

DA SILVA, M., TEIXEIRA, N., DA FONSECA, R. y FREIRE, S. (2016). Mão robótica. Escola
Senai “Roberto Simonsen”, São Paulo, Brasil.

DAWSON-HOWE, K. (2014). A practical introduction to computer vision with OpenCV.

Chichester: Wiley.

FLAMENCO, F., MARROQUÍN, R., PORTILLO, J. y RIVAS, G. (2017). Brazo robot controlado
por gestos (Tesis de pregrado). UCA, Antiguo Cuscatlán, El Salvador.

HAN, J. & KAMBER, M. (2006). Data Mining: Concepts and Techniques. San Francisco: Morgan
Kaufmann.

ISASI, P. y GALVÁN, I. (2004). Redes de Neuronas Artificiales. Un enfoque práctico. Madrid:

Pearson.

JANA, A. (2012). Kinect for Windows SDK Programming Guide. Birmingham: Packt Publishing.

KLETTE, R. (2014). Concise Computer Vision: An Introduction into Theory and Algorithms.
Londres: Springer.

KURNIAWAN, A. (2017). Arduino Programming with .NET and Sketch. Nueva York: Apress.

113
MCNEIL, S. (2017). Sign language static gesture recognition using leap motion (Tesis de
maestría). Western Carolina University, Estados Unidos.

NIXON, M. y AGUADO, A. (2012). Feature Extraction & Image Processing for Computer Vision.
Reino Unido: Elsevier.

ÖZKAYA, Ö. y YILLIKÇI, G. (2015). Arduino Computer Vision Programming. Birmingham:

Packt.

PALACIOS, E., REMIRO, F., LOPEZ, L. (2009). Microcontrolador PIC16F84. Desarrollo de

proyectos. México D.F: Alfaomega.

RAMOS, E., CASTRO, C. y JAWORSKI, P. (2012). Arduino and Kinect Projects. New York:
Apress.

SCHMALSTIEG, D y HÖLLERER, T. (2016). Augmented Reality: Principles and Practice.

Estados Unidos: Pearson.

SCHMIDT, M. (2011). Arduino: A Quick-Start Guide. Estados Unidos: Pragmatic Programmers.

TANENBAUM, A. S. y WETHERHALL, D. J. (2011). Computer Networks. Boston: Pearson.

WEICHERT, F., BACHMANN, D., BARTHOLOMÄ, R. y FISSELER, D. (2013). Analysis of the

Accuracy and Robustness of the Leap Motion Controller. Sensors (Dortmund), 13, 6380-6393.

WITTEN, I. y FRANK, E. (2005). Data Mining: Practical Machine Learning Tools and
Techniques. San Francisco: Elsevier.

114
 FUENTES ELECTRÓNICAS

ALEGRE, E., PAJARES, G., DE LA ESCALERA, A. (2016). Conceptos y Métodos en Visión por
Computador. Recuperado de https://intranet.ceautomatica.es/sites/default/files/upload/8/files/
ConceptosyMetodosenVxC.pdf (Consulta 20/06/2018).

ARDUINO. (2018a). Introduction. Recuperado de https://www.arduino.cc/en/Guide/Introduction

(Consulta: 27/05/2018).

ARDUINO. (2018b). Arduino Products. Recuperado de https://www.arduino.cc/en/Main/Products

(Consulta: 29/05/2018).

ARDUINO. (2018c). Frequently Asked Questions. Recuperado de https://www.arduino.cc/en/

Main/FAQ (Consulta: 29/05/2018).

ARDUINO. (2018d). Read(). Recuperado de https://www.arduino.cc/en/Serial/Read

(Consulta: 27/05/2018).

ARDUINO. (2018e). Serial. Recuperado de https://www.arduino.cc/reference/en/language/

functions/communication/serial/ (Consulta: 28/05/2018).

ARDUINO (2018f). ServoAttach. Recuperado de https://www.arduino.cc/en/Reference/

ServoAttach (Consulta 08/09/2018).

AZUMA, R. T. (1997). A Survey of Augmented Reality. Recuperado del sitio de Internet de

University of North Carolina at Chapel Hill: https://www.cs.unc.edu/~azuma/ARpresence.pdf
(Consulta: 27/06/2018).

BRABANDER, F. (2015). LiquidCrystal I2C. Recuperado de https://www.arduinolibraries.info/

libraries/liquid-crystal-i2-c (Consulta: 25/04/2018).

BREÑA, A., y JACOBO, M. (2006). Principios y fundamentos de la Hidrología superficial.

Recuperado de http://www.uamenlinea.uam.mx/materiales/licenciatura/hidrologia/
principios_fundamentos/libro-PFHS-05.pdf (Consulta: 23/05/2018).

115
COLGAN, A. (25 de abril de 2013). How Does the Leap Motion Controller Work? [Mensaje en un
blog]. Recuperado de http://blog.leapmotion.com/hardware-to-software-how-does-the-leap-motion-
controller-work/ (Consulta: 20/04/2018).

DELTAKOSH. (2011). Unleash the power of Kinect for Windows SDK! Recuperado de
https://www.eternalcoding.com/?p=1663 (Consulta: 10/05/2018).

EDWIN. (10 de julio de 2018). Troubleshooting Guide. Recuperado de

https://support.leapmotion.com/hc/en-us/articles/223782688-Troubleshooting-Guide
(Consulta 01/08/2018)

FELTHAM, J. (17 de febrero de 2016). Leap Motion Announces Orion For Faster, More Accurate
VR Hand Tracking. VR Focus. Recuperado de https://www.vrfocus.com/2016/02/leap-motion-
announces-orion-for-faster-more-accurate-vr-hand-tracking/ (Consulta: 24/06/2018).

GRAGLIA, D. (11 de julio de 2016). Niantic: la empresa que sacó los Pokémon a las calles y a
millones de jugadores detrás. Univision Noticias.
Recuperado de https://www.univision.com/noticias/desde-silicon-valley/niantic-la-empresa-que-
saco-los-pokemon-a-las-calles-y-a-millones-de-jugadores-detras (Consulta: 29/06/2018).

HIDALGO, V. (7 de julio de 2018). Comprometidos con el cuido del medioambiente. Recuperado

de http://uca.edu.sv/noticias/texto-5492 (Consulta: 31/07/2018).

HOLLISTER, S. (12 de enero de 2012). PlayStation Vita plays augmented reality soccer (hands-on
video). The Verge. Recuperado de https://www.theverge.com/2012/1/12/2701266/playstation-vita-
plays-augmented-reality-soccer-hands-on-video (Consulta: 29/06/2018).

HUANG,T. (1996). Computer Vision: Evolution And Promise. Recuperado de https://cds.cern.ch/

record/400313/files/p21.pdf (Consulta: 28/06/2018).

KINECT FOR WINDOWS TEAM (2012a). Starting February 1, 2012: Use the Power of Kinect
for Windows to Change the World. Recuperado de https://blogs.msdn.microsoft.com/
kinectforwindows/2012/01/09/starting-february-1-2012-use-the-power-of-kinect-for-windows-to-
change-the-world/ (Consulta: 20/05/2018).

116
KINECT FOR WINDOWS TEAM. (2012b). Near Mode: What it is (and isn’t). Recuperado de
https://blogs.msdn.microsoft.com/kinectforwindows/2012/01/20/near-mode-what-it-is-and-isnt/
(Consulta: 22/05/2018).

KINECT FOR WINDOWS TEAM. (2014). The Kinect for Windows v2 sensor and free SDK 2.0
public preview are here. Recuperado de https://blogs.msdn.microsoft.com/kinectforwindows/
2014/07/15/the-kinect-for-windows-v2-sensor-and-free-sdk-2-0-public-preview-are-here/
(Consulta: 22/05/2018).

LEAP MOTION INC. (2013). Leap Motion Launches World's Most Accurate 3-D Motion Control
Technology for Computing. Recuperado de https://www.leapmotion.com/news/leap-motion-
launches-worlds-most-accurate-3-d-motion-control-technology-for-computing
(Consulta: 14/05/2018).

LEAP MOTION INC. (2017). Get Started with Our SDK. Recuperado de
https://developer.leapmotion.com/get-started (Consulta: 24/06/2018).

LEAP MOTION INC. (Sin fecha A). System Architecture. Recuperado de https://developer-
archive.leapmotion.com/documentation/v2/csharp/devguide/Leap_Architecture.html
(Consulta: 15/05/2018).

LEAP MOTION INC. (Sin fecha B). Leap Motion SDK and Plugin Documentation. Recuperado de
https://developer-archive.leapmotion.com/documentation/index.html (Consulta: 15/05/2018).

LEAP MOTION INC. (Sin fecha C). API Overview. Recuperado de https://developer-
archive.leapmotion.com/documentation/v2/csharp/devguide/Leap_Overview.html
(Consulta: 25/05/2018).

LEAP MOTION INC. (Sin fecha D). Camera Images. Recuperado de https://developer-
archive.leapmotion.com/documentation/v2/csharp/devguide/Leap_Images.html
(Consulta: 24/06/2018).

LEAP MOTION INC. (Sin fecha E). Image. Recuperado de https://developer-

archive.leapmotion.com/documentation/v2/csharp/api/Leap.Image.html (Consulta: 27/06/2018).

117
LEAP MOTION INC. (Sin fecha F). Vector. Recuperado de https://developer-
archive.leapmotion.com/documentation/v2/csharp/api/Leap.Vector.html#csharpclass_leap_1_1_vec
tor (Consulta: 30/06/2018).

LEAP MOTION INC. (Sin fecha G). Tool. Recuperado de https://developer-

archive.leapmotion.com/documentation/v2/csharp/api/Leap.Tool.html (Consulta: 25/06/2018).

LEAP MOTION INC. (Sin fecha H). Gesture. Recuperado de https://developer-

archive.leapmotion.com/documentation/v2/csharp/devguide/Leap_Gestures.html
(Consulta: 27/06/2018).

MICROSOFT. (2013). Kinect for Windows SDK v1.8. Recuperado de: https://www.microsoft.com/
en-us/download/details.aspx?id=40278 (Consulta 30/05/2018).

MILLER, P. (17 de septiembre de 2017). The iPhone X’s notch is basically a Kinect. The Verge.
Recuperado de https://www.theverge.com/circuitbreaker/2017/9/17/16315510/iphone-x-notch-
kinect-apple-primesense-microsoft (Consulta: 7/06/2018).

NINTENDO (2018). Tarjetas RA: Mira tus juegos en el mundo. Recuperado de:
https://www.nintendo.com/es_LA/3ds/ar-cards (Consulta: 04/07/2018).

OPENCV TEAM (2018). About. Recuperado de https://opencv.org/about.html

(Consulta: 31/05/2018).

PESCO, D. y BORTOLOSSI, H. (Sin fecha). Matrices and Digital Images. Recuperado del sitio de
Internet de Fluminense Federal University, Institute of Mathematics and Statistics:
http://dmuw.zum.de/images/6/6d/Matrix-en.pdf (Consulta: 20/06/2018).

SPARKFUN ELECTRONICS (s.f). Announced Specification of HS-805BB+ MEGA 1/4 Scale

Servo. Recuperado de https://cdn.sparkfun.com/datasheets/Robotics/hs805.pdf (Consulta
08/09/2018).

118
SZELISKI, R. (2010). Computer Vision: Algorithms and Applications. Recuperado de
http://szeliski.org/Book/drafts/SzeliskiBook_20100903_draft.pdf (Consulta: 19/06/2018).
TOWERPRO (2014). MG946R. Recuperado de http://www.towerpro.com.tw/product/mg946r/
(Consulta 08/09/2018).

UNIVERSIDAD CARLOS III DE MADRID. (2016). Introducción a la visión por computador:

desarrollo de aplicaciones con OpenCV. Recuperado de https://www.edx.org/es/course/
introduccion-la-vision-por-computador-uc3mx-isa-1x-0 (Consulta 20/04/2018).

WRIGHT, J. (Sin fecha). Dispelling Common Bluetooth Misconceptions. Recuperado de

https://www.sans.edu/cyber-research/security-laboratory/article/bluetooth (Consulta: 04/07/2018).

119
ANEXOS
 ANEXO A. Código fuente C++: clasificador en base a distancia

#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include "opencv2/imgproc/imgproc.hpp"
#include <opencv2/ml/ml.hpp>
#include <iostream>
#include <fstream>

using namespace cv;

using namespace std;

struct caracteristicas {
double area, perimetro;
int ancho, alto;
};

int main() {
string ruta = "imagenKinect.jpg";
cout << "Analizando imagen: " << ruta << endl;
Mat imagenOriginal = imread(ruta);

//Se almacenaran las carac. de 3 objetos (izquierda, centro y derecha)

struct caracteristicas arreglo[3];
for (int i = 0; i < 3; i++) {
arreglo[i].area = 0;
arreglo[i].perimetro = 0;
arreglo[i].ancho = 0;
arreglo[i].alto = 0;
}

for (int i = 0; i < 3; i++) {

cout << "Procesando objeto [" << i << "]" << endl;
Mat seccionColor;
Mat r(imagenOriginal, Rect(0 + 220 * i, 150, 200, 200));
r.copyTo(seccionColor);

//Separar la imagen en los 3 canales de color: 0(blue) 1(green) 2(red)

Mat seccionCanales[3];
split(seccionColor, seccionCanales);

//Aplicar umbralizacion (threshold) al canal verde: 1(green)

threshold(seccionCanales[1], seccionColor, 128, 255, CV_THRESH_BINARY);

//Calcular contornos a la imagen umbralizada (ahora ya es binaria)

vector<vector<Point> > contours;
Mat contourOutput = seccionColor.clone();
findContours(contourOutput, contours, CV_RETR_LIST,
CV_CHAIN_APPROX_NONE);

A-1
 //Revisar cada figura (contorno) detectada
for (size_t idx = 0; idx < contours.size(); idx++) {
double area = contourArea(contours[idx], false);

//Sólo aquellas cuya área no sea muy pequeña ni muy grande

if (area > 1000 && area < 20000) {
cout << "Objeto encontrado, obteniendo carac..." << endl;
arreglo[i].area = area;
arreglo[i].perimetro = arcLength(contours[idx], 1);

Rect caja = boundingRect(contours[idx]);

arreglo[i].ancho = caja.width;
arreglo[i].alto = caja.height;
}
}
}

//Almacenar resultados en archivo

cout << "Almacenando resultados en archivo..." << endl;
ofstream o_archivo;
o_archivo.open("resultadosCaracterizacion.csv");
for (int i = 0; i < 3; i++) {
o_archivo << arreglo[i].area << "," << arreglo[i].perimetro << ",";
o_archivo << arreglo[i].ancho << "," << arreglo[i].alto << endl;
}
o_archivo.close();

cout << "Proceso terminado." << endl;

return 0;
}

A-2
 ANEXO B. Código fuente C++: clasificador en base a colores

#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include "opencv2/imgproc/imgproc.hpp"
#include <opencv2/ml/ml.hpp>
#include <iostream>
#include <fstream>
#include <cmath>

using namespace cv;

using namespace std;

struct dupla {
int indice, magnitud;
//indice: 0(B), 1(G), 2(R), 3(Gray)
//magnitud: promedio || umbral
};

struct caracteristicas {
int colorM, colorC;
//0(negro) 1(blanco) 2(Red) 3(Green) 4(Blue)
int AreaCHull_Area, AreaTMin_Area;
double AreaElipse_Area;
};

struct caracteristicas arreglo[3];

struct dupla calcularUmbral(Mat unaImagen, int iSeccion) {

//i: 0(B), 1(G), 2(R), 3(Gray)
int acumuladorMarco[4], acumuladorCentro[4], promedioMarco[4],
promedioCentro[4];
for (int i = 0; i < 4; i++) {
acumuladorMarco[i] = 0;
acumuladorCentro[i] = 0;
promedioMarco[i] = 0;
promedioCentro[i] = 0;
}

//-------------- Calcular acumuladores de colores --------------------

int cn = unaImagen.channels();//3 canales
//Borde superior
uint8_t* rowPtr = unaImagen.row(2).data;
for (int j = 2; j < 198; j++) {
acumuladorMarco[0] += rowPtr[j*cn + 0]; // B
acumuladorMarco[1] += rowPtr[j*cn + 1]; // G
acumuladorMarco[2] += rowPtr[j*cn + 2]; // R
}
//Borde inferior
rowPtr = unaImagen.row(198).data;
for (int j = 2; j < 198; j++) {
acumuladorMarco[0] += rowPtr[j*cn + 0]; // B
acumuladorMarco[1] += rowPtr[j*cn + 1]; // G
acumuladorMarco[2] += rowPtr[j*cn + 2]; // R
}

B-1
 //Centro
for (int i = 96; i < 104; i++) {
rowPtr = unaImagen.row(i).data;
for (int j = 96; j < 104; j++) {
acumuladorCentro[0] += rowPtr[j*cn + 0]; // B
acumuladorCentro[1] += rowPtr[j*cn + 1]; // G
acumuladorCentro[2] += rowPtr[j*cn + 2]; // R
}
}

//-------------- Convertir a escala de grises --------------------

cvtColor(unaImagen, unaImagen, CV_BGR2GRAY);

//----------- Calcular acumuladores de escala de grises -----------

cn = unaImagen.channels();//1 canal
//Borde superior
rowPtr = unaImagen.row(2).data;
for (int j = 2; j < 198; j++)
acumuladorMarco[3] += rowPtr[j*cn + 0]; // gray

//Borde inferior
rowPtr = unaImagen.row(198).data;
for (int j = 2; j < 198; j++)
acumuladorMarco[3] += rowPtr[j*cn + 0]; // gray

//Centro
for (int i = 96; i < 104; i++) {
rowPtr = unaImagen.row(i).data;
for (int j = 96; j < 104; j++)
acumuladorCentro[3] += rowPtr[j*cn + 0]; // gray
}

//--------- Calcular promedios a color y escala de grises -------------

for (int i = 0; i < 4; i++) {
promedioMarco[i] = acumuladorMarco[i] / 392;//392=2*(198-2)=2*(200-4)
promedioCentro[i] = acumuladorCentro[i] / 64;//64=8*8
}//division entera a proposito xD

//-------------- Arbol de decisión - Color Marco --------------

//promedio[]: 0(B), 1(G), 2(R), 3(Gray)
//arrelo.color: 0(negro) 1(blanco) 2(Red) 3(Green) 4(Blue)
if (promedioMarco[0] - promedioMarco[1] <= -31.5)
arreglo[iSeccion].colorM = 3;
else if (promedioMarco[1] - promedioMarco[2] <= -39)
arreglo[iSeccion].colorM = 2;
else if (promedioMarco[2] >= 130.5)
arreglo[iSeccion].colorM = 1;
else if (promedioMarco[0] - promedioMarco[2] >= 30)
arreglo[iSeccion].colorM = 4;
else
arreglo[iSeccion].colorM = 0;
//-------------- Arbol de decisión - Color Centro(figura) --------------
if (promedioCentro[0] - promedioCentro[1] <= -31.5)
arreglo[iSeccion].colorC = 3;
else if (promedioCentro[1] - promedioCentro[2] <= -39)
arreglo[iSeccion].colorC = 2;
else if (promedioCentro[2] >= 130.5)
arreglo[iSeccion].colorC = 1;

B-2
 else if (promedioCentro[0] - promedioCentro[2] >= 30)
arreglo[iSeccion].colorC = 4;
else
arreglo[iSeccion].colorC = 0;

//Calcular diferencias
struct dupla distancias[4];
for (int i = 0; i < 4; i++) {
distancias[i].indice = i;
distancias[i].magnitud = abs(promedioMarco[i] - promedioCentro[i]);
}

//Ordenarlo
for (int x = 1; x < 4; x++)
for (int y = 0; y < 4 - 1; y++)
if (distancias[y].magnitud < distancias[y + 1].magnitud) {
struct dupla temp;
temp.indice = distancias[y].indice;
temp.magnitud = distancias[y].magnitud;

distancias[y].indice = distancias[y + 1].indice;

distancias[y].magnitud = distancias[y + 1].magnitud;

distancias[y + 1].indice = temp.indice;

distancias[y + 1].magnitud = temp.magnitud;
}

//Calcular umbral "optimo" y devolver estructura

struct dupla resultado;
resultado.indice = distancias[0].indice;
resultado.magnitud = (promedioMarco[resultado.indice] +
promedioCentro[resultado.indice]) / 2;
return resultado;
}

int main() {
string ruta = "imagenKinectColores.jpg";
cout << "Analizando imagen: " << ruta << endl;
Mat imagenOriginal = imread(ruta);

//Se almacenaran las carac. de 3 objetos (izquierda, centro y derecha)

for (int i = 0; i < 3; i++) {
arreglo[i].colorM = 0;
arreglo[i].colorC = 0;
arreglo[i].AreaCHull_Area = 0;
arreglo[i].AreaTMin_Area = 0;
arreglo[i].AreaElipse_Area = 0;
}

for (int i = 0; i < 3; i++) {

cout << "Procesando objeto [" << i << "]" << endl;

Mat seccionICD;
Mat r(imagenOriginal, Rect(0 + 220 * i, 180, 200, 200));
r.copyTo(seccionICD);

//Encontrar aproximación a la mejor umbralización

cout << "Calculando umbralizacion optima..." << endl;

B-3
 struct dupla umbral = calcularUmbral(seccionICD, i);
cout << "Umbral[indice] = " << umbral.indice << endl;
cout << "Umbral[magnitud] = " << umbral.magnitud << endl;

//La mejor umbralización se da en un canal de color

if (umbral.indice <= 2) {
//Separar los canales de color
Mat brgSeccionICD[3];
split(seccionICD, brgSeccionICD);//split source
//Umbralizar
threshold(brgSeccionICD[umbral.indice], seccionICD,
umbral.magnitud, 255, CV_THRESH_BINARY);
}
//La mejor umbralización se da en escala de grises
else {
//Convertir imagen a escala de grises
cvtColor(seccionICD, seccionICD, CV_BGR2GRAY);
//Umbralizar
threshold(seccionICD, seccionICD, umbral.magnitud, 255,
CV_THRESH_BINARY);
}

//Encontrar contornos en la imagen ya binarizada

vector<vector<Point> > contours;
Mat contourOutput = seccionICD.clone();
findContours(contourOutput, contours, CV_RETR_LIST,
CV_CHAIN_APPROX_NONE);

for (size_t idx = 0; idx < contours.size(); idx++) {

double area = contourArea (contours[idx], false);

if (area > 850 && area < 20000) {

cout << "Objeto encontrado, obteniendo carac..." << endl;

//Calcular ConvexHull (Envolvente convexa)

vector<Point> hull;
convexHull(contours[idx], hull);
//caracteristicas
double areaCH = contourArea(hull, false);

//Calcular triangulo de area minima

vector<Point> triangulo;
minEnclosingTriangle(contours[idx], triangulo);
//caracteristicas
double areaTmin = contourArea(triangulo, false);

//Calcular Ellipse
RotatedRect elipse = fitEllipse(contours[idx]);
//caracteristicas
double areaElipse = 3.14159*elipse.size.width
*elipse.size.height / 4;

arreglo[i].AreaCHull_Area = areaCH - area;

arreglo[i].AreaTMin_Area = areaTmin - area;
arreglo[i].AreaElipse_Area = areaElipse - area;
}
}
}

B-4
 //Almacenar resultados en archivo
cout << "Almacenando resultados en archivo..." << endl;
ofstream o_archivo;
o_archivo.open("resultadosCaracterizacionColores.csv");
for (int i = 0; i < 3; i++) {
o_archivo << arreglo[i].colorM << "," << arreglo[i].colorC << ",";
o_archivo << arreglo[i].AreaCHull_Area << "," <<
arreglo[i].AreaTMin_Area << ",";
o_archivo << arreglo[i].AreaElipse_Area << endl;
}
o_archivo.close();

cout << "Proceso terminado." << endl;

return 0;
}

B-5
ANEXO C. Código fuente Arduino: control de brazo derecho

C-1
C-2
C-3
ANEXO D. Código fuente Arduino: control de brazo izquierdo

D-1
ANEXO E. Código fuente Arduino: control de mano derecha

E-1
E-2
E-3
E-4
ANEXO F. Código fuente Arduino: control de mano izquierda

F-1
F-2
ANEXO G. Pantallas plataforma de escritorio.

Pestaña de inicio.

Pestaña de conexión.

G-1
 Pestaña de imitación.

Pestaña de grabación.

Pestaña de reproducción.

G-2
Pestaña de reconocimiento de objetos.

Pestaña de configuración.

G-3
 ANEXO H. Diagramas de circuitos del tablero indicador de ledes.

B C
B
BRAZO DERECHO

D
A
A

E
D
A

G
A
F
A

Partes del circuito correspondiente al brazo derecho: a) placa Arduino Mega, b) ledes indicadores
de los ángulos de abertura del brazo, c) ledes indicadores de las posiciones de objetos en módulo de
reconocimiento, d) módulo Bluetooth, e) pantalla LCD, f) interfaz I2C, g) botones para seleccionar
ángulos a visualizar en pantalla LCD.

H-1
 BRAZO IZQUIERDO
A

C
B

Partes del circuito correspondiente al brazo izquierdo: a) placa Arduino UNO,

b) ledes indicadores de los ángulos de abertura del brazo, c) módulo Bluetooth

MANO IZQUIERDA

A B

C
B

Partes del circuito correspondiente a la mano izquierda: a) placa Arduino UNO,

b) ledes indicadores de los ángulos de abertura de cada dedo, c) módulo Bluetooth

H-2
 B
MANO DERECHA
C

Partes del circuito correspondiente al mano derecha: a) placa Arduino Mega, b) ledes indicadores de
los ángulos de abertura de cada dedo, c) módulo Bluetooth, d) pantalla LCD, e) interfaz I2C,
f) botones para seleccionar ángulos a visualizar en pantalla LCD.

H-3