Prototipado de Sistema TPV Controlado Con "Leap Motion"

Prototipado de
un Sistema TPV
controlado con
“Leap Motion”
Grado en Ingeniería en Sonido e Imagen

en Telecomunicación
Trabajo Fin de Grado

Autor:
Patricia Benavente Domenech
Tutor/es:
Adolfo Albaladejo Blázquez
Septiembre 2018
AGRADECIMIENTOS
Durante el desarrollo de este proyecto son varias las personas que, de una forma u otra, han
contribuido a que se me facilitara el trabajo.
- Por parte de Artech, GeneXus: Rodolfo Roballo y Rodrigo Álvarez.
Al primero, por certificarme, por enseñarme la base de un software totalmente

desconocido en España, y ser mi instructor durante un mes allá por abril del 2015.
Además, siempre predispuesto a aportar y ayudar con cualquier consulta, aunque esté a
miles de km.
Al segundo, por facilitarme desinteresadamente una licencia sin coste para poder
desarrollar con su software durante todo el período de creación de la propuesta.
- A Rubén, por transmitirme conocimientos acerca de una versión de GeneXus con la que
yo no estaba familiarizada, y también su ayuda desinteresada con cualquier cuestión que
podía surgir.
- A mi hermana Verónica, que después de un proyecto de fin de carrera, dos proyectos de

fin de máster y una tesis doctoral … Algo controlaba en cuanto al formato de la memoria.
😊
A todos los que de alguna forma se han implicado desinteresadamente en esto, ¡gracias!
Universidad de Alicante – Escuela Politécnica Superior 0
ÍNDICE DE CONTENIDOS
1. INTRODUCCIÓN ................................................................................................... 8
1.1. ¿Qué es un Sistema TPV? ............................................................................. 8
1.1.1. Componentes de un sistema TPV ........................................................... 9
1.2. Nacimiento de la propuesta de TFG ............................................................... 9
1.3. Ideas generales y objetivos del proyecto ...................................................... 10
1.4. Fases del desarrollo del proyecto ................................................................. 10
2. METODOLOGÍA Y TECNOLOGÍAS UTILIZADAS ............................................... 11
2.1. ‘Leap Motion’: el sensor de control gestual ................................................... 11
2.1.1. Partes físicas del dispositivo (hardware) ................................................ 12
2.1.2. Funcionamiento del controlador ............................................................. 15
2.1.3. Resumen de la API del sensor (v3.2.1_win) .......................................... 18
2.1.3.1 Objeto Hand (mano) .......................................................................... 20
2.1.3.2 Objeto Arm (brazo) ............................................................................ 22
2.1.3.3 Objeto Finger (dedo) .......................................................................... 23
2.1.3.4 Objeto Frame ..................................................................................... 25
2.1.3.5 Interfaz de comunicación entre la aplicación y el dispositivo .............. 27
2.1.3.6. Los gestos que interpreta Leap Motion .............................................. 28
2.1.4. Arquitectura del sistema ........................................................................ 29
2.1.4.1 Interfaz nativa .................................................................................... 29
2.1.4.2 Interfaz web (WebSocket) .................................................................. 30
2.2. Lenguajes de programación y herramientas ................................................. 32
2.2.1. GeneXus: el generador de código ......................................................... 32
2.2.1.1 ¿Qué es y para qué sirve GeneXus? ................................................. 32
2.2.1.2 ¿Por qué GeneXus? .......................................................................... 34
2.2.1.3 La base de conocimiento de una aplicación en GeneXus (Knowledge
Base - KB)........................................................................................................ 35
2.2.1.4 Objeto Transacción en GeneXus ....................................................... 36
2.2.1.5 Generando una aplicación con GeneXus ........................................... 38
2.2.2. Microsoft SQL Server (servidor BBDD) .................................................. 41
2.3. Conexión entre GeneXus y un sistema DAQ ................................................ 43
2.3.1. Importación de los objetos de la API de Leap Motion desde GeneXus .. 43
3. EL SISTEMA TPV................................................................................................ 48
3.1. Prototipo de la aplicación original (v.0.1.) ..................................................... 48
3.1.1. El Developer Menu de GX ..................................................................... 48
3.1.2. Inicio ...................................................................................................... 49
3.1.3. Interfaz de usuario: clientes ................................................................... 51
TRABAJO DE FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

1 Sistema TPV controlado con ‘Leap Motion’
3.1.3.1. Menú principal ................................................................................... 51

3.1.3.2. Eventos asociados a los botones del Menú principal ......................... 52
3.1.4. Interfaz de usuario: empleados .............................................................. 57
3.1.4.1 Menú principal ................................................................................... 57
3.1.4.2. Funciones de administrador .............................................................. 58
4. EL SISTEMA TPV CON LEAP MOTION INTEGRADO ........................................ 64
4.1. Primeros pasos con Leap ............................................................................. 64
4.1.1. Ejecutando por primera vez… ‘Hola Mundo’ .......................................... 65
4.1.2. Avanzando un poco más… ‘Hola Mundo’ “casero” ................................ 68
4.1.2.1 Configuración de Visual Studio 2012 para el uso de Leap ................. 69
4.1.2.2 “Implementando que es gerundio” ..................................................... 72
4.1.2.3 Haciendo trabajar al sensor: casos de prueba ................................... 75
4.2. Integración con el TPV ................................................................................. 79
4.2.1. Funcionalidades gestuales requeridas por el TPV ................................. 79
4.2.2. Propuestas de solución para cada funcionalidad gestual planteada y a
implementar sobre el sistema TPV ...................................................................... 80
5. CONCLUSIONES Y FUTURAS MEJORAS ......................................................... 85
6. BIBLIOGRAFÍA Y REFERENCIAS ...................................................................... 86
7. ANEXOS.............................................................................................................. 88
7.1. Ejemplo ‘Hola Mundo’ en C# ........................................................................ 88
7.2. Ejemplo ‘Hola Mundo’ mejorado en C# con VS2012. Caso 1. ...................... 91
7.3. Ejemplo ‘Hola Mundo’ mejorado en C# con VS2012. Caso 2. ...................... 93
7.4. JSON tracking data format............................................................................ 94
TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

ÍNDICE DE FIGURAS
A continuación se presenta un listado de figuras utilizadas en esta memoria.
Figura 1. Caja registradora convencional vs sistema TPV....................................................... 8

Figura 2. Controlador ‘Leap Motion’..................................................................................... 11
Figura 3. Escenificación del funcionamiento del sensor ‘Leap Motion’. .............................. 11
Figura 4. Interior del dispositivo – Esquema distribución cámaras, LEDs. ........................... 12
Figura 5. Placa base del dispositivo Leap Motion 1. Microcontrolador. ............................... 13
Figura 6. Configuración PIN del integrado MX25L3206E.................................................... 13
Figura 7. Placa base del dispositivo Leap Motion 2. Controlador USB. ............................... 14
Figura 8. Placa base del dispositivo Leap Motion 3. Puertos de E/S datos............................ 14
Figura 9. Distorsión compleja o de mostacho. ....................................................................... 15
Figura 10. Imagen recogida por el sensor con el mapa de mallado de puntos superpuesto. .. 16
Figura 11. Imágenes Ii e Id (dispares) cuya fuente son dos cámaras separadas en el eje X. . 16
Figura 12. Diagrama representando los parámetros que intervienen en el cálculo de la
disparidad entre imágenes. ..................................................................................................... 17
Figura 13. Puntos del esqueleto del modelo interno de la mano definida por el controlador
Leap Motion, funcionamiento del cual está basado en el sistema de coordenadas cartesianas.
................................................................................................................................................ 18
Figura 14. Lenguajes permitidos por la API para hacer uso de Leap .................................... 19
Figura 15. Contexto de los objetos que contiene la API ........................................................ 19
Figura 16. Vectores que proporcionan información sobre la orientación de la mano. ........... 20
Figura 17. Constructor de un objeto Hand. ............................................................................ 20
Figura 18. Constructor de un objeto Arm. ............................................................................. 22
Figura 19. Constructor de un objeto Finger. .......................................................................... 23
Figura 20. Vectores que proporcionan información sobre la posición y dirección de un dedo.
................................................................................................................................................ 23
Figura 21. Esquema anatómico de una mano humana. .......................................................... 25
Figura 22. Diagrama que representa la relación con otros objetos del objeto ‘Frame’. ......... 25
Figura 23. Constructor de un objeto Frame. .......................................................................... 26
Figura 24. Región contextual del objeto InteractionBox. ...................................................... 26
Figura 25. Objeto Listener y sus métodos asociados a Controller. ........................................ 27
Figura 26. Tipos de gesto interpretados por Leap Motion. (Fuente: github.com) ................. 28
Figura 27. Aplicaciones habilitadas con Leap a través de la interfaz nativa del dispositivo. 29
Figura 28. Aplicación Panel de Control Leap Motion corriendo en Windows. ..................... 30
Figura 29. Aplicaciones web habilitadas para Leap a través de la interfaz WebSocket. ....... 31

Figura 30. Opción habilitar / inhabilitar a las aplicaciones el acceso al servidor WebSocket.
................................................................................................................................................ 31
Figura 31. Logo GeneXus X Evolution 2. ............................................................................. 32
Figura 32. Definiendo GeneXus 1. ........................................................................................ 33
Figura 33. Lenguajes de programación soportados en función de la plataforma destino. ..... 33
Figura 34. Lenguajes de programación y clientes de BBDD soportados en función de la
plataforma destino. ................................................................................................................. 33
Figura 35. Ejemplo real de definición de transacción GeneXus. Transacción Pedido de
nuestra app TPV. .................................................................................................................... 37
Figura 36. Ejemplo real de definición de transacción GeneXus. Transacción Mesas de
nuestra app TPV. .................................................................................................................... 37
Figura 37. Ejemplo real de Web Form dentro de la definición de una transacción GeneXus.
................................................................................................................................................ 37
Figura 38. Generando una aplicación con GeneXus. ............................................................. 38
Figura 39. Especificación de los objetos GeneXus. ............................................................... 38
Figura 40. Generación de los objetos GeneXus a clases en el lenguaje para el que generemos
la app. ..................................................................................................................................... 39
Figura 41. Compilación de las clases generadas por GeneXus. ............................................. 39
Figura 42. Ejecutando la aplicación 1 ►. .............................................................................. 39
Figura 43. Ejecutando la aplicación 2 ►. .............................................................................. 40
Figura 44. Ejecutando la aplicación 3 ►. Web Form creado para la transacción Pedido. .... 40
Figura 45. Propiedades de conexión de la base de datos utilizada por la app. ....................... 41
Figura 46. Configuración de la base de datos en GeneXus. ................................................... 42
Figura 47. Objetos Externos importados a la KB................................................................... 44
Figura 48. Importación de una DLL utilizando Objetos Externos 1. ..................................... 44
Figura 54. Objeto Externo creado a partir de la importación del método Finger desde la API
Leap Motion. .......................................................................................................................... 47
Figura 55. Menú raíz de la aplicación que conforma el sistema TPV.................................... 48
Figura 56. Menú raíz de la aplicación que conforma el sistema TPV (2). ............................. 49
Figura 57. Estructura de la transacción Empresa en GX........................................................ 49
Figura 58. Tabla generada por GX a partir de la transacción Empresa.................................. 50

Figura 59. Tabla impactada por GX en BBDD a partir de la tabla generada a partir de la
transacción Empresa. ............................................................................................................. 50
Figura 60. Flujo de acciones GX desde que se crea un objeto tipo transacción hasta que lo
vemos reflejado en BBDD. .................................................................................................... 50
Figura 61. Interfaz del Menú principal para un perfil de cliente............................................ 51
Figura 62. Interfaz del MENÚ. .............................................................................................. 52
Figura 63. Tabla paramétrica para los tipos de menús en BBDD. ......................................... 52
Figura 64. Interfaz con los productos del Menú del día. ........................................................ 53
Figura 65. Contenido de la tabla MenuItem con MenuId = 31 (menú del día). ..................... 53
Figura 66. Contenido de la tabla CategoriasMenu. ................................................................ 54
Figura 67. Pop-up COMPLEMENTOS del menú. ................................................................ 54
Figura 68. Tabla que contiene la parametría de los productos clasificados como
COMPLEMENTOS. .............................................................................................................. 55
Figura 69. Pop-up MODOS del menú.................................................................................... 55
Figura 70. Tabla que contiene la parametría de los productos clasificados como MODOS. . 56
Figura 71. PEDIDO con ítems añadidos. ............................................................................... 56
Figura 72. Categorías tradicionales que componen una carta. ............................................... 57
Figura 73. PEDIDO con ítems añadidos desde la carta. ........................................................ 57
Figura 74. Interfaz del Menú principal para un perfil de empleado. ...................................... 58
Figura 75. Interfaz del modo ADMINISTRAR para perfiles de empleado. .......................... 58
Figura 76. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña
PEDIDOS. .............................................................................................................................. 59
Figura 77. Tabla “Pedido” en BBDD. .................................................................................... 60
PEDIDOS, botón Mantenimiento. ......................................................................................... 61
PEDIDOS, filtro Estado. ........................................................................................................ 61
PEDIDOS, filtro Fecha. ......................................................................................................... 61
Figura 81. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña ITEMS. 62
Figura 82. Tabla “Item” en BBDD. ....................................................................................... 62
CATEGORIAS, Carta. ........................................................................................................... 63
CATEGORIAS, Menu. .......................................................................................................... 63
Figura 85. Panel de Control de Leap Motion → Resolución de problemas → Device Status 64
Figura 86. Ejecutando por primera vez… (1) ........................................................................ 65


Figura 94. Montando la primera app con Visual Studio (1)................................................... 69
Figura 100. Montando la primera app con Visual Studio (7)................................................. 71
Figura 101. Ejecutando nuestro propio ‘Hola Mundo’. Caso 1. (1)....................................... 72
Figura 102. Ejecutando nuestro propio ‘Hola Mundo’. Caso 1. (2) ....................................... 73
Figura 106. Ejecutando nuestro propio ‘Hola Mundo’. Caso 2. (3)....................................... 75
Figura 107. Analizando los resultados obtenidos. Casos de prueba. (1) ................................ 75
Figura 108. Analizando los resultados obtenidos. Casos de prueba. (2). Inclinación mano
(front / back)........................................................................................................................... 76
Figura 109. Analizando los resultados obtenidos. Casos de prueba. (3). Inclinación mano (eje
vertical) .................................................................................................................................. 77
Figura 110. Analizando los resultados obtenidos. Casos de prueba. (4). Inclinación mano (eje
horizontal) .............................................................................................................................. 77
Figura 111. Analizando los resultados obtenidos. Casos de prueba. (5). Dirección brazo. ... 77
Figura 112. Analizando los resultados obtenidos. Casos de prueba. (6). Posición de la
muñeca. .................................................................................................................................. 78
Figura 113. Analizando los resultados obtenidos. Casos de prueba. (7). Posición del codo. 78
Figura 114. Analizando los resultados obtenidos. Casos de prueba. (8). Información dedos.79
Figura 115. Prototipo de interfaz para gestionar pedidos desde la cocina. ............................ 79
Figura 116. Condiciones para el lanzamiento de eventos. ..................................................... 83

ÍNDICE DE TABLAS
Listado de tablas a las que en esta memoria se hace referencia.
Tabla 1. Magnitudes físicas medidas por los sensores de Leap. ............................................ 19

Tabla 2. Descripción de los parámetros del constructor del objeto Hand. ............................. 21
Tabla 3. Descripción de los parámetros del constructor del objeto Arm. .............................. 22
Tabla 4. Descripción de los parámetros del constructor del objeto Finger. ........................... 24
Tabla 5. Descripción de los parámetros del constructor del objeto Frame. ........................... 26
Tabla 6. Versión de instalación de los componentes asociados al SQL Server que
utilizaremos en la app. ........................................................................................................... 41

LISTADO DE ABREVIATURAS, SIGLAS Y SÍMBOLOS
A continuación se presenta un listado de términos utilizados en esta memoria, junto a su

correspondiente significado.
1. TFG: Trabajo de fin de Grado.

2. TPV: Terminal Punto de Venta.
3. BBDD: Bases de datos.
4. API: Interfaz de programación de aplicaciones.
5. Sistemas DAQ: Sistemas de adquisición de datos.
6. JSON: JavaScript Object Notation.
7. KB: Knowledge Base (base de conocimiento).
8. PK: Primary key (clave primaria).
9. DLL: Dynamic Link Library.
10. VS2012: Visual Studio 2012.
11. GX: GeneXus.

1. INTRODUCCIÓN
La evolución de los sistemas TPV (Terminal Punto de Venta) en el mundo de la restauración

ha ido creciendo conforme se extiende cada vez más el uso de las nuevas tecnologías. Tablets,
pantallas táctiles e incluso smartphones sustituyen ya a las clásicas cajas registradoras con grandes
botones con las que hasta no hace mucho tiempo se gestionaban cobros, pedidos y comandas.
Este proyecto pretende acercar parte de estas nuevas funcionalidades ya existentes al sector
y complementarlas con un enfoque distinto, el cual se centra principalmente en una zona
concreta de los locales de restauración: la cocina.
Este nuevo enfoque consiste en controlar las pantallas táctiles que se utilizan para actualizar
los estados de las comandas (las cuales ya existen en la mayoría de estos espacios -cocinas-), de
una forma totalmente innovadora: únicamente con control gestual.
La utilidad de la propuesta es evidente si suponemos que las personas que trabajan dentro de
estos espacios tienen ocupadas sus manos durante la mayor parte del tiempo, como para hacer uso
de una pantalla táctil constantemente. Leap Motion es un controlador de movimiento capaz de
evitar que perdamos tiempo cada vez que necesitemos actualizar la comanda, incrementando así
también la productividad, y de ese modo eludir además ensuciar la pantalla táctil del sistema TPV
tradicional, ya que con este dispositivo seríamos capaces de controlar el sistema solamente
con gestos y sin entrar en contacto físico con dicha pantalla.
1.1. ¿Qué es un Sistema TPV?
A nivel comercial, un sistema informático de este tipo es el que nos permite gestionar todo el
proceso de venta (tickets, facturas, ventas, cobros, generar informes, etc,…).
Un TPV eficaz sirve para acelerar y organizar las tareas ligadas a cualquiera de estos procesos
de venta, de forma que las operaciones comerciales se pueden hacer de forma mucho más fácil
que con las ya antiguas cajas registradoras.
Figura 1. Caja registradora convencional vs sistema TPV (Fuente: www.holasoft.es)

1.1.1. Componentes de un sistema TPV
Los numerosos tipos de TPV (dependen de hacia qué sector comercial esté enfocado su uso)
que nos podemos encontrar hacen que tengamos una serie de requisitos técnicos o componentes
que debemos tener en cuenta cuando creamos o instalamos un sistema de este tipo, y no baste
solamente con descargarnos un programa para utilizarlo correctamente.
Por ejemplo, en un restaurante, además de la aplicación software y de la infraestructura de

pantallas o tablets para ver y gestionar pedidos, añadido deberíamos al menos tener un módulo
que permita pagos con tarjeta y otro que imprima tickets. Y en un supermercado, además, por
ejemplo, al menos un módulo que lea códigos de barras.
Llegados a este punto, por lo tanto, en un sistema TPV deberemos diferenciar entre:
- Software instalado.
- Componentes Hardware, necesarias para un buen servicio al cliente.
En nuestro caso práctico-teórico, desarrollaremos nosotros mismos la aplicación (software) y

utilizaremos un ordenador portátil junto a un sensor gestual (hardware).
En un caso real de puesta en funcionamiento del sistema planteado en esta memoria,

necesitaríamos como mínimo un terminal móvil con el software instalado por cada camarero del
restaurante, un terminal central (que podría ser una pantalla táctil u ordenador) con su CPU +
módulo de impresión de tickets + módulo de pagos con tarjeta; y además, la parte fundamental
en la que se basa este proyecto: una pantalla + sensor gestual en cocina. Todo con acceso a
Internet, ya que nuestro servidor supuesto estará en la nube.
1.2. Nacimiento de la propuesta de TFG
La idea de realizar este tipo de proyecto nace de la mezcla de 2 situaciones, las cuales vamos
a describir a continuación.
- En primer lugar, de la posibilidad de realizar un TFG utilizando la tecnología ‘Leap

Motion’ que se proporcionaba, en este caso, por el tutor del proyecto, Adolfo Albaladejo.
- Y en segundo lugar, por la demanda que me venía haciendo desde hacía tiempo un buen
amigo cocinero. Su propuesta era poner en marcha el sistema TPV entero para su local,
con lo que dándole vueltas después, se me ocurrió hacerlo y además aprovechando e
introduciendo la tecnología que iba a usar en mi TFG.

1.3. Ideas generales y objetivos del proyecto
La idea y propósito general de este trabajo de fin de grado es prototipar una aplicación capaz
de conseguir una comunicación desde cocina con el exterior solamente realizando gestos,
haciendo uso de un sensor captador de movimientos de manos, dedos y objetos que
posteriormente describiremos.
La realidad es que los cocineros cuotidianamente tienen las manos ocupadas y embrutecidas,
así que de esta forma les sería mucho más cómodo poder actualizar el estado de los pedidos y
comandas de forma rápida. Con esto conseguiremos ser más productivos en la cocina, y, además,
contribuiremos a cuidar el estado de los aparatos que intervienen en un sistema TPV convencional
(p. ej más limpios), donde generalmente, se interactúa a través de una pantalla o incluso pantalla
+ algún otro tipo de hardware (ratones, teclados, …).
1.4. Fases del desarrollo del proyecto
El proyecto se ha desarrollado durante varios meses, los cuales han estado organizados por un
plan de trabajo que se dividió en 9 fases:
- Fase 1: Definición de los requerimientos mínimos del prototipo del sistema TPV.
- Fase 2: Documentación sobre el dispositivo Leap Motion. Consistió en obtener
información sobre el modo de funcionamiento del dispositivo que íbamos a usar, así como
de su API asociada, la cual nos facilitaba el fabricante.
- Fase 3: Implementación y codificación del prototipo web del TPV con GeneXus. En esta
etapa se crea también el servidor de base de datos (localhost) con el que trabajará la
aplicación
- Fase 4: Generación de la aplicación en C# web con GeneXus.
- Fase 5: Pruebas del sistema TPV.
- Fase 6: Instalación de los productos Leap Motion y prueba de su entorno de desarrollo a
partir de ejemplos básicos ‘Hola Mundo’ que encontramos en la web oficial del
dispositivo. En nuestro caso, en C#.
- Fase 7: Definición y desarrollo de los casos de prueba definidos sobre los desarrollos
realizados para el dispositivo Leap Motion.
- Fase 8: Análisis funcional para la integración del dispositivo Leap Motion con la
aplicación TPV web desarrollada.
- Fase 9: Generación de la documentación. Se incluye la presente memoria, resúmenes en
castellano e inglés, póster y presentación utilizada en la defensa frente al tribunal.

2. METODOLOGÍA Y TECNOLOGÍAS UTILIZADAS
Una vez introducido el contexto funcional del proyecto, así como su hipotética finalidad y
objetivos, vamos a detallar a continuación la metodología y tecnologías de las que se va a hacer
uso durante todo el proceso de elaboración de nuestra aplicación.
2.1. ‘Leap Motion’: el sensor de control gestual
Nuestro elemento protagonista es Leap, un diminuto dispositivo (80x30x12mm y apenas 80$)

de control gestual, que colocado frente a la pantalla de un ordenador es capaz de capturar con una
precisión enorme los movimientos de nuestras manos, dedos e incluso algunos objetos
determinados.
Figura 2. Controlador ‘Leap Motion’. (Fuente: https://www.geek.com)
Como se puede observar en la Figura 2, Leap cuenta con un sensor del tamaño de un pendrive,
el cual se enchufa en el puerto USB y detecta el movimiento de nuestras manos sobre él,
interpretando los gestos que vayamos haciendo como acciones en nuestra máquina.
Figura 3. Escenificación del funcionamiento del sensor ‘Leap Motion’. (Fuente: www.realidad-virtual.net)

2.1.1. Partes físicas del dispositivo (hardware)
En esta primera parte del estudio de Leap, vamos a analizar los componentes principales que
forman el hardware y, próximamente, veremos también el principio de funcionamiento y un
resumen de la API del controlador.
▪ CÁMARAS Y LEDS DE ILUMINACIÓN INFRARROJA

Leap Motion cuenta con 2 cámaras y 3 LEDs, con la distribución física que se indica en la
Figura 4:
Figura 4. Interior del dispositivo – Esquema distribución cámaras, LEDs. (Fuente: ncbi.nlm.nih.gov)
Cada una de estas cámaras cuenta con un sensor monocromático sensible a la luz infrarroja,
con una longitud de onda de 850 nm. Estos sensores pueden trabajar a una velocidad de hasta 200
fps, dependiendo del rendimiento del ordenador/tablet al que conectemos el dispositivo.
Además, cada sensor es de tipo CMOS. Algunas de las características principales que hacen
que este tipo de sensor sea el utilizado y no los CCD, son, por ejemplo:
• La digitalización de los píxeles en un sensor CMOS se produce dentro de cada celda, por
lo que no es necesario un chip externo (como ocurriría en el caso de utilizar sensores
CCD). Esto se traduce en mayor velocidad para capturar imágenes y en menor espacio
para albergar los sensores.
• Estos sensores son más económicos que los sensores CCD.
• En este tipo de sensor no se produce el fenómeno blooming, al contrario que en los
sensores CCD. Este fenómeno se produce cuando una celda se satura de luz y hace que
las celdas de alrededor también se saturen.
• La lectura simultánea de celdas en los CMOS es mayor que en los CCD.
• El consumo eléctrico de los CMOS es menor que el de los CCD.
Por lo general, los únicos objetos que verá Leap son los directamente iluminados por los
LED. Sin embargo, las bombillas incandescentes, los halógenos y la luz del día también podrán

iluminar la escena en infrarrojo. Los LED trabajan en el espectro de luz infrarroja a una longitud
de onda de 850 nm que, como es lógico, es la misma a la que son sensibles los sensores ópticos
de las cámaras.
▪ MICROCONTROLADOR CPU
Se trata de un circuito integrado que se suele utilizar para hacer la función de BIOS (MXIC
MX25L3206E–32M-bit CMOS SERIAL FLASH).
Figura 5. Placa base del dispositivo Leap Motion 1. Microcontrolador. (Fuente: image-sensors-world.blogspot.com)
La configuración de los pines de este circuito integrado es la siguiente:
Figura 6. Configuración PIN del integrado MX25L3206E (Fuente: netcheif.com)

Toda la información de este dispositivo la podemos encontrar en la hoja técnica que

proporciona su fabricante, Macronix International Co., LTD.
En este caso, el integrado contiene el programa que controla todo el dispositivo Leap (para,
entre otras cosas, regular la iluminación) y se encarga de recoger la información de los sensores
para luego enviarla al driver instalado en el ordenador.
▪ CONTROLADOR USB
Leap Motion cuenta con un controlador USB para que el ordenador pueda reconocer el
dispositivo. Este controlador es de alta velocidad, y puede soportar USB 3.0.
Figura 7. Placa base del dispositivo Leap Motion 2. Controlador USB. (Fuente: learn.sparkfun.com)
▪ PUERTOS DE ENVÍO Y RECEPCIÓN DE DATOS

Los datos se envían y se reciben al controlador del ordenador a través de dos puertos serie:
UART_RX y UART_TX.
Figura 8. Placa base del dispositivo Leap Motion 3. Puertos de E/S datos.
(Fuente: image-sensors-world.blogspot.com)

2.1.2. Funcionamiento del controlador
Como ya hemos visto en el apartado 2.1.1., Leap ilumina la zona de cobertura mediante una
luz infrarroja emitida a través de sus tres LEDs, con una longitud de onda de 850 nm. Esta zona
de cobertura está limitada por el ángulo de visión de los sensores (lo veremos en el apartado
2.1.3.) y por la corriente máxima que puede entregar la conexión USB.
Cuando un objeto es iluminado, se produce una reflexión de luz que llega al dispositivo e
incide sobre las lentes de las dos cámaras. Estas lentes, de tipo biconvexas, concentran los rayos
en el sensor de cada cámara y los datos recogidos por los sensores se almacenan en una matriz
(imagen digitalizada) en la memoria del controlador USB, en donde se realizan los ajustes de
resolución adecuados mediante el microcontrolador del dispositivo.
Una vez ajustada la resolución, los datos de los sensores se envían directamente
al driver instalado en el ordenador. Estos datos representan un valor de intensidad luminosa por
cada píxel de la imagen capturada, y se guardan en un buffer. El valor de intensidad luminosa se
cuantifica a 8 bits para generar una imagen RAW en escala de grises (por lo tanto, hay un total de
256 posibles valores de luminosidad).
Cada imagen tiene un tamaño de 640 x 120 px, con lo que en total hay 76.800 píxeles por
imagen. Como las imágenes no son tratadas en el propio dispositivo, si no que solamente se
recogen y se envían, el tamaño de estas no afectará a su rendimiento. Por eso Leap sigue siendo
igual rápido.
Una vez que las imágenes de las dos cámaras llegan al driver, son analizadas para identificar
las manos y los dedos a partir de un modelo matemático de caracterización anatómico; así como
también obtiene la profundidad del objeto mediante otro algoritmo.
Para realizar dichos cálculos correctamente hay que tener en cuenta que las lentes del
dispositivo producen una distorsión en la imagen óptica, deformando el objeto capturado. En este
caso, Leap produce lo que conocemos como distorsión compleja (o de mostacho).
Figura 9. Distorsión compleja o de mostacho. (Fuente: mtfmapper.blogspot.com)

Por lo tanto, cada buffer de datos de imagen que se envía al driver va acompañado de
otro buffer que contiene los datos de distorsión.
Para mejorar esta distorsión, el sensor tiene una opción de calibrado mediante la cual se
obtiene un mapa de mallado de puntos de calibrado que se superpone a la imagen captada por
cada sensor.
Figura 10. Imagen recogida por el sensor con el mapa de mallado de puntos superpuesto.
(Fuente: developer-archive.leapmotion.com)
Encontramos una rejilla de 64 x 64 puntos con dos valores de 32 bits cada uno. Cada uno de
estos puntos representa un rayo proyectado en la cámara. El valor de un punto del mallado define
la luminosidad de un píxel en la imagen, y se pueden obtener los datos de luminosidad de todos
los píxeles mediante interpolación.
Una vez que han llegado las imágenes, las hemos corregido debidamente y el driver ha
identificado las manos y los dedos, podemos determinar la posición de estas en el sistema de
coordenadas cartesianas de Leap a través de técnicas de visión estereoscópica. Básicamente, un
sistema estereoscópico funciona del siguiente modo: gracias a la separación de las dos cámaras
en el eje X se obtienen dos imágenes con pequeñas diferencias.
Figura 11. Imágenes Ii e Id (dispares) cuya fuente son dos cámaras separadas en el eje X.

Como se puede observar en la imagen anterior, las dos cámaras (representadas por Oi y Od)
están en el mismo plano Z, sobre la línea base. Si trazamos una línea epipolar entre las dos
imágenes Ii e Id, dado que Oi y Od están en el mismo plano Z y las dos cámaras tienen la misma
distancia focal, podemos ver la proyección del punto P en las dos imágenes.
Por lo tanto, se puede obtener un valor de disparidad d para cada par de puntos emparejados
Pi(xi,yi) y Pd(xd,yd) dado por d = XI-XD.
Figura 12. Diagrama representando los parámetros que intervienen en el cálculo de la disparidad entre imágenes.
Considerando igual la distancia focal f en las dos cámaras y conociendo la distancia entre
cámaras b:
𝑏
+ 𝑋 𝑥𝑖 𝑓 𝑏 𝑓·𝑏
𝑂𝑖 : 2 = 𝑥𝑖 = (𝑋 + ) 𝑑 = 𝑥𝑖 − 𝑥𝐷 =
𝑍 𝑓 𝑍 2 𝑍
𝑏
− 𝑋 𝑥𝐷 𝑓 𝑏 𝑓·𝑏
𝑂𝐷 : − 2 = 𝑥𝐷 = (𝑋 − ) 𝑍=
𝑍 𝑓 𝑍 2 𝑑
Ecuación 1.
Como vemos, a partir del sistema estereoscópico podemos obtener las coordenadas del
punto P.
En resumen, los pasos básicos que realiza Leap para devolvernos la información de los objetos
que captura es la siguiente:
1. Obtiene las imágenes desde los sensores de las cámaras del dispositivo.
2. Aplica una corrección de la distorsión que producen los sensores.
3. Aplica un modelo para determinar la configuración de cada mano y ejecuta un algoritmo
de visión estereoscópica entre cada par de imágenes para obtener la posición en el plano
tridimensional.

2.1.3. Resumen de la API del sensor (v3.2.1_win)
Como ya hemos comentado en los apartados anteriores, este dispositivo es capaz de reconocer
y rastrear manos, dedos y objetos. Está basado en un sistema de coordenadas cartesianas (diestro),
y funciona con muy alta precisión gracias a sus sensores ópticos y de luz infrarroja. Estos sensores
se dirigen a lo largo del eje Y (hacia arriba, cuando el controlador se encuentra en su posición de
funcionamiento estándar); y tienen un campo de visión de aproximadamente 150º de izquierda a
derecha y 120º desde atrás hacia adelante.
El alcance efectivo se extiende desde aproximadamente 25 a 600 milímetros sobre el

dispositivo (1 pulgada a 2 pies aprox.). La detección y seguimiento funcionan mejor cuando el
controlador tiene una vista clara y un alto contraste de la silueta del objeto, dedos o mano que
rastrea.
El software combina sus datos físicos obtenidos de los sensores con un modelo interno de la
mano humana para ayudarlo a sobrellevar las difíciles condiciones de rastreo posibles.
Figura 13. Puntos del esqueleto del modelo interno de la mano definida por el controlador Leap Motion,
funcionamiento del cual está basado en el sistema de coordenadas cartesianas. (Fuente: www.mdpi.com)
A—Dedo pulgar, B—Índice, C—Medio, D—Anular, E—Meñique, F—Posición punta, G—Posición de la palma, H—
Posición de la muñeca, I—Brazo, J—Falange distal, K—Falange medial, L—Falange proximal, M—Hueso
metacarpiano. Las marcas J, K, L, M correspondientes a las falanges se encuentran en los 5 dedos del modelo.
El origen del sistema de coordenadas está centrado en la parte superior del controlador. Los
ejes X y Z se encuentran en el plano horizontal, con el eje X paralelo al borde largo del
dispositivo.
El eje Y es vertical, con valores positivos que aumentan hacia arriba (al contrario que la
mayoría de los sistemas de coordenadas gráficas virtuales, cuya orientación positiva suele ser
hacia abajo).
El eje Z tiene valores positivos que aumentan hacia el usuario.

La API de ‘Leap Motion’ mide magnitudes físicas con las siguientes unidades,
Distancia: milímetros (mm)

Tiempo: microsegundos (µs)
Velocidad: milímetros / segundo (mm/s)
Ángulo: radianes (rad)
Tabla 1. Magnitudes físicas medidas por los sensores de Leap.
y su programación permite el uso de los siguientes lenguajes:
Figura 14. Lenguajes permitidos por la API para hacer uso de Leap
Como Leap rastrea las manos, los dedos y los objetos dentro de su campo de visión,
proporciona actualizaciones como un conjunto de datos representado en un tipo de objeto Frame.
Figura 15. Contexto de los objetos que contiene la API (Fuente: blog.leapmotion.com).
A continuación veremos qué datos obtiene Leap de cada tipo de los principales objetos para
representarnos y devolvernos la información de cada uno de ellos.

2.1.3.1 Objeto Hand (mano)
El modelo de mano está representado por la clase Hand, y proporciona información sobre la
identidad, posición, velocidad de la palma y otras características de una mano detectada.
Los vectores PalmNormal (vector normal, perpendicular) y PalmDirection (dirección de los

dedos) son los encargados de definir la orientación de la mano.
Figura 16. Vectores que proporcionan información sobre la orientación de la mano.
Además, Hand también recoge datos del brazo (objeto Arm) al que está sujeta la mano y de
los dedos (objeto Finger) asociados a dicha mano.
Figura 17. Constructor de un objeto Hand.

Parámetros:
frameID ID del frame al que pertenece esta la mano.
id ID de la mano.
confidence Estimación de la aptitud – fiabilidad de los datos.
grabStrength Rating de la postura de agarre de la mano.
grabAngle Ángulo promedio de los dedos de la mano.
pinchStrength Rating de la postura de pellizco de la mano.
pinchDistance Distancia (mm) entre las puntas de los dedos índice y pulgar al pellizcar.
palmWidth Ancho de la mano.
IsLeft Verdadero cuando se trata de una mano izquierda. Falso en caso

contrario.
timeVisible Cantidad de tiempo que la mano ha estado visible.
arm Objeto Arm (brazo) para esta mano.
fingers Lista de dedos (objetos Finger) para esta mano.
palmPosition Posición de la palma de la mano.
stabilizedPalmPosition Posición media en el tiempo de la palma.
palmVelocity Vector velocidad de la mano.
Vector palmNormal – vector normal de la palma.
direction Dirección de la mano.
wristPosition Posición de la muñeca.
Tabla 2. Descripción de los parámetros del constructor del objeto Hand.
Como ya hemos comentado en el apartado 2.1.3., el software usa un modelo interno de una
mano humana (Figura 13) para proporcionar un seguimiento predictivo, incluso cuando partes de
una mano no son visibles. El modelo siempre proporciona posiciones para cinco dedos, aunque
el seguimiento es óptimo cuando la silueta de una mano y todos sus dedos son claramente
visibles. El software usa las partes visibles de la mano, su modelo interno y observaciones pasadas
para calcular las posiciones más probables de las partes que no están dentro del campo de visión
del sensor en un momento dado.

El software permite que puedan aparecer más de dos manos en la lista de manos para un frame.
Sin embargo, se recomienda mantener como máximo dos manos en el campo de visión del
sensor para obtener una calidad de seguimiento de movimiento óptima.
2.1.3.2 Objeto Arm (brazo)
Arm es un objeto que representa al antebrazo, y que proporciona información sobre la

orientación (vector de dirección), longitud, ancho y puntos finales (posiciones de muñeca y codo)
de un brazo.
Figura 18. Constructor de un objeto Arm.
Parámetros:
elbow Posición del codo.
wrist Posición de la muñeca.
center Posición del punto medio entre el codo y la muñeca.
direction Vector de dirección desde el codo hasta la muñeca.
length Distancia entre el codo y la muñeca (mm).
width Ancho del brazo (estimado).
basis Matriz que representa la orientación del brazo.
Tabla 3. Descripción de los parámetros del constructor del objeto Arm.
Cuando el codo no está a la vista, el controlador estima su posición basándose en

observaciones pasadas (como pasaba con el objeto Hand), así como en datos sobre la proporción
humana típica.

2.1.3.3 Objeto Finger (dedo)
Leap proporciona información sobre cada dedo de una mano. Si la totalidad o parte de un dedo
no es visible, como pasaba con los tipos de objeto anteriores, las características del dedo se
estiman en base a las observaciones recientes y el modelo anatómico de la mano definido. Los
dedos se identifican por el nombre del dedo real, es decir: pulgar, índice, centro (corazón), anular
y meñique.
Figura 19. Constructor de un objeto Finger.
Los vectores tipPosition y direction proporcionan la posición de la punta de un dedo y la

dirección general a la que apunta un dedo:
Figura 20. Vectores que proporcionan información sobre la posición y dirección de un dedo.

En general, no se debería crear objetos Finger propiamente dichos, ya que estos no tendrán
datos de seguimiento válidos. La información se debe obtener desde un objeto Hand (mano)
contenido en un frame.
Parámetros:
frameId ID del frame en el que aparece el dedo.
handId ID de la mano que contiene el dedo.
fingerId Identificación de un dedo concreto, (formato = handId + num[0,4]

para la posición del dedo).
timeVisible Cantidad de tiempo que ha estado visible el dedo.
tipPosition Posición de la punta del dedo.
tipVelocity Velocidad de la punta del dedo.
direction Dirección a la que apunta el dedo.
stabilizedTipPosition Posición de la punta del dedo estabilizada.
width Ancho promedio del dedo.
length Longitud del dedo.
isExtended Nivel de extensión del dedo (si está más o menos recto).
type Nombre del dedo (pulgar, índice, corazón, anular o meñique).
metacarpal Primer hueso del dedo (teniendo la muñeca como referencia, ver
Figura 4).
proximal Segundo hueso del dedo (‘’).
intermediate Tercer hueso del dedo (‘’).
distal Último hueso (‘’).
Tabla 4. Descripción de los parámetros del constructor del objeto Finger.
A nivel anatómico, un pulgar real tiene un hueso menos que los otros dedos. Sin embargo,
para facilitar la programación, el modelo de pulgar del controlador incluye un hueso metacarpiano
de longitud cero para que el pulgar tenga el mismo número de huesos en los mismos índices que
los otros dedos.

Como resultado, el hueso metacarpiano anatómico del

pulgar se etiqueta como una falange proximal, y la falange
proximal anatómica se etiqueta como la falange intermedia
en el modelo de dedo del hueso virtual.
Figura 21. Esquema anatómico de una mano humana.
(Fuente: commons.wikimedia.org).
En definitiva, el objeto Finger nos devolverá por cada dedo definido dentro de un objeto Hand
(mano) información sobre los siguientes parámetros:
• Posición y velocidad de la punta.

• Vector de dirección.
• Anchura y longitud del dedo.
2.1.3.4 Objeto Frame
El objeto Frame es el cuadro que contiene cualquier mano rastreada, y esencialmente la raíz
del modelo de datos del dispositivo. Representa un conjunto de datos de seguimiento de manos y
dedos detectados, detallando sus propiedades en un instante temporal.
A continuación, podemos ver un diagrama de la relación entre el objeto Frame y otros objetos
a los que se puede acceder a través de él:
Figura 22. Diagrama que representa la relación con otros objetos del objeto ‘Frame’.

Como podemos ver en la Figura 22, Frame nos da la posibilidad de acceder a todas las
clases List, a partir de las cuales se puede acceder a una lista de objetos del mismo tipo y que
aparecen en cada Frame.
Figura 23. Constructor de un objeto Frame.
id ID del frame.
timestamp Tiempo de creación del frame (en µs).
fps Velocidad de refresco del frame.
interactionBox Objeto InteractionBox para el frame concreto.
Tabla 5. Descripción de los parámetros del constructor del objeto Frame.
La clase InteractionBox representa una región en forma de caja, completamente dentro del
campo de visión del controlador. Dicha región está definida por un centro y dimensiones a lo
largo de los ejes x, y, z.
Figura 24. Región contextual del objeto InteractionBox.(Fuente: developer-archive.leapmotion.com)
El cuadro de interacción es un prisma rectangular alineado al eje y que proporciona

coordenadas normalizadas para manos, dedos y otras herramientas contenidas en el frame.
La utilidad de esta clase es facilitar la asignación de posiciones en el sistema de coordenadas

de Leap a sistemas de coordenadas 2D o 3D, utilizados para el trazado de aplicaciones.

2.1.3.5 Interfaz de comunicación entre la aplicación y el dispositivo
En cuanto a comunicación con Leap, el principal objeto es Controller(), que se encarga de

hacer de interfaz entre la aplicación que desarrollemos y el dispositivo. Lo que más nos interesa
de esta clase es el método frame(), a través del cual podemos acceder al objeto Frame que
deseemos; por defecto, al último que ha llegado desde el dispositivo.
Hay dos modos de acceder a un objeto Frame:
- Desde el objeto Controller, a través del método frame().

- Desde el objeto Listener, a través de los eventos que se van disparando.
Usar un modo u otro dependerá de si queremos analizar o no todos los frames que lleguen
desde Controller. Si queremos analizarlos todos, accederemos a la información del objeto Frame
a través de Listener; pero, si por el contrario, queremos analizar un objeto Frame solamente cada
cierto tiempo, accederíamos desde el objeto Controller.
La clase Listener define un conjunto de funciones para responder a eventos enviados por
el objeto Controller.
Figura 25. Objeto Listener y sus métodos asociados a Controller.
Para manejar eventos…
1) Se debe crear una instancia de una subclase Listener y asignársela a la instancia de

Controller.
2) Controller llamará a la función que le responde de la clase Listener cuando ocurre un

evento, pasándose una referencia a sí mismo.
No es necesario que se implementen respuestas a las llamadas desde Controller para eventos
que no nos interesan.

Otro método interesante es el onFrame(), evento que se produce cada vez que el dispositivo
captura una imagen. Este es el evento principal, ya que dentro de este se pueden implementar
todas las acciones que queremos hacer sobre los objetos ya vistos anteriormente (manos, dedos,
brazos, etc.).
2.1.3.6. Los gestos que interpreta Leap Motion
Llegados a este punto, toca explicar qué tipo de gestos son con los que realmente trabaja e
interpreta Leap a través de los sensores, cálculos, objetos, etc,… anteriormente descritos.
Dentro de la API nos encontramos 4 métodos que corresponden a tipos diversos de

movimientos. La dependencia de estos 4 objetos con los demás aparece en la Figura 22, ya que
también se puede acceder a ellos a través del objeto padre Frame.
Figura 26. Tipos de gesto interpretados por Leap Motion. (Fuente: github.com)
• El gesto ‘SwipeGesture’ representa un movimiento de deslizamiento de un dedo u

objeto.
El reconocimiento por parte de Leap de este tipo de gesto necesita de la información del
método vector de dirección paralelo al movimiento de deslizamiento, direction(). Es posible
comparar los componentes del vector para clasificar el deslizamiento según corresponda para
una cierta aplicación. Por ejemplo, si se está usando deslizamientos para desplazamiento
bidimensional, se puede comparar los valores de los ejes x e y para determinar si el
deslizamiento es principalmente horizontal o vertical.
• El gesto ‘CircleGesture’ representa el movimiento circular de un dedo.

En este caso, la información que maneja el controlador para interpretar este tipo de gesto está
definida por el vector normal al círculo que se traza (normal()), un número positivo de tipo
flotante (devuelto por progress()) que indica las veces que la punta del dedo u objeto ha atravesado
el círculo y el radio del círculo trazado, obtenido del método radius(), en mm.

• El gesto ‘ScreenTapGesture’ representa un ‘click’ sobre algún punto de la pantalla, que

puede ser hecho por un dedo u objeto.
Igual que pasaba con el gesto Swipe, este tipo de movimiento también necesita
información del método direction(). En este caso, para determinar la dirección de la punta
del dedo u objeto. Además, a través del método pointable() obtendremos el dedo concreto
que ha hecho ‘click’; y a través de otro método position(), la posición exacta de la pantalla
donde se ha producido este evento.
• El gesto ‘KeyTapGesture’ representa un ‘click’ rápido y descendente sobre algún punto

de la pantalla, que también, como en los casos anteriores, puede ser producido por un
dedo u objeto.
Para obtener la información sobre el tipo de movimiento, este objeto se basa exactamente
en los mismos métodos que el tipo de gesto anterior.
2.1.4. Arquitectura del sistema
En Windows, el software de Leap Motion se ejecuta como un servicio más. Para otros
sistemas operativos (Linux y Macintosh), como daemon.
El SDK proporciona dos variedades de API para obtener datos de seguimiento del servicio
de Leap: una interfaz nativa y una interfaz WebSocket (web).
2.1.4.1 Interfaz nativa
La interfaz nativa es una biblioteca dinámica que se puede usar para crear aplicaciones
nuevas habilitadas para Leap. Esta biblioteca se conecta al servicio Leap Motion y proporciona
datos de seguimiento a su aplicación.
Figura 27. Aplicaciones habilitadas con Leap a través de la interfaz nativa del dispositivo.

Analizando la Figura 27,
1. El servicio Leap Motion recibe datos del dispositivo controlador a través del bus
USB. Procesa esa información y la envía a ejecutar aplicaciones habilitadas para
Leap. De forma predeterminada, el servicio sólo envía datos de seguimiento a la
aplicación en primer plano. Sin embargo, las aplicaciones pueden solicitar que reciban
datos en segundo plano (esta solicitud puede ser denegada por el usuario si así lo
requiere).
2. La aplicación Panel de Control de Leap Motion se ejecuta por separado del servicio, y
permite al usuario configurar su instalación. Dicha aplicación es un applet del Panel de
Control en Windows, y una aplicación en la barra de menús en Macintosh y Linux.
Figura 28. Aplicación Panel de Control Leap Motion corriendo en Windows.
3. La aplicación habilitada para Leap recibe datos en primer plano de seguimiento de

movimiento del servicio. Una aplicación habilitada para Leap se puede conectar al
servicio utilizando la biblioteca nativa del dispositivo.
4. Cuando una aplicación habilitada para obtener información pierde el foco del sistema
operativo, el servicio deja de enviarle datos. Las aplicaciones destinadas a trabajar en
segundo plano pueden solicitar permiso para recibir datos incluso cuando están en
segundo plano. Cuando una aplicación está en segundo plano, la aplicación de primer
plano determina los ajustes de configuración.
2.1.4.2 Interfaz web (WebSocket)
La interfaz WebSocket permite crear aplicaciones web habilitadas para Leap. El servicio
ejecuta un servidor WebSocket en el dominio localhost, puerto 6437. Esta interfaz proporciona
datos de seguimiento en forma de mensajes JSON (notación de Objetos de JavaScript), un formato

de intercambio de datos abierto y basado en texto, que ofrece un intercambio estandarizado de

datos. Consultar su referencia estándar RFC4627 para más información.
Está disponible una biblioteca de cliente JavaScript leap.js que consume los mensajes JSON
y presenta los datos de seguimiento como objetos regulares de JavaScript.
Figura 29. Aplicaciones web habilitadas para Leap a través de la interfaz WebSocket.
Analizando la Figura 29,
1. El servicio Leap Motion proporciona un servidor WebSocket que escucha

en http://127.0.0.1:6437.
2. El panel de control permite a los usuarios finales habilitar o deshabilitar el servidor
WebSocket.
Figura 30. Opción habilitar / inhabilitar a las aplicaciones el acceso al servidor WebSocket.
3. El servidor envía datos de seguimiento en forma de mensajes JSON. Una aplicación

puede enviar mensajes de configuración al servidor.
4. La biblioteca de JavaScript del cliente leap.js se debe usar en aplicaciones web. La
biblioteca establece la conexión con el servidor y consume los mensajes JSON.
Esta interfaz está destinada principalmente para aplicaciones web, pero cualquier aplicación
que pueda establecer una conexión WebSocket puede usarla. El servidor cumple con el protocolo
estándar RFC6455 contenido en The WebSocket Protocol.

2.2. Lenguajes de programación y herramientas
Llegados a este punto, como se puede intuir, una herramienta muy importante de desarrollo
que va a ser utilizada en este proyecto es la API que nos proporciona el fabricante de Leap Motion
y todo lo que esta contiene. Además, para codificar la aplicación TPV usaremos el lenguaje de
programación C# con ayuda de un generador de código llamado GeneXus, del cual explicaremos
su funcionamiento y características en el apartado 2.2.1.
2.2.1. GeneXus: el generador de código
Como ya hemos comentado en la introducción de este apartado, el responsable de generar

nuestra aplicación web de nuestro TPV va a ser un software llamado GeneXus, en concreto la
versión X Evolution 2.
Figura 31. Logo GeneXus X Evolution 2.
A continuación, en los apartados 2.2.1.1. y 2.2.1.2. definiremos sus principales

características y analizaremos las causas por las que hemos elegido este programa para desarrollar
nuestra aplicación.
2.2.1.1 ¿Qué es y para qué sirve GeneXus?
GeneXus es un generador de programas informáticos (como por ejemplo, aplicaciones

Windows, web y orientadas a Smart Devices). Los desarrolladores escriben la aplicación en un
lenguaje de alto nivel, principalmente declarativo, a partir del cual se genera código nativo para
múltiples entornos. Es una herramienta para crear, desarrollar y mantener en forma prácticamente
automática aplicaciones multiplataforma, que se adaptan fácilmente a los cambios de negocio y a
las nuevas posibilidades brindadas por la evolución tecnológica en la implementación de sistemas
informáticos.
El objetivo de GeneXus es lograr que las aplicaciones estén funcionando en el menor tiempo
y con la mejor calidad posible.
En general, el desarrollo de una aplicación implica tareas de análisis, diseño e

implementación. Por eso, GeneXus libera al desarrollador de las tareas que son automatizables
(como el diseño de la base de datos y escribir el código fuente), permitiéndole así concentrarse en

aquellas tareas realmente difíciles y no automatizables, como comprender las necesidades y los
problemas de los usuarios.
El analista GeneXus trabaja básicamente entendiendo y

describiendo la realidad del usuario; y el software se encarga,
por sí solo, de generar muchas funcionalidades útiles que
permiten contar con una aplicación lista para funcionar muy
rápidamente.
Figura 32. Definiendo GeneXus 1.
Los lenguajes para los cuales se puede generar código incluyen C#, COBOL, Java (incluso
para Android y BlackBerry), Swift para iOS, Objective-C, RPG, Ruby, Visual Basic, etc,...
Figura 33. Lenguajes de programación soportados en función de la plataforma destino. (Fuente: genexus.com)
Los sistemas gestores de bases de datos más populares están soportados, como SQL
Server, Oracle, DB2, Informix, PostgreSQL y MySQL.
Figura 34. Lenguajes de programación y clientes de BBDD soportados en función de la plataforma destino.
(Fuente: genexus.com)

2.2.1.2 ¿Por qué GeneXus?
Cuando nos solicitan desarrollar una aplicación informática, el cliente nos plantea el
problema que quiere resolver de acuerdo a su visión particular. Lo primero que debemos hacer es
interpretar la realidad que nuestro cliente nos describe, construir un modelo y luego diseñar una
solución que represente lo mejor posible esa realidad. También es importante que el producto
desarrollado sea capaz de adaptarse a los cambios que sufre esa realidad, y que esos cambios los
podamos realizar en un tiempo razonable.
Con la metodología de desarrollo tradicional, el proceso de desarrollo incluye

principalmente 2 partes:
- El diseño de un modelo de datos.

- El análisis funcional, que genera especificaciones a partir de las cuales se construyen los
programas a implementar.
El problema de esta forma de trabajo es la suposición de que es viable construir un modelo

de datos estable de la aplicación, lo cual es imposible debido a la dinámica cambiante de la
realidad.
Si la realidad cambia, debemos volver a realizar un análisis del modelo de datos, cambiar su
implementación, volver a hacer un análisis funcional y cambiar la codificación de los programas.
Todo esto lleva mucho tiempo, por lo cual, la metodología tradicional deja de ser eficiente
frente a cambios frecuentes en los requerimientos del usuario.
GeneXus nos ofrece una alternativa. A partir de los requerimientos de los usuarios, el
desarrollador analiza e interpreta sus ideas, y luego lo sistematiza con objetos generalmente de
tipo Transacción (que al final se materializa en una tabla de BBDD + un web panel) en una base
de conocimiento en lenguaje GeneXus (Knowledge Base). A partir de esta, el software en forma
automática crea el modelo de datos en una base de datos, y construye los programas básicos de la
aplicación para cubrir las necesidades funcionales requeridas.
Esta metodología permite al desarrollador optimizar su tiempo, como ya hemos comentado,

aplicándolo a entender los problemas de los usuarios mientras que GeneXus genera la aplicación
en forma 100% automática en el lenguaje que le digamos, y para la base de datos que necesitemos.
Esto permite el desarrollo incremental de soluciones de negocio independientemente de la
plataforma de producción, y nos permite crear rápidamente prototipos totalmente funcionales con
los que podemos validar nuestro diseño con el usuario.
Por lo tanto, resumiendo, algunas de las razones por las que hemos elegido este software para
implementar nuestro sistema TPV son las siguientes:

- Desarrollo de software ágil y efectivo. Es posible generar prototipos que

funcionalmente son idénticos a la aplicación en producción. Esto permite validar en forma
temprana los requerimientos con los usuarios finales, y de esta forma minimizar errores
desde el principio del proyecto, logrando al final sistemas de mejor calidad.
- Plataforma flexible y adaptable. GeneXus genera los programas en la plataforma que
necesitemos. Si tenemos que cambiar de plataforma solamente se debe generar de nuevo
los programas y la base de datos, sin necesidad de codificar una línea.
- Plataforma resistente al cambio. Con GeneXus podemos integrar aplicaciones con otras
que usen tecnologías más modernas. Permite integrar una aplicación con sistemas
externos, desarrollar nuevas funcionalidades y nuevos sistemas, así como también
acceder y trabajar en su información desde múltiples plataformas. Todo ello sin modificar
su sistema actual.
En definitiva, GeneXus es un buen aliado para ser más productivos y estar actualizados
tecnológicamente.
Además, otra razón por la que decidimos elegir este software para desarrollar nuestro proyecto
fue contar con más de 3 años de experiencia laboral con esta tecnología, aunque no en la versión
X Evolution 2, si no en la 9.0. Gracias a esta experiencia nos ha sido más fácil adaptarnos a la
versión más actual (que ha sido la que hemos utilizado para generar nuestra aplicación).
El motivo para cambiar de versión y utilizar una que no dominábamos fue básicamente el
poder usar las funcionalidades nuevas con las que cuenta GeneXus a partir de la versión X, la
mayoría de ellas relacionadas con la generación automática de aplicaciones para móviles y
herramientas para crear aplicaciones responsive.
2.2.1.3 La base de conocimiento de una aplicación en GeneXus

(Knowledge Base - KB)
La primera tarea cuando se empieza a desarrollar una aplicación con GeneXus es crear una
base de conocimiento. Una base de conocimiento o Knowledge Base (KB, es el término más
utilizado para nombrarla) corresponde al concepto de proyecto.
Durante este proceso de creación de la KB, GeneXus crea automáticamente también una base
de datos que almacenará información relativa a nuestra base de conocimiento (objetos creados,
etc,...). Es importante decir que no se trata de la base de datos de nuestra aplicación, sino que
es una base de datos que almacenará la información asociada a las definiciones que hagamos en
nuestra base de conocimiento. Por ejemplo, si creamos dominios nuevos o reglas de cálculo.

2.2.1.4 Objeto Transacción en GeneXus
Después de crear la base de conocimiento, el siguiente paso consiste en describir los objetos
de la realidad identificados para implementar en nuestra aplicación mediante objetos GeneXus.
Por cada objeto de la realidad identificado, en nuestra aplicación crearemos un objeto GeneXus
llamado transacción.
Por ejemplo, para nuestro TPV podríamos definir varios objetos de la realidad importantes,
como pueden ser el Restaurante, Menú, la Carta, las Mesas o los Pedidos. Por cada uno de estos
objetos deberemos crear un objeto transacción, la cual los identificará dentro de nuestra
aplicación.
Dentro de cada transacción se debe definir los atributos característicos de cada objeto de la
realidad representado. Por ejemplo, para una transacción Pedido podríamos definir atributos que
nos aporten información significativa del objeto, tales que: ID de pedido, fecha del pedido, hora
del pedido, importe, estado, mesa, etc,…
Además del conjunto de atributos definidos en una transacción, hay que identificar cuáles de
ellos identifican de forma única al objeto transacción (en este caso, a la transacción Pedido).
Equivale a una clave primaria PK en BBDD. En otras palabras, por ejemplo, si identificamos el
atributo ID como PK, no será posible ingresar dos pedidos con el mismo ID.
Cada vez que creamos un objeto transacción, se genera automáticamente un Web Form
(formulario web) asociado a dicha transacción. Contiene los atributos definidos dentro de esta, y
realiza las siguientes acciones con los datos:
- Ingreso.
- Eliminación.
- Modificación.
Por eso GeneXus es tan eficaz: simplemente con definir una transacción y sus
correspondientes atributos, él mismo ya se encarga de generarse el web form y los procesos
necesarios para realizar estas acciones, sin que nosotros hayamos codificado ni una línea.
Teniendo en cuenta todo lo anterior, parece obvio que la esencia de una aplicación
desarrollada con GeneXus esté basada en la dependencia entre objetos distintos del tipo
transacción. Esto es, por ejemplo, el Pedido no tiene sentido si no está asociado a una Mesa, y lo
mismo con el Menú y la Carta, que no podrían existir sin un Restaurante.
Volviendo al ejemplo de la transacción Pedido, vamos a ver a continuación cómo ha quedado

definida dentro de nuestra KB del proyecto con la aplicación TPV real.

Figura 35. Ejemplo real de definición de transacción GeneXus. Transacción Pedido de nuestra app TPV.
Como se puede observar, la transacción Pedido infiere el atributo MesaCod desde la

transacción Mesas, ya que no tiene sentido que un pedido no esté asociado a ninguna mesa.
Figura 36. Ejemplo real de definición de transacción GeneXus. Transacción Mesas de nuestra app TPV.
En el siguiente apartado 2.2.1.5.

analizaremos también cómo se
comporta el Web Form creado
asociado a la transacción, así como sus
acciones de ingreso, eliminación y
modificación cuando generamos toda
la aplicación web y la ponemos en
Producción.
Figura 37. Ejemplo real de Web Form dentro de la definición de una transacción GeneXus.

2.2.1.5 Generando una aplicación con GeneXus
Una vez introducidos los puntos clave y objetos básicos que necesita GeneXus para empezar
a desarrollar una aplicación, ha llegado la hora de ver cómo relaciona a todos ellos y cuál es el
resultado cuando decidimos generar una aplicación.
Figura 38. Generando una aplicación con GeneXus.
Cuando generamos una aplicación con GeneXus se producen 3 eventos, de los cuales se
puede seguir su estado a través de la consola del programa.
- Lo primero que hace GeneXus es especificar los objetos que forman la base de
conocimiento de la aplicación que estamos generando.
Figura 39. Especificación de los objetos GeneXus.
En el proceso de especificación, el programa crea un objeto nuevo de tipo tabla asociada a

cada transacción nueva. Esta tabla nueva hará que GeneXus tenga que hacer una reorganización
de la BBDD, donde la crea (o en caso de que no sea nueva, sino que solamente haya sido
modificada, reorganiza igualmente la BBDD para actualizarla).
Durante este proceso, GeneXus detecta qué objetos necesitan ser especificados (sólo se
especifican si han sufrido cambios respecto a la última especificación hecha) y si necesita
reorganizar en BBDD alguna tabla nueva o una existente que haya sufrido modificaciones.

- A continuación se produce la generación de clases, en el lenguaje que hayamos escogido

que lo haga y en la ruta que hayamos definido que se creen.
Figura 40. Generación de los objetos GeneXus a clases en el lenguaje para el que generemos la app.
- Por último, se produce la compilación de las clases que ha generado anteriormente.
Figura 41. Compilación de las clases generadas por GeneXus.
El siguiente paso para ver nuestra aplicación corriendo es ejecutarla,
Figura 42. Ejecutando la aplicación 1 ►.
La página principal que genera GeneXus por defecto contiene todos los objetos creados en
la base de conocimiento. Se llama Developer Menu.

Figura 43. Ejecutando la aplicación 2 ►.
Si vamos a abrir el objeto Pedido, que es con el que estábamos desarrollando el ejemplo, nos
encontramos lo siguiente:
Figura 44. Ejecutando la aplicación 3 ►. Web Form creado para la transacción Pedido.
Aunque acceder directamente al web form que se genera en la transacción no sigue la

navegación normal creada en nuestra aplicación y los datos que aparecen no tienen sentido si no

accedemos a través del Menú principal, nos sirve para ver cómo crea GeneXus la estructura de
los formularios web y los botones que implementa automáticamente junto a los procedimientos
asociados para que se realicen las acciones correspondientes en cada botón.
2.2.2. Microsoft SQL Server (servidor BBDD)
El gestor de base de datos que vamos a utilizar en nuestra aplicación es Microsoft SQL Server
2012, con las versiones de los componentes que lo conforman que indicamos en la siguiente tabla:
Nombre del componente Versión

Microsoft SQL Server Management Studio 11.0.2100.60
Microsoft Data Access Components (MDAC) 10.0.17134.1
Microsoft MSXML 3.0 6.0
Microsoft Internet Explorer 9.11.17134.0
Microsoft .NET Framework 4.0.30319.42000
Sistema operativo 6.3.17134
Tabla 6. Versión de instalación de los componentes asociados al SQL Server que utilizaremos en la app.
Funcionaremos con un servidor localhost, con la siguiente configuración:
Figura 45. Propiedades de conexión de la base de datos utilizada por la app.

Para que la aplicación funcione bien, en GeneXus debemos apuntar a dicha conexión, y en
concreto a la base de datos que va a contener la información de nuestro desarrollo. En nuestro
caso la hemos llamado tpvweb2. Esto se hace dentro de las Propiedades de nuestro proyecto:
Figura 46. Configuración de la base de datos en GeneXus.
A diferencia de la base de datos que crea GeneXus automáticamente con información de la

base de conocimiento (como vimos en el apartado 2.2.1.3.), es importante decir, que esta base de
datos sí que es con la que va a trabajar nuestra aplicación.
Es decir, dentro de tpvweb2 tenemos guardada en tablas de datos la información que cuando
la aplicación está corriendo consultamos, grabamos, eliminamos y modificamos continuamente.
También contiene tablas paramétricas, por ejemplo, para guardar la información de los
productos de la carta, o el número de mesas que tenemos.

2.3. Conexión entre GeneXus y un sistema DAQ
Existe una extensa gama de sistemas informáticos que obtienen su información directamente
del mundo real, a partir de dispositivos que recaban la información de un evento físico. Esta
información la digitalizan, la envían al ordenador y luego el software se encarga de su
procesamiento. Los sistemas que capturan datos por sí mismos se llaman genéricamente Sistemas
de Adquisición de Datos (DAQ), y un ejemplo de ello es nuestro dispositivo Leap Motion.
Los fabricantes de este tipo de sistemas generalmente proveen una API para poder acceder a
estos dispositivos desde nuestro lenguaje de programación. Esta API puede ser una DLL, una
clase Java o un wrapper para otros lenguajes como Python, Visual Basic, etc. En el caso de Leap,
su API es tan completa que dependiendo del lenguaje que vayamos a utilizar se proporciona o
bien una DLL o bien clases Java.
A partir de la versión X Evolution 1, se puede usar perfectamente a GeneXus como lenguaje

para desarrollar este tipo de aplicaciones y aprovechar las ventajas que tiene frente a los lenguajes
convencionales.
El recurso técnico de la creación de Objetos Externos nos permite interactuar con la API que
nos provee el fabricante de interfases de adquisición de datos y usar GeneXus para leer
información de eventos físicos o para controlar procesos. Dado que la mayoría de estos fabricantes
de hardware de DAQ provee una DLL o una clase Java, podemos importar estas funciones y
utilizar el objeto externo para acceder a los comandos que controlan los puertos de entrada y
salida, analógicos o digitales, más otros recursos que estas interfases multi-propósito
normalmente tienen, como temporizadores y contadores internos.
Además, usando GeneXus X Evolution 2 podemos generar aplicaciones que se ejecuten en

modo nativo en smart devices Android, Blackberry y Apple (iPhone y iPad). Esto potencia las
posibilidades, dado que podemos controlar dispositivos físicos de forma remota, por ejemplo, en
aplicaciones domóticas, como encender una lámpara, un aire acondicionado o un
electrodoméstico, pero también en control de procesos industriales, entre otros.
2.3.1. Importación de los objetos de la API de Leap Motion desde

GeneXus
Como acabamos de comentar en el apartado 2.3., para interactuar a través de GeneXus con
sistemas DAQ debemos hacerlo a través de los llamados Objetos Externos (External Objects,
EO).

El EO permite incluir en la propia KB la definición de esos programas externos (web service u

objetos nativos del lenguaje, DLL, clases Java, etc) importándolos utilizando un “Inspector”. De
este modo, la definición de esos objetos y cómo utilizarlos (propiedades, métodos, etc) queda
disponible y fácilmente utilizable.
Figura 47. Objetos Externos importados a la KB.
El proceso para incluir un programa externo dentro de una base de conocimiento consta de dos
partes:
• Un inspector que muestra las definiciones de los objetos a importar.

• Creación del objeto GeneXus con toda la información necesaria del mismo.
Cabe destacar, que la existencia de este objeto donde se centraliza toda la información del
objeto externo, brinda una mayor facilidad y flexibilidad en la programación.
Por ejemplo, para importar el contenido DLL en C# (LeapCSharp.NET3.5.dll) de la API que

nos proporciona el fabricante de Leap Motion…
1. En GeneXus, vamos a Tools → Application Integration → .Net Assembly Import
Figura 48. Importación de una DLL utilizando Objetos Externos 1.

2. Nos aparece el inspector anteriormente mencionado. Le damos la ruta del archivo que nos
hemos descargado de https://developer.leapmotion.com para C# y damos Next.
3. Agregamos el prefijo con el que se crearán los nombres de los objetos y la carpeta de la
KB donde se generarán.

4. Nos trae todas las clases y métodos que contiene la DLL que nos hemos descargado. Los
marcamos todos y los importamos.
Cuando se produce la importación, en

el árbol de carpetas de nuestra KB,
vemos como GeneXus nos ha creado una
carpeta con el nombre que le hemos
dicho (APILeap) dentro de la carpeta de
Objetos.

Dicha carpeta APILeap contiene X objetos externos, uno por cada método o clase importado
desde la DLL de Leap.
5. Ejemplo de objeto externo creado mediante la importación de un método que contiene una
biblioteca de una aplicación externa. Elegimos un objeto conocido como es Finger,
analizado en el apartado 2.1.3.3.
Figura 54. Objeto Externo creado a partir de la importación del método Finger desde la API Leap Motion.

3. EL SISTEMA TPV
Una vez introducido todo el marco teórico que influye en este proyecto, vamos a centrarnos
en describir nuestra aplicación y la manera en la que esta se ha desarrollado.
3.1. Prototipo de la aplicación original (v.0.1.)
El formato que vamos a seguir para describir nuestro prototipo de sistema TPV va a ser
separando por partes cada funcionalidad de nuestra aplicación. Por cada parte, analizaremos:
- La interfaz y su funcionalidad.
- Qué tipo de objetos GX intervienen en la creación de dicha interfaz y pequeña
descripción de su labor dentro de esta.
- Si estos objetos están relacionados con alguna tabla en base de datos.
3.1.1. El Developer Menu de GX
Como ya vimos en el apartado 2.2.1.5., cuando GX nos genera una aplicación web, lo
primero que vemos cuando abre el navegador es el Developer Menu (Figura 43).
Se trata de una página principal que GX nos crea por defecto, y que contiene todos los
principales objetos que él entiende que conforman la aplicación, de forma que podemos abrir
cualquiera de ellos (para ver su estructura, por ejemplo) sin necesidad de seguir el flujo lógico
que debe seguir dicha aplicación para su correcto funcionamiento.
En nuestro caso, como generamos para C# y .NET, GX muestra todos los objetos .aspx que
ha creado automáticamente (Figura 43) a raíz de toda la información que hemos introducido en
forma de objetos en la KB de nuestro sistema TPV.
Para seguir un orden lógico de funcionamiento, nuestra aplicación debe abrir como Menú
raíz la clase “Inicio” (inicio.aspx).
Figura 55. Menú raíz de la aplicación que conforma el sistema TPV.

3.1.2. Inicio
Representado por inicio.aspx.
Figura 56. Menú raíz de la aplicación que conforma el sistema TPV (2).
La interfaz que conforma el Menú raíz se basa en mostrar los datos del restaurante a modo
de información, y la única acción que permite hacer al usuario es elegir el idioma con el que
quiere interactuar. Este prototipo solamente trabaja con el español, las otras banderas se
encuentran a modo de ejemplo de funcionamiento.
Para conformar la estructura de la interfaz, se han utilizado los siguientes objetos:
▪ La pantalla en sí es una MasterPage, que obtiene los datos del restaurante a partir de
la tabla de BBDD Empresa y los guarda en variables que son las que printeamos
con la distribución que se muestra.
▪ Las imágenes originales para mostrar los idiomas están contenidas en la carpeta
Resources de la KB, y se representan con atributos de tipo Imagen a través de un
control ContentPlaceHolder.
▪ La tabla Empresa se crea en GX y BBDD a partir de la transacción definida en GX
con el mismo nombre. Su estructura es la siguiente:
Figura 57. Estructura de la transacción Empresa en GX.
La estructura de las tablas generadas, tanto en GX como en base de datos, queda definida por
las siguientes figuras.

Figura 58. Tabla generada por GX a partir de la transacción Empresa.
Figura 59. Tabla impactada por GX en BBDD a partir de la tabla generada a partir de la transacción Empresa.
El proceso de creación de tablas automáticamente en BBDD por GX siempre se produce del

mismo modo (como ya vimos en el apartado 2.2.1.5.), por lo que de ahora en adelante, solamente
haremos referencia a la tabla de la que obtenemos los datos para cada caso.
Figura 60. Flujo de acciones GX desde que se crea un objeto tipo transacción hasta que lo vemos reflejado en
BBDD.
Solamente si es necesario, y para el buen seguimiento de algún caso concreto, entraremos a

ver la estructura de la transacción.

A continuación, separaremos en apartados distintos los 2 tipos de interfaz posibles según el

perfil que esté consultando nuestro sistema: cliente o empleado.
3.1.3. Interfaz de usuario: clientes
A esta interfaz tendrán acceso tanto los clientes como los empleados, por lo que ambos
podrán realizar las mismas acciones si nos encontramos dentro de esta serie de menús.
3.1.3.1. Menú principal
Representado por menuocarta.aspx con el botón de ADMINISTRAR invisible.
Figura 61. Interfaz del Menú principal para un perfil de cliente.
Desde esta interfaz es donde los clientes desde sus respectivas mesas realizarán por ellos
mismos sus pedidos, sin necesidad de estar presente la figura del camarero.
Esta pantalla es muy simple, ya que solamente se basa en la interacción con botones que nos
conducen a otras pantallas o envían notificaciones.
Su estructura es un objeto de tipo web panel, al que se le han añadido 7 botones con las
siguientes funcionalidades:
- MENÚ, que conduce a otra pantalla donde podremos elegir entre los menús disponibles
para tomar.
- CARTA, que conduce a otra pantalla con una serie de productos disponibles para tomar.
- Inicio, que vuelve al menú raíz del que hemos partido. Es decir, a la pantalla para elegir
un idioma cuando inicia la aplicación.
- Volver, para retroceder dentro de la misma interfaz al menú principal.
- Ocio, enfocado al entretenimiento del cliente durante la espera de su pedido. Ahora
mismo no tiene implementado nada, se encuentra a modo de prototipo.

- CAMARERO, que tampoco tiene implementación todavía, y que está enfocado a enviar
una notificación al camarero asignado a la mesa concreta que haga la llamada para que
acuda.
- ADMINISTRAR, que en modo cliente se encuentra invisible.
3.1.3.2. Eventos asociados a los botones del Menú principal
A continuación, describiremos las interfaces asociadas que aparecerán en cuanto hagamos

click en cada uno de los botones importantes no descritos anteriormente del Menú principal.
• Click en MENÚ
Representado por mainmenu.aspx.
Figura 62. Interfaz del MENÚ.
Esta interfaz es muy parecida a su predecesora, ya que se basa en un web panel y botones o
links para moverse a otras pantallas. La diferencia que existe en este caso, es que la lista de menús
disponibles es dinámica. Dichos menús están parametrizados en la tabla Menu, con lo cual, el
web panel carga los tipos en función de los registros que tenga dicha tabla cargados en BBDD.
Figura 63. Tabla paramétrica para los tipos de menús en BBDD.
Si hacemos click sobre cualquiera de los menús disponibles nos aparecen los distintos
platos que entran, los productos que contienen y sus precios. Por ejemplo, para el Menú del día:

Figura 64. Interfaz con los productos del Menú del día.
Para cualquier menú que elijamos, la página a la que nos va a llevar es la misma
(mainitemmenu.aspx?X, donde X = ID del menú que hayamos elegido en la tabla Menu). Lo que
muestre la tabla de productos que se carga dinámicamente dependerá de lo que tenga
parametrizado en la tabla MenuItem cada tipo de menú. A su vez, cada ID de Item tiene relación
con la tabla CategoriasMenu.
Es decir, en la Figura 63 se observa como cada tipo de Menú tiene un ID asignado. Cada vez
que elijo un tipo de menú, iré a la tabla MenuItem filtrando con ese mismo ID, y filtraré los ítems
que necesita tener ese menú. Por ejemplo, para el Menú del día ID = 31:
Figura 65. Contenido de la tabla MenuItem con MenuId = 31 (menú del día).

Le corresponden los ítems 2, 3, 4, 5, 6, 7, 8, 9 y 10. Si consultamos a qué corresponden esto

ítems en la tabla CategoríasMenu:
Figura 66. Contenido de la tabla CategoriasMenu.
Comprobamos en la Figura 64, que la tabla dinámica del web panel debería tener, al menos,
las categorías Primer Plato, Segundo Plato, Postres, Cafés y Bebidas. Coincide con lo mostrado.
En cuanto a los botones azules y verdes que nos encontramos dentro de la interfaz de los
registros por tipo de plato del menú (Figura 64), su funcionalidad es la siguiente:
▪ Botón COMPLEMENTOS
Lanza un evento que abre un pop-up en la pantalla, la cual nos permite elegir entre varias
guarniciones.
Figura 67. Pop-up COMPLEMENTOS del menú.
La lista de complementos se encuentra parametrizada en la tabla Complemento, y

dependiendo del tipo de plato que esté seleccionando, filtraré un tipo de complementos u otros.

Figura 68. Tabla que contiene la parametría de los productos clasificados como COMPLEMENTOS.
▪ Botón MODOS
Lanza un evento que abre un pop-up en la pantalla, la cual nos permite elegir entre varios
modos de preparar la comida.
Figura 69. Pop-up MODOS del menú.
Los modos disponibles también se encuentran parametrizados en una tabla, Modo, y

dependiendo del tipo de plato que esté seleccionando, filtraré unos tipos de modo u otros.

Figura 70. Tabla que contiene la parametría de los productos clasificados como MODOS.
▪ Botón AÑADIR
El botón AÑADIR se encarga de guardar en la lista del PEDIDO (parte derecha de la

pantalla) los productos del menú que vayamos eligiendo. De este modo, cada vez que elijamos un
plato, irá apareciendo en dicha lista (tabla dinámica).
Figura 71. PEDIDO con ítems añadidos.
Cada vez que se genera un registro dentro de la lista del pedido, se genera automáticamente
también un control X para poder eliminar un ítem si nos hemos equivocado y el producto no
debería de haber sido añadido.
Una vez que tenemos la lista del PEDIDO completa, con el botón AÑADIR se creará un
nuevo pedido en la sección de pedidos que más tarde veremos en la interfaz de empleado.

• Click en CARTA
Representado por menuinicio.aspx.
Figura 72. Categorías tradicionales que componen una carta.
Cuando elegimos una categoría, por ejemplo Bebidas, nos lleva a otro web panel con una
estructura y funcionalidad idénticas a la de los ítems por menú que hemos visto en el punto
anterior.
Figura 73. PEDIDO con ítems añadidos desde la carta.
3.1.4. Interfaz de usuario: empleados
Al contrario que pasaba con la serie de menús anteriores, a esta interfaz solamente podrán
acceder los usuarios que tengan un perfil de empleado.
3.1.4.1 Menú principal
Representado por menuocarta.aspx con el botón de ADMINISTRAR visible.

Figura 74. Interfaz del Menú principal para un perfil de empleado.
Como ya hemos comentado, el empleado podrá realizar las mismas funciones que un perfil
de cliente dentro de la interfaz de menús y carta. La diferencia viene dada por el botón
ADMINISTRAR, cuyas funcionalidades disponibles describiremos en el siguiente apartado.
3.1.4.2. Funciones de administrador
Esta interfaz para empleados la forman un grupo de 9 pestañas, donde cada una de estas se
representa a través de un objeto web panel distinto.
Figura 75. Interfaz del modo ADMINISTRAR para perfiles de empleado.
Básicamente, la funcionalidad de las pestañas de basa en un mantenimiento de la información

que luego mostramos en la carta y el menú; así como del número de mesas, pedidos realizados o
datos del restaurante.
Dicha información está contenida en tablas paramétricas, algunas ya vistas en apartados

anteriores, sobre las cuales el usuario puede insertar, modificar o eliminar registros desde el web
panel.
Lo que contiene el web panel es, de nuevo, una tabla que se modifica dinámicamente
cargando más o menos filas en función de los datos que se encuentran grabados en BBDD sobre
las tablas paramétricas.
Analizando la funcionalidad para cada pestaña…
▪ Pestaña 1: MENÚS
Representado por wwmenu.aspx (Figura 75).
Esta pestaña básicamente trabaja con lo explicado, sobre una tabla dinámica sobre la que va
cargando información de registros que encuentra en BBDD. La tabla a la que corresponde la
información es Menú (Figura 63).
Añadido, se integra en el web panel un textbox que hace funciones de filtro, para buscar un
menú dentro de la lista dinámica (por nombre).
Como se puede observar en la figura 75, el usuario tendrá un botón (verde) para agregar un
menú nuevo (acción INSERT en BBDD); y sobre cada registro menú ya existente, dos botones
más: uno para modificar la información sobre este (acción UPDATE en BBDD) y otro para
eliminarlo (acción DELETE en BBDD). Esto lo encontraremos en TODAS LAS PESTAÑAS.
▪ Pestaña 2: PEDIDOS
Representado por wwpedido.aspx.
Figura 76. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña PEDIDOS.
De nuevo, el web panel está formado por una tabla dinámica, pero en este caso no se limita
únicamente a leer y representar la información desde tablas en BBDD, si no que también es capaz
de interpretar el estado de la comanda para asignar un color a la fila, e incorpora botones que
realizan acciones sobre el registro concreto del pedido leído.

- Botón columna Mantenimiento
- Botón columna Retornar
- Botones columna Atender
o Estado inicial , cada vez que se crea un pedido y todavía no ha sido

atendido ni está caducado.
o Estado en curso , cada vez que el usuario actualiza un pedido en

estado “Inicial”.
o Estado Completado , cada vez que el usuario actualiza un pedido en

estado “En curso”.
o Estado caducado, cuando un pedido no se atiende en menos de 1h. El color

del registro será NEGRO. La columna “Espera” es la encargada de controlar
la caducidad, ya que su función es calcular el tiempo que va transcurriendo
desde que se crea el pedido hasta que se despacha.
Todas estas acciones sobre los botones son entendidos como un UPDATE en la tabla de
datos BBDD que representa al pedido, “Pedido”,
Figura 77. Tabla “Pedido” en BBDD.
excepto el botón de la columna de Mantenimiento, que redirecciona hacia otro web panel
que nos permite modificar un pedido.

Figura 78. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña PEDIDOS, botón Mantenimiento.
Como se puede ver en la figura 76, la pestaña PEDIDOS también cuenta con dos objetos que
representan filtros.
- Uno de ellos es de tipo combo box, para filtrar por estado del pedido.
Figura 79. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña PEDIDOS, filtro Estado.
- El otro es a través de un calendario, para filtrar por fecha de pedido.
Figura 80. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña PEDIDOS, filtro Fecha.
▪ Pestaña 3: ITEMS
Representado por wwitem.aspx.

Figura 81. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña ITEMS.
De nuevo, volvemos a estar frente a un web panel que contiene una tabla dinámica que carga
líneas en función de lo que encuentra en la tabla de BBDD que lee. En este caso, la tabla base que
recorre es “Item”.
Figura 82. Tabla “Item” en BBDD.
En este caso, también encontramos 3 filtros disponibles.
- Uno corresponde a un textbox para buscar por nombre del ítem.

- Otro es un combo box para buscar por la categoría en la que está clasificado un ítem.
- Y por último, otro combo box para filtrar por la categoría que tiene el producto dentro
de un menú.

▪ Pestaña 4: CATEGORÍAS
La pestaña CATEGORÍAS se divide en dos posibles interfaces.
1. Interfaz de Categorías Carta.
Representado por wwtip.aspx.
Figura 83. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña CATEGORIAS, Carta.
2. Interfaz de Categorías Menú
Representado por wwcategorias.aspx.
Figura 84. Interfaz del modo ADMINISTRAR para perfiles de empleado. Pestaña CATEGORIAS, Menu.
Como se puede observar, ambas contienen los mismos tipos de objetos, los cuales, de nuevo
como en casos anteriores se basan en una tabla dinámica que extrae las líneas de los registros que
encuentra en las tablas base en BBDD y un filtro a través de un textbox.
▪ Pestañas 5, 6, 7, 8, 9: COMPONENTES, MODOS, COMPLEMENTOS, MESAS,

ADMINISTRAR DATOS
Todas las pestañas que siguen tienen exactamente la misma estructura y composición de
componentes que las dos de la pestaña CATEGORÍAS. Solamente cambia la tabla base a la que
van a buscar datos en la BBDD y la implementación de los filtros para cada caso.

4. EL SISTEMA TPV CON LEAP MOTION INTEGRADO
En este apartado explicaremos nuestras primeras experiencias con Leap, cómo nos
familiarizamos con el tratamiento a nivel de código con los objetos que maneja la API y cuáles
son sus posibilidades para hacer uso de ellas y aprovecharlas al máximo de cara al futuro; ya sea
mejorando el presente proyecto, o usándolas para otro tipo de aplicaciones. Además, analizaremos
el procedimiento para la integración de Leap con nuestra aplicación TPV.
4.1. Primeros pasos con Leap
Nuestros primeros pasos se basaron en cómo conectarse al controlador Leap Motion y acceder
a los datos básicos de seguimiento, tales que: nº de frames que ha detectado hasta ahora, el tiempo
que ha estado activo o las manos que aparecen en un momento dado en la pantalla, etc.
Para ello, lo que hicimos fue empezar a trabajar con un ejemplo ‘Hola Mundo’ que nos facilitan
en la web oficial de desarrolladores. Básicamente, lo único que hay que tener en cuenta para que
empiece a funcionar es lo siguiente:
• Descargar el último SDK (DeveloperKit) disponible para el lenguaje que

vayamos a usar. Esto es importante, ya que durante el proceso de desarrollo de este
proyecto han ido apareciendo varias versiones nuevas, y eso ha hecho que tengamos
algún problema a la hora de cambiar la forma de tratar los objetos o la conexión que
hacemos con el dispositivo. También hay que tener en cuenta que cada vez que aparece
una actualización también hay una modificación de la documentación principal, por
lo que cuando estemos consultándola hay que tener mucho cuidado para elegir la
versión correcta. La versión que nosotros utilizamos es la 3.2.1.
• Tener un compilador instalado. En nuestro caso, como ya teníamos Visual Studio
2012 instalado, no tuvimos que hacer nada.
• Asegurarnos de que Leap se conecta correctamente a nuestro ordenador. Esto es
importante, ya que cuando no ocurre el compilador nos devolverá un error.
Para asegurarnos de que la conexión está OK, podemos

consultar el Device Status en la app del Panel de Control que se
nos instala con el setup que nos proporcionan.
Figura 85. Panel de Control de Leap Motion → Resolución de problemas →

Device Status

• Las clases que generemos y las librerías correspondientes que nos proporcionan
deben estar en la misma ruta. Si no es así, la compilación funcionará, pero la
ejecución posterior no será buena. En el caso de la versión 3, las librerías que
necesitamos son Leap.dll y LeapC.dll.
Dadas las pautas básicas anteriores, vamos a empezar a probar.
4.1.1. Ejecutando por primera vez… ‘Hola Mundo’
Para ejecutar el ejemplo dado, y en general, cualquier clase implementada que queramos
probar, seguiremos los pasos que se enumeran a continuación.
1. Abrimos el Símbolo de Sistema, y navegamos a la ruta donde tenemos las clases a

compilar. En nuestro caso,
cd C:\LeapDeveloperKit_3.2.1_win\LeapDeveloperKit_3.2.1+45911_win\LeapSDK\samples
Figura 86. Ejecutando por primera vez… (1)
2. Para compilar, ejecutamos la siguiente sentencia:
csc /platform:x64 /target:exe Sample2.cs ..\src\*.cs Sample2.cs
Sample2.cs es nuestra clase a compilar. Ojo, porque el ejemplo es para nuestro caso. Para
cualquier otro, habrá que tener en cuenta la plataforma del sistema (x32, x64, x86,…) el formato
de salida de la clase compilada y el nombre de esta, que será diferente en cada caso.

3. Vamos a la carpeta de generación a buscar la aplicación .exe generada y la ejecutamos.
Como se puede observar, es una aplicación muy básica, que lo que hace es obtener información
acerca de cuántos frames lleva capturados ya el dispositivo y en cuánto tiempo. Además, nos
proporciona información del número de manos que están visibles en ese momento.

En el momento que introducimos una mano dentro del campo de visión del sensor, la
apariencia de la aplicación cambia y aparece mucha más información acerca de la mano, los dedos
y el brazo capturados.
Si volvemos a quitar la(s) mano(s), la pantalla vuelve a tener el mismo formato que en la
Figura x anterior.
Como recordatorio, durante todo el proceso explicado, es muy importante que el dispositivo
esté conectado por USB y con el Device Status (visto en el apartado 4.1.) correcto para un buen
funcionamiento, tanto de ejecución de la aplicación como de compilación de clases y generación
previa de esta.
Si por lo que sea Leap Motion no consiguiese iniciar automáticamente cuando es conectado,
en Windows se puede forzar a mano iniciando el Servicio que usa de la siguiente forma:
1. Abrimos la configuración de los Servicios de Windows,
Si no la encontramos a través del Menú de Windows, se puede acceder a través del ejecutador
(Ejecutar / Run) de la siguiente manera:

2. Una vez dentro de los Servicios, buscamos el de Leap y lo iniciamos a mano.
Realizando estos pasos ya nos debería quedar conectado. Lo podemos comprobar a través del
Device Status (como ya hemos comentado, en la aplicación Leap Motion Control Panel) o
simplemente comprobando el color verdecito del dispositivo conectado en la barra de
herramientas de Windows:
4.1.2. Avanzando un poco más… ‘Hola Mundo’ “casero”
Dado que la aplicación de ejemplo se ejecuta a través de la “pantalla negra”, resulta bastante
difícil seguir la información de los datos de los gestos que nos va devolviendo Leap.
Para resolverlo, vamos a crear un proyecto en Visual Studio 2012, y a aplicar más o menos las
mismas funcionalidades, pero dentro de un marco de aplicación más real y sobre todo más visual.

4.1.2.1 Configuración de Visual Studio 2012 para el uso de Leap
1. Empezamos, como hemos dicho, creando un nuevo proyecto en VS2012, de tipo C#

Aplicación de Windows Form.
Figura 94. Montando la primera app con Visual Studio (1)
2. Agregamos como referencia la librería LeapCSharp.NET4.5.dll que encontramos en la

carpeta “lib” del DeveloperKit descargado para C#.

Si no las tenemos ya cargadas, deberemos buscarlas a través del botón Examinar.
3. Una vez tenemos las librerías cargadas como Referencia, vamos a modificar las
propiedades del proyecto. Para eso, hacemos click derecho sobre el nombre de este en el
Menú de la derecha,
y seleccionamos Propiedades. En nuestro caso, dentro de la pestaña Compilar, deberemos

modificar el Destino de la plataforma a x64

y para todos los casos, dentro de la pestaña Eventos de compilación, añadir la siguiente
sentencia al textbox de la Línea de comandos del evento posterior a la compilación:
xcopy /yr "$(LEAP_SDK)\lib\x64\LeapC.dll" "$(TargetDir)"
de manera que quede de la siguiente forma:
La ruta que debemos escribir para sustituir el literal “$(LEAP_SDK)\lib\x64\” es la que

contenga la librería que usa el comando, en este caso LeapC.dll.
Al igual que pasaba con el caso del apartado 4.1.1. ejecutando desde la consola, usando
VS2012 también es necesario que Leap Motion esté conectado al ordenador para que la
compilación funcione correctamente.
De lo contrario, nos aparecerá un error tal que la figura siguiente:
Como se puede observar, el error viene dado por el comando del evento que hemos introducido
como requisito para que haga posterior a la compilación.

4.1.2.2 “Implementando que es gerundio”
Una vez tenemos el controlador instalado y funcional dentro del entorno de desarrollo VS2012,
empezamos a crear nuestra propia versión del “Hola Mundo”. El objetivo es conseguir una
aplicación similar a la dada, pero pudiendo ver con claridad y de forma ordenada la información
que nos devuelve el sensor cuando realizamos un gesto. En otras palabras, conseguir tener el
control de lo que se está ejecutando en cada momento.
• Caso 1
Para ello, sobre el código del Form1 que se nos ha generado al guardar el proyecto nuevo que
hemos creado en el punto 4.1.2.1., hemos implementado un programa (código disponible en el
anexo 7.2.) para que el controlador nos devuelva la siguiente información:
• ID frame.
• Tiempo total que ha estado activo el sensor.
• Los FPS que estamos captando.
• El nº de manos dentro del campo de visión del sensor.
• Un objeto PictureBox definido con un bitmap, y que muestra la imagen que estamos
capturando.
La estructura del Form1 para el primer caso de prueba mencionado queda de la siguiente
manera:
Figura 101. Ejecutando nuestro propio ‘Hola Mundo’. Caso 1. (1)
La estructura del programa consta principalmente de 3 funciones. Las describimos.

• Función 1: a partir de un nuevo objeto Frame, obtenemos la información frame.Id,

frame.Timestamp, frame.CurrentFramesPerSecond y frame.Hands.Count.
Como se intuye, estas son las que representamos en el Form1, por lo que igualamos
esos campos a las variables que hemos definido para dicho Form.
• Función 2: definimos el bitmap que mostrará la imagen capturada, y lo igualamos a
la imagen recogida del controlador imagedata.
• Función 3: la tercera es una función pública que recoge todo lo anterior.
El resultado obtenido tras compilar y ejecutarse la aplicación ha sido el siguiente:

• Caso 2
Para generar el Caso 2, hemos aprovechado el código del Caso 1 sobre el que hemos añadido
más líneas (código disponible en el anexo 7.3.). La información que hemos añadido sirve para
obtener datos sobre los siguientes campos, además de los que ya teníamos:
Hemos reutilizado las mismas funciones del caso anterior. La única que ha sido modificada es
la “madre”, de donde sacamos información a partir del Frame. El resultado obtenido tras compilar
y ejecutarse la aplicación ha sido el siguiente:
Como obtenemos los datos a partir de Controller, dicha información de las manos y dedos
pertenecerá al último frame detectado hasta el momento.

Si quisiéramos obtener la información para todos los frames detectados, tendríamos que
obtener la información a partir de un objeto Listener (como ya vimos en el apartado 2.1.3.5.). A
nivel desarrollo, la primera versión del ‘Hola Mundo’ que nos proporcionan en la web oficial
(visto en el apartado 4.1.1.) es un buen ejemplo (código disponible en el anexo 7.1.).
Vamos a hacer un análisis de los resultados obtenidos para cada caso de prueba planteado a
continuación.
4.1.2.3 Haciendo trabajar al sensor: casos de prueba
Para comprobar que lo que hemos implementado funciona correctamente, nos hemos definido
una serie de casos de prueba donde veremos si realmente nuestro código hace lo que esperamos
en cada momento.
La definición de cada uno de estos casos de prueba se realiza teniendo en cuenta en todo
momento la estructura principal del programa y lo que se espera que esta nos muestre.
Dicha estructura es la del

Form con el que hemos estado
trabajando durante los últimos
apartados vistos.
Figura 107. Analizando los resultados obtenidos. Casos de prueba. (1)

• Caso de prueba 1
Objetivo: Comprobar que la información obtenida para una mano detectada es correcta.
Resultado:
✓ Nro. Manos
✓ ID mano
✓ Posición mano
 Nro. Dedos
✓ Inclinación (front / back)
✓ Inclinación (eje vertical)
✓ Inclinación eje horizontal
Comentarios y análisis de los resultados:
El único error detectado corresponde al nº de dedos visibles que cuenta Leap para una mano
detectada. Dicho “error” viene dado por la cuestión que ya hemos estado planteando durante toda
la memoria, cuando obtenemos la información de un frame lo podemos hacer a través de
Controller o de Listener (que también será un método de Controller).
En este caso, como hemos obtenido el campo a través de Controller, la información que
estamos recogiendo corresponde con el último frame detectado. Si quisiéramos estar
monitorizando cada cambio y recogiendo todos esos datos, tendríamos que hacer una
implementación usando el método Listener y asignando a Controller todos los eventos que va
devolviendo para que nos los muestre.
Dicho lo anterior, asumimos que nos enfrentamos a un error que tenemos controlado y que
no corresponde a un error de desarrollo en sí, sino del modo en el que la aplicación está definida
para recoger la información.
En cuanto a las pruebas para validar los distintos tipos de inclinación, se han basado en mover
la mano por cada eje afectado, en las dos direcciones de las que recogemos información.
Figura 108. Analizando los resultados obtenidos. Casos de prueba. (2). Inclinación mano (front / back)

Figura 109. Analizando los resultados obtenidos. Casos de prueba. (3). Inclinación mano (eje vertical)
Figura 110. Analizando los resultados obtenidos. Casos de prueba. (4). Inclinación mano (eje horizontal)
Objetivo: Comprobar que la información obtenida para un brazo detectado es correcta.
Resultado:
✓ Dirección
✓ Pos. Muñeca
✓ Pos. Codo
En este caso, todos los datos obtenidos han sido satisfactorios.
Figura 111. Analizando los resultados obtenidos. Casos de prueba. (5). Dirección brazo.

Figura 112. Analizando los resultados obtenidos. Casos de prueba. (6). Posición de la muñeca.
Figura 113. Analizando los resultados obtenidos. Casos de prueba. (7). Posición del codo.
Objetivo: Comprobar que la información obtenida para una lista de dedos detectados es
correcta.
Resultado:
✓  ID dedo
✓  Tipo dedo
✓  Largo
✓  Ancho
✓  Dedo extendido
Como era de esperar, todos los datos obtenidos y que correspondan con información de los
dedos van a estar afectados por el mismo error que hemos detectado en el caso de prueba 1. Es
decir, estamos obteniendo siempre la información del último dedo leído dentro del frame, que en
este caso siempre es el meñique.
En cualquier caso, la información obtenida es correcta, aunque solamente corresponda a un

dedo en concreto en el momento que accedemos a los datos a través de Controller.

Figura 114. Analizando los resultados obtenidos. Casos de prueba. (8). Información dedos.
4.2. Integración con el TPV
Una vez probado y vistas las capacidades que muestra nuestro sensor, vamos a analizar de qué
formas se podría implementar su funcionalidad dentro del sistema TPV. También elegiremos la
que -a priori- será la mejor de ellas, siempre respecto al hipotético modo de funcionamiento del
sistema planteado.
4.2.1. Funcionalidades gestuales requeridas por el TPV
Para analizar el “cómo”, primero debemos plantear el “qué”. En este apartado vamos a definir
una serie de requisitos de control gestual que nuestro TPV deberá tener.
Dado que este proyecto está enfocado al uso de Leap desde la cocina, vamos a centrarnos en
definir acciones solamente sobre la parte de la aplicación que se vaya a usar desde dicho espacio.
Figura 115. Prototipo de interfaz para gestionar pedidos desde la cocina.

Dentro de nuestro prototipo del sistema TPV, la ventana principal con la que teóricamente se
trabajaría desde cocina será la que nos permite gestionar el estado de los pedidos, formada por la
interfaz que representa la figura anterior.
Vista la estructura con la que tendremos que interactuar, definimos una lista de un total de 6
gestos para implementar usando los recursos que nos proporciona Leap.
1. Funcionalidad “click”, que deberá poder realizarse para cada componente que lo
permita normalmente (botones) dentro de esta interfaz, excepto para el desplegable del
filtro por “Estado” del pedido.
2. El filtro “Estado” unirá dos tipos de gestos para una misma funcionalidad: un gesto corto
y rápido hacia abajo para realizar el desplegado + un click para elegir la componente del
filtro que queremos utilizar.
3. Funcionalidad que nos permita arrastrar objetos para reubicarlos en otra zona de la
pantalla. Un ejemplo de esto sería poder intercambiar la posición que ocupan los pedidos,
de forma que los organicemos como mejor nos convenga.
4. Funcionalidad que nos permita hacer el paginado realizando un gesto de derecha a
izquierda o al contrario, dependiendo de hacia qué lado queremos paginar. Emulará la
tarea que hacen los botones de control de paginado.
5. Funcionalidad de despacho rápido de un pedido, que consistirá en hacer un gesto
rápido hacia la izquierda sobre el pedido concreto del cual queremos cambiar su estado.
Emulará la tarea del botón columna “Atender”.
6. Funcionalidad de cambio de estado de un pedido una vez que está despachado, que
consistirá en hacer un gesto rápido hacia la derecha sobre el pedido concreto para el que
queramos revertir el avance de su estado. Emulará la tarea del botón columna “Retornar”.
Analizaremos en el siguiente apartado cuáles son las posibles soluciones para cada modo de
funcionamiento planteado. En caso de que contemos con más de una posibilidad de
implementación para alguno de ellos, debatiremos entre todos los cómos y nos quedaremos con
la versión que consideremos la mejor para nuestro sistema TPV, teniendo en cuenta factores como
por ejemplo el rendimiento o la complejidad del desarrollo.
4.2.2. Propuestas de solución para cada funcionalidad gestual

planteada y a implementar sobre el sistema TPV
Vistos los requisitos gestuales con los que queremos que nuestra aplicación sea capaz de
trabajar, vamos a enumerar ahora una serie de posibles soluciones que podrían ser válidas y servir
de guía de cara a la implementación de código para la integración del sensor con el sistema.

1. Funcionalidad 1. Evento “click”.
Si hacemos memoria, en el apartado 2.1.3.6. vimos que la API de Leap Motion incluía por
defecto 4 objetos que emulaban tipos de gestos. Uno de ellos es ScreenTapGesture, que si
recordamos, era el que representaba un click sobre la pantalla.
Dicho objeto cuenta con una serie de funciones públicas que nos devuelven información sobre
el movimiento detectado y que se pueden usar. Para nuestro caso concreto, la información que
necesitamos obtener a través de este objeto es la siguiente:
• El frame que contiene el evento del gesto que se acaba de producir. Objeto tipo Frame.
• Lista de manos asociada al gesto, objeto tipo HandList.
A través del objeto HandList se puede acceder a toda la información respecto a los dedos que
han realizado el gesto, que en nuestro caso controlaremos que solamente lo pueda hacer el dedo
índice.
• El sitio exacto de la pantalla donde se ha producido el gesto, mediante el objeto de

tipo Pointable. Esto nos sirve para saber a qué botón real de la aplicación debemos
asignar el evento, comparando coordenadas respecto a la posición del click con la del
botón dentro de la interfaz desarrollada.
2. Funcionalidad 2. Tratamiento del desplegable del filtro “Estado” del pedido.
La API de Leap también cuenta con un tipo de gesto que se llama KeyTapGesture, el cual
también ya comentamos en el apartado 2.1.3.6. En este caso, se representaba un desplazamiento
rápido y corto hacia abajo, por lo que nos sirve perfectamente para abrir el desplegable.
La información que necesitamos que devuelva KeyTap para que funcione correctamente es la
misma que para un evento click: el frame, la mano, el dedo concreto y la posición de la pantalla
donde se ha realizado el gesto. Todos ellos están disponibles y son perfectamente accesibles,
como en el caso anterior.
3. Funcionalidad 3. Arrastrar objetos.
Dado que Leap no tiene ninguna función predefinida para hacer movimientos en vertical, en
este caso lo tenemos más complicado.
Lo que planteamos para generar este tipo de gesto es, mediante los datos de posición de la
mano y los dedos que se nos proporciona durante el rastreo, generar un algoritmo que nos permita
reconocer cuándo la mano se mueve en el eje vertical (da igual el sentido). También, usando los
datos de su posición inicial y final, para saber desde dónde y hasta dónde tiene que moverse el

objeto. Añadido, tendremos que comparar la posición de la mano con la del objeto dentro de la
lista de pedidos para identificar cuál es que queremos mover.
Como no tenemos ningún movimiento más que vaya a necesitar de este eje (a excepto de
KeyTap, pero este ya es reconocido por Leap de forma automática) nos debería facilitar la
casuística a la hora de implementar este algoritmo. Si en un futuro queremos implementar otro
tipo de gesto que utilice directamente el eje vertical, tendríamos que afinar mucho más en qué
caso estamos y qué condiciones y particularidades de movimiento tiene cada uno para que puedan
ser reconocidos correctamente y no haya confusión entre gestos.
4. Funcionalidad 4. Realizar el paginado.
Para realizar el paginado podríamos pensar que la implementación debe ser la misma que para
el caso anterior, pero sobre el eje horizontal y sin tener en cuenta posiciones inicial y final, porque
no las requerimos. Se podría implementar creando un algoritmo así, pero por suerte la API de
Leap sí que cuenta con un objeto reconocible para detectar gestos de este tipo.
Es SwipeGesture, que haciendo memoria, representa un deslizamiento sobre la pantalla. Con

detectar hacia qué dirección se dirige (derecha o izquierda, mediante el vector direction() que usa)
y comprobando que es en el eje horizontal, tendríamos suficiente para lanzar el evento que le
corresponda al botón de paginado.
5. Funcionalidades 5 y 6. Actualización rápida del estado de un pedido.
Para realizar este gesto podríamos pensar que nos vale el que ya incluye la API y ya hemos
visto anteriormente, KeyTap, pero en este caso deberemos tener en cuenta muchos más factores
además de la información que este método nos proporciona.
Por ejemplo, tenemos que saber sobre qué pedido estamos actuando, por lo que necesitamos
comparar las posiciones de nuestro dedo y el objeto por el que el pedido está representado en la
interfaz para saber a qué comanda afectamos.
Además, también debemos tener presente la dirección hacia la que se está realizando el gesto
(izquierda o derecha), ya que en función del lado al que se dirija se lanzará un evento u otro
(avanzar o retroceder el estado del pedido).
Sobre la API…
Todos los gestos mencionados y reconocidos en la API están contenidos en una estructura de
datos tipo Enum en la librería “LeapC.dll”, dentro de la clase “Gestures”. Dicha estructura puede
ser de dos tipos: Type o State.

• Las estructuras tipo Type recogen información sobre los tipos de gestos, que como ya
hemos visto, son los siguientes:
- TYPE_INVALID
- TYPE_SWIPE
- TYPE_CIRCLE
- TYPE_SCREEN_TAP
- TYPE_KEY_TAP
• Las estructuras tipo State recogen información acerca de los posibles tipos de estado en los
que se pueden encontrar los gestos. Por cada gesto, tenemos 4 estados posibles:
- STATE_INVALID
- STATE_START
- STATE_UPDATE
- STATE_STOP
En cuanto al funcionamiento general, nuestra aplicación almacenará los datos de los tipos de
gestos que usa, para que al realizar un movimiento compare con los gestos que ya tenemos
registrados.
Si se reconoce el movimiento, se lanza un evento que captura la aplicación; y, dependiendo

del gesto, se realiza una acción u otra.
En la siguiente figura se explica el procedimiento que se realiza:
Figura 116. Condiciones para el lanzamiento de eventos.
Cuando se graban los gestos, se tendrán que almacenar los datos en algún fichero de tipo
JSON, BVH, XML o CSV con un formato predeterminado, para posteriormente poder ser
reconocidos fácilmente desde dentro de nuestra aplicación según la estructura definida.

Como nuestro TPV tiene un formato web, el fichero que contenga los gestos será de tipo JSON.
Su formato predeterminado (tracking data) debe seguir la estructura definida en el Anexo 7.4. de
esta memoria.

5. CONCLUSIONES Y FUTURAS MEJORAS
Con la elaboración de este proyecto se ha podido analizar la funcionalidad, capacidad y

alcance que puede llegar a tener el dispositivo Leap Motion en cualquier ámbito, no solamente en
la restauración.
Es un sensor poco conocido, pero que por su bajo precio y a su vez gran desempeño podría
estar funcionando en sistemas donde podría ser súper útil; como por ejemplo en la industria, donde
cada vez se usa más el tratamiento de imágenes para realizar funciones de cualquier tipo.
Mediante las diferentes pruebas realizadas con una parte de su extensa API, pudimos observar
que el sensor es intuitivo, funciona correctamente y cuenta con las validaciones suficientes para
evitar errores por parte de los usuarios.
Sinceramente, no entendemos cómo con los años que lleva comercializándose su uso no se
haya extendido más. A pesar de permitir casi todos los lenguajes de programación, suponemos
que la razón podría deberse a otro tipo de dispositivos todavía más baratos y potentes dentro del
mercado. Un ejemplo pueden ser las placas de Arduino, con las que se puede programar casi
cualquier cosa con un rendimiento brutal.
En cuanto a las mejoras que proponemos para nuestro prototipo de sistema, las
diferenciamos en dos tipos:
➢ Puntos pendientes, que incluyen las funcionalidades requeridas y que ya nacieron con
el prototipo inicial de la aplicación.
✓ Implementación real de la funcionalidad del sensor sobre la aplicación.
➢ Mejoras evolutivas, a nivel aplicación, haciendo uso de recursos que tenemos en nuestra
mano y que nos permitirían un mayor alcance comercial de nuestro TPV. Por ejemplo:
✓ Parte funcional con Leap más visual y mejora de la interfaz del sistema en general.
✓ Aprovechar las funcionalidades que presenta GeneXus, como por ejemplo la
facilidad de generar aplicaciones móviles a partir de la original en cualquier lenguaje.
✓ Comunicación con Mesas por IP.
✓ Sistema de perfiles. Funcionalidades habilitadas distintas dentro de la aplicación
para cada tipo de usuario logueado.

6. BIBLIOGRAFÍA Y REFERENCIAS
[1]. SparkFun start something, “Leap Motion Teardown”, «sparkfun». [En Línea].
Available: https://learn.sparkfun.com/tutorials/leap-motion-teardown/you-got-guts-
kid.
[2]. Image Sensors World, news and discussions about image sensors, «blogspot»
2013. [En Línea]. Available: http://image-sensors-
world.blogspot.com/2013/08/haptix-follows-leapmotion-steps.html.
[3]. Frank Weichert, Daniel Bachmann, Bartholomäus Rudak and Denis Fisseler
(2013). “Analysis of the Accuracy and Robustness of the Leap Motion Controller”.
[En Línea]. Available: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3690061/.
[4]. Almà, A. “Interacción 3D con Leap Motion”. inLab talent & tech, Centre d’Innovació
i Tecnologia de la Universitat Politècnica de Catalunya, «inLab» 2014. [En Línea].
Available: https://inlab.fib.upc.edu/es/blog/interaccion-3d-con-leap-motion.
[5]. Leap Motion / Developers, «Leap Motion» 2018. [En Línea]. Available:
https://developer-archive.leapmotion.com.
[6]. MTF Mapper, “A brief overview of lens distortion correction”, «blogspot» 2017. [En
Línea]. Available: http://mtfmapper.blogspot.com/2017/08/a-brief-overview-of-
lens-distortion.html.
[7]. López-Flores, Juan E. (2016). “Control por gestos usando Leap Motion”. Instituto
Tecnológico y de Estudios Superiores de Occidente. [En Línea]. Available:
https://rei.iteso.mx/bitstream/handle/11117/4079/TOG+Control+por+gestos+usan
do+Leap+Motion.pdf?sequence=3.
[8]. Laazizi Ruiz, K. (2014). “Desarrollo de un prototipo usando como dispositivo de
interacción Leap Motion”. Universidad Politécnica de Madrid. [En Línea]. Available:
http://oa.upm.es/30975/1/PFC_KARIM_LAAZIZI_RUIZ.pdf.
[9]. Akcasu, A. (2014). “Introduction to Programming the LeapMotion”. Interactive
Business Systems, Inc. «slideshare». [En Línea]. Available:
https://www.slideshare.net/IBS_corp/leap-motion-aydin-akcasu-ibs.
[10]. Tina Running Blog, “General Introduction to Leap Motion (Java) API AND Your first
JAVA program with Leap Motion API –“Hello world”. «wordpress» 2015. [En
Línea]. Available: https://xiaotingrunning.wordpress.com/2015/03/23/leap-motion-
tutorial-java2-general-introduction-and-hello-world/.
[11]. SHOWLEAP TECHNOLOGIES, Un proyecto pensado para cambiar el mundo,
2015. [En Línea]. Available: http://blog.showleap.com.

[12]. Tamarjan, D. (2013). “Leap Motion: Drawbacks and Potential Applications”.

Augmented Tomorrow. About augmented reality, new tech and humans. [En
Línea]. Available: http://augmentedtomorrow.com/drawbacks-applications-leap-
motion/.
[13]. Anónimo, GitHub, "Leap Motion for Processing", «github» 2013. [En Línea].
Available: https://github.com/Redacacia/leap-motion-processing-1.
[14]. Artech. Training GeneXus, «GeneXus» 2018. [En Línea]. Available:
https://training.genexus.com.
[15]. Artech. GeneXus Community Wiki, «GeneXus» 2018. [En Línea]. Available:
https://wiki.genexus.com.
[16]. Artech. GeneXus, «GeneXus» 2018. [En Línea]. Available:
https://www.genexus.com/es/
[17]. Leap Motion / Forums, «Leap Motion» 2018. [En Línea]. Available:
https://forums.leapmotion.com/.
[18]. Leap Motion, «Leap Motion» 2018. [En Línea]. Available:
https://www.leapmotion.com/.
[19]. Darren, L. (2015). YouTube, [C# Winform Leap], «youtube». [En Línea]. Available:
https://www.youtube.com/playlist?list=PLY_-
oT2VZL2NYtoL7ez1iAN_S2aLysoP3.
[20]. Roballo, R. (2011). “Usando GeneXus para leer sensores y controlar dispositivos”.
Artech. [En Línea]. Available: https://www.genexus.com/es/global/noticias/leer-
noticia/usando-genexus-para-leer-sensores-y-controlar-dispositivos.

7. ANEXOS
A continuación, se anexa una serie de información y funcionalidades que consideramos útiles

para el buen seguimiento y entendimiento durante la lectura de la presente memoria.
7.1. Ejemplo ‘Hola Mundo’ en C#
Referencia en el apartado 4.1.1.: Sample2.cs

/******************************************************************************\
* Copyright (C) 2012-2016 Leap Motion, Inc. All rights reserved. *
* Leap Motion proprietary and confidential. Not for distribution. *
* Use subject to the terms of the Leap Motion SDK Agreement available at *
* https://developer.leapmotion.com/sdk_agreement, or another agreement *
* between Leap Motion and you, your company or other organization. *
\******************************************************************************/
using System;
using System.Threading;
using Leap;
class Sample {
public static void Main() {
using (Leap.IController controller = new Leap.Controller()){

controller.SetPolicy(Leap.Controller.PolicyFlag.POLICY_ALLOW_PAUSE_RESUME);
// Set up our listener:

SampleListener listener = new SampleListener();
controller.Connect += listener.OnServiceConnect;
controller.Disconnect += listener.OnServiceDisconnect;
controller.FrameReady += listener.OnFrame;
controller.Device += listener.OnConnect;
controller.DeviceLost += listener.OnDisconnect;
controller.DeviceFailure += listener.OnDeviceFailure;
controller.LogMessage += listener.OnLogMessage;
// Keep this process running until Enter is pressed

Console.WriteLine("Press any key to quit...");
Console.ReadLine();
}
}
}
class SampleListener {
public void OnInit(Controller controller) {

Console.WriteLine("Initialized");
}
public void OnConnect(object sender, DeviceEventArgs args) {

Console.WriteLine("Connected");
}
public void OnDisconnect(object sender, DeviceEventArgs args) {

Console.WriteLine("Disconnected");
}

public void OnFrame(object sender, FrameEventArgs args) {

// Get the most recent frame and report some basic information
Frame frame = args.frame;
Console.WriteLine(
"Frame id: {0}, timestamp: {1}, hands: {2}",
frame.Id, frame.Timestamp, frame.Hands.Count
);
foreach (Hand hand in frame.Hands) {

Console.WriteLine(" Hand id: {0}, palm position: {1}, fingers: {2}",
hand.Id, hand.PalmPosition, hand.Fingers.Count);
// Get the hand's normal vector and direction
Vector normal = hand.PalmNormal;
Vector direction = hand.Direction;
// Calculate the hand's pitch, roll, and yaw angles

Console.WriteLine(
" Hand pitch: {0} degrees, roll: {1} degrees, yaw: {2} degrees",
direction.Pitch * 180.0f / (float)Math.PI,
normal.Roll * 180.0f / (float)Math.PI,
direction.Yaw * 180.0f / (float)Math.PI
);
// Get the Arm bone

Arm arm = hand.Arm;
Console.WriteLine(
" Arm direction: {0}, wrist position: {1}, elbow position: {2}",
arm.Direction, arm.WristPosition, arm.ElbowPosition
);
// Get fingers
foreach (Finger finger in hand.Fingers) {
Console.WriteLine(
" Finger id: {0}, {1}, length: {2}mm, width: {3}mm",
finger.Id,
finger.Type.ToString(),
finger.Length,
finger.Width
);
// Get finger bones

Bone bone;
for (int b = 0; b < 4; b++){
bone = finger.Bone((Bone.BoneType)b);
Console.WriteLine(
" Bone: {0}, start: {1}, end: {2}, direction: {3}",
bone.Type, bone.PrevJoint, bone.NextJoint, bone.Direction
);
}
}
}
if (frame.Hands.Count != 0){
Console.WriteLine("");
}
}
public void OnServiceConnect(object sender, ConnectionEventArgs args){

Console.WriteLine("Service Connected");
}

public void OnServiceDisconnect(object sender, ConnectionLostEventArgs args){

Console.WriteLine("Service Disconnected");
}
public void OnServiceChange(Controller controller){

Console.WriteLine("Service Changed");
}
public void OnDeviceFailure(object sender, DeviceFailureEventArgs args){

Console.WriteLine("Device Error");
Console.WriteLine(" PNP ID:" + args.DeviceSerialNumber);
Console.WriteLine(" Failure message:" + args.ErrorMessage);
}
public void OnLogMessage(object sender, LogEventArgs args){

switch (args.severity){
case Leap.MessageSeverity.MESSAGE_CRITICAL:
Console.WriteLine("[Critical]");
break;
case Leap.MessageSeverity.MESSAGE_WARNING:
Console.WriteLine("[Warning]");
break;
case Leap.MessageSeverity.MESSAGE_INFORMATION:
Console.WriteLine("[Info]");
break;
case Leap.MessageSeverity.MESSAGE_UNKNOWN:
Console.WriteLine("[Unknown]");
break;
}
Console.WriteLine("[{0}] {1}", args.timestamp, args.message);
}
}
//Para compilar:
/*csc /platform:x64 /target:exe Sample2.cs ..\src\*.cs Sample2.cs*/

7.2. Ejemplo ‘Hola Mundo’ mejorado en C# con VS2012. Caso 1.
Referencia en el apartado 4.1.2.2.: Form1.cs
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Drawing.Imaging;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using Leap;
namespace LeapMotionPrueba {
public partial class Form1 : Form {
private byte[] imagedata = new byte[1];

private Controller controller = new Controller();
Bitmap bitmap = new Bitmap(640, 480,
System.Drawing.Imaging.PixelFormat.Format8bppIndexed);
public Form1() {
InitializeComponent();
controller.EventContext = WindowsFormsSynchronizationContext.Current;
controller.FrameReady += newFrameHandler;
controller.ImageReady += onImageReady;
controller.ImageRequestFailed += onImageRequestFailed;
ColorPalette grayscale = bitmap.Palette;

for (int i = 0; i < 256; i++){
grayscale.Entries[i] = Color.FromArgb((int)255, i, i, i);
}
bitmap.Palette = grayscale;
}
void newFrameHandler(object sender, FrameEventArgs eventArgs) {

Frame frame = eventArgs.frame;
this.displayID.Text = frame.Id.ToString();
this.displayTimestamp.Text = frame.Timestamp.ToString();
this.displayFPS.Text = frame.CurrentFramesPerSecond.ToString();
this.displayNroManos.Text = frame.Hands.Count.ToString();
controller.RequestImages(frame.Id, Leap.Image.ImageType.DEFAULT,
imagedata);
}
void onImageRequestFailed (object sender, ImageRequestFailedEventArgs

error) {
if (error.reason ==
Leap.Image.RequestFailureReason.Insufficient_Buffer) {
imagedata = new byte[error.requiredBufferSize];
}
Console.WriteLine("Petición de imagen fallida: ", error.message);
}

void onImageReady(object sender, ImageEventArgs error){

Rectangle Area = new Rectangle(0, 0, bitmap.Width, bitmap.Height);
BitmapData bitmapData = bitmap.LockBits(Area,
ImageLockMode.WriteOnly, PixelFormat.Format8bppIndexed);
byte[] rawImageData = imagedata;
System.Runtime.InteropServices.Marshal.Copy(rawImageData, 0,
bitmapData.Scan0, error.image.Width * error.image.Height * 2 *
error.image.BytesPerPixel);
bitmap.UnlockBits(bitmapData);
displayImagen.Image = bitmap;
}
} // public partial class Form1

} //namespace LeapMotionPrueba

7.3. Ejemplo ‘Hola Mundo’ mejorado en C# con VS2012. Caso 2.
Referencia en el apartado 4.1.2.2.: Form1.cs función newFrameHandler.
void newFrameHandler(object sender, FrameEventArgs eventArgs) {
Frame frame = eventArgs.frame;

this.displayID.Text = frame.Id.ToString();
this.displayTimestamp.Text = frame.Timestamp.ToString();
this.displayFPS.Text = frame.CurrentFramesPerSecond.ToString();
this.displayNroManos.Text = frame.Hands.Count.ToString();
controller.RequestImages(frame.Id, Leap.Image.ImageType.DEFAULT,
imagedata);
//Caso 2 - I
foreach (Hand hand in frame.Hands){
this.displayHandID.Text = hand.Id.ToString();
this.displayPalmPosition.Text = hand.PalmPosition.ToString();
this.displayHandFingers.Text = hand.Fingers.Count.ToString();
Vector normal = hand.PalmNormal;

Vector direction = hand.Direction;
this.displayHandInclinacion.Text = (direction.Pitch * 180.0f /
(float)Math.PI).ToString();
this.displayHandInclinacionV.Text = (normal.Roll * 180.0f /
this.displayHandInclinacionH.Text = (direction.Yaw * 180.0f /
Arm arm = hand.Arm;

this.displayArmDireccion.Text = arm.Direction.ToString();
this.displayPosicionMunyeca.Text = arm.WristPosition.ToString();
this.displayPosicionCodo.Text = arm.ElbowPosition.ToString();
foreach (Finger finger in hand.Fingers){
this.displayFingerID.Text = finger.Id.ToString();
this.displayFingerTipo.Text = finger.Type.ToString();
this.displayFingerL.Text = finger.Length.ToString();
this.displayFingerA.Text = finger.Width.ToString();
this.displayFingerExt.Text = finger.IsExtended.ToString();
} //foreach (Finger)
} //foreach (Hand)
//Caso 2 - F
} // newFrameHandler

7.4. JSON tracking data format
Referencia en el apartado 4.2.2.
"currentFrameRate": float
"id": float
"r": array of floats (Matrix)
"s": float
"t": array of floats (vector)
"timestamp": integer
"devices": not implemented (always an empty array)
"gestures": array of Gesture objects
(Attributes vary by gesture type)
"center": array of floats (vector) -- circle only
"direction": array of floats (vector) -- swipe, keyTap, screenTap only
"duration": integer microseconds
"handIds": array of integers
"id": integer
"normal": array of floats -- circle only
"pointableIds": array
"position": array of floats (vector) -- swipe, keyTap, screenTap only
"progress": float -- circle, keyTap, screenTap only
"radius": float -- circle only
"speed": float -- swipe only
"startPosition": array of float (vector) -- swipe only
"state": string - one of "start", "update", "stop"
"type": string - one of "circle", "swipe", "keyTap", "screenTap"
"hands": array of Hand objects
"armBasis: the 3 basis vectors of the arm (array of vectors)
"armWidth: float
"confidence: float
"direction": array of floats (vector)
"elbow: array of floats (vector)
"grabStrength: float
"id": integer
"palmNormal": array of floats (vector)

"palmPosition": array of floats (vector)
"palmVelocity": array of floats (vector)
"pinchStrength: float
"r": array of floats (Matrix)
"s": float
"sphereCenter": array of floats (vector)
"sphereRadius": float
"stabilizedPalmPosition": array of floats (vector)
"t": array of floats (vector)
"timeVisible": float
"type": string - one of "right", "left"
"wrist: array of floats (vector)
"interactionBox": object
"center": array of floats (vector)
"size": array of floats (vector)
"pointables": array of Pointable objects
"bases": the 3 basis vectors for each bone, in index order, wrist to tip,
(array of vectors).
"btipPosition": the position of the tip of the distal phalanx as an array

of 3 floats.
"carpPosition": the position of the base of metacarpal bone as an array of

3 floats.
"dipPosition:" the position of the base of the distal phalanx as an array

of 3 floats.
"direction": array of floats (vector)
"extended": boolean (true or false)
"handId": integer
"id": integer
"length": float
"mcpPosition": a position vector as an array of 3 floating point numbers
"pipPosition": a position vector as an array of 3 floating point numbers
"stabilizedTipPosition": array of floats (vector)
"timeVisible": float
"tipPosition": array of floats (vector)
"tipVelocity": array of floats (vector)
"tool": boolean (true or false)

"touchDistance": float
"touchZone": string - one of "none", "hovering", "touching"
"type": integer - 0 is thumb; 4 is pinky
"width": float

Prototipado de Sistema TPV Controlado Con "Leap Motion"

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Prototipado de Sistema TPV Controlado Con "Leap Motion"

Diunggah oleh

Hak Cipta:

Format Tersedia

Prototipado de

Grado en Ingeniería en Sonido e Imagen

Trabajo Fin de Grado

- Por parte de Artech, GeneXus: Rodolfo Roballo y Rodrigo Álvarez.

Al primero, por certificarme, por enseñarme la base de un software totalmente

- A mi hermana Verónica, que después de un proyecto de fin de carrera, dos proyectos de

TRABAJO DE FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

3.1.3.1. Menú principal ................................................................................... 51

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

A continuación se presenta un listado de figuras utilizadas en esta memoria.

Figura 1. Caja registradora convencional vs sistema TPV....................................................... 8

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

Figura 87. Ejecutando por primera vez… (2) ........................................................................ 65

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

Listado de tablas a las que en esta memoria se hace referencia.

Tabla 1. Magnitudes físicas medidas por los sensores de Leap. ............................................ 19

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

LISTADO DE ABREVIATURAS, SIGLAS Y SÍMBOLOS

A continuación se presenta un listado de términos utilizados en esta memoria, junto a su

1. TFG: Trabajo de fin de Grado.

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

La evolución de los sistemas TPV (Terminal Punto de Venta) en el mundo de la restauración

1.1. ¿Qué es un Sistema TPV?

Figura 1. Caja registradora convencional vs sistema TPV (Fuente: www.holasoft.es)

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

1.1.1. Componentes de un sistema TPV

Por ejemplo, en un restaurante, además de la aplicación software y de la infraestructura de

En nuestro caso práctico-teórico, desarrollaremos nosotros mismos la aplicación (software) y

En un caso real de puesta en funcionamiento del sistema planteado en esta memoria,

1.2. Nacimiento de la propuesta de TFG

- En primer lugar, de la posibilidad de realizar un TFG utilizando la tecnología ‘Leap

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

1.3. Ideas generales y objetivos del proyecto

1.4. Fases del desarrollo del proyecto

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

2. METODOLOGÍA Y TECNOLOGÍAS UTILIZADAS

2.1. ‘Leap Motion’: el sensor de control gestual

Nuestro elemento protagonista es Leap, un diminuto dispositivo (80x30x12mm y apenas 80$)

Figura 2. Controlador ‘Leap Motion’. (Fuente: https://www.geek.com)

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

2.1.1. Partes físicas del dispositivo (hardware)

▪ CÁMARAS Y LEDS DE ILUMINACIÓN INFRARROJA

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

La configuración de los pines de este circuito integrado es la siguiente:

Figura 6. Configuración PIN del integrado MX25L3206E (Fuente: netcheif.com)

Toda la información de este dispositivo la podemos encontrar en la hoja técnica que

▪ PUERTOS DE ENVÍO Y RECEPCIÓN DE DATOS

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

2.1.2. Funcionamiento del controlador

Figura 9. Distorsión compleja o de mostacho. (Fuente: mtfmapper.blogspot.com)

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

2.1.3. Resumen de la API del sensor (v3.2.1_win)

El alcance efectivo se extiende desde aproximadamente 25 a 600 milímetros sobre el

El eje Z tiene valores positivos que aumentan hacia el usuario.

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA

Distancia: milímetros (mm)

Tabla 1. Magnitudes físicas medidas por los sensores de Leap.

y su programación permite el uso de los siguientes lenguajes:

TRABAJO FIN DE GRADO - MEMORIA BENAVENTE DOMENECH, PATRICIA