UNIVERSIDAD TECNOLÓGICA...

UNIVERSIDAD TECNOLÓGICA EQUINOCCIAL

FACULTAD DE CIENCIAS DE LA INGENIERÍA E

INDUSTRIAS

CARRERA DE INGENIERÍA MECATRÓNICA

SISTEMA DE CONTROL DE MANO ROBÓTICA MEDIANTE

SENSOR DE REALIDAD VIRTUAL

TRABAJO PREVIO A LA OBTENCIÓN DEL TÍTULO

DE INGENIERO MECATRÓNICO

DAVID ALEJANDRO VEGA PÉREZ

DIRECTOR: DANIEL ALEJANDRO MIDEROS MORA PhD.

Quito, julio 2018

FORMULARIO DE REGISTRO BIBLIOGRÁFICO

PROYECTO DE TITULACIÓN

DATOS DE CONTACTO

CÉDULA DE IDENTIDAD: 1720351046

APELLIDO Y NOMBRES: VEGA PÉREZ DAVID ALEJANDRO

DIRECCIÓN: TUMBACO, PIO JARAMILLO Y JORGE

ICAZA E28-88

EMAIL: [email protected]

TELÉFONO FIJO: 022373691

TELÉFONO MOVIL: 0992517444

DATOS DE LA OBRA

TITULO: SISTEMA DE CONTROL DE MANO

ROBÓTICA MEDIANTE SENSOR DE

REALIDAD VIRTUAL

AUTOR O AUTORES: Vega Pérez David Alejandro

FECHA DE ENTREGA DEL PROYECTO

DE TITULACIÓN:

2018-04-18

DIRECTOR DEL PROYECTO DE

TITULACIÓN:

DANIEL ALEJANDRO MIDEROS MORA

PhD.

PROGRAMA PREGRADO POSGRADO

TITULO POR EL QUE OPTA: Ingeniero en Mecatrónica

RESUMEN: Mínimo 250 palabras Debido a la necesidad de precisión al controlar sistemas robóticos de una manera natural se propone implementar un sistema de control de lazo abierto sobre una mano robótica mediante un sensor de movimiento 3D y control de gestos. Se utilizó la metodología de modelo en V siendo un estándar para el diseño de sistemas mecatrónicos donde las etapas generales son los requerimientos del sistema, diseño de sistemas, diseño especifico e integración de sistemas, resultando el producto final. El modelo de datos creado obtiene los parámetros para el controlador de tareas sobre los datos en el sistema conectado al sensor y en el ordenador, este envía los datos hacia la interfaz gráfica como también al sistema de control de los actuadores. El ángulo enviado es mapeado dentro del micro-controlador para acoplarse a los rangos de movimiento del prototipo físico. Los datos obtenidos como

X

muestra fueron analizados y así se obtuvo resultados estadísticos como los son los valores promedio y variación porcentual de cada vector de posición, manteniendo la mano estatica sobre el sensor. La interfaz gráfica muestra los datos que arroja el sensor y los transforma en vectores, una vez que se obtienen estos datos se los va mostrando cuadro por cuadro dependiendo de la unidad de procesamiento gráfico que el ordenador posea para un mejor desempeño de la aplicación. Finalmente se integró los sistemas desarrollados en conjunto para controlar el prototipo físico de manera que la adquisición de datos esté vinculada con el control del prototipo físico y también tenga sincronización en la interfaz. La respuesta del prototipo físico generada por el sistema de control y envío de datos implementado para Leap Motion, fue calibrada con posiciones directamente hacia los dedos del prototipo.

PALABRAS CLAVES: Interfaz gráfica del usuario,

interacción humano-computadora,

radiotransmisión, comunicación

serial, emisor, receptor, sensor.,

mano robótica, Leap motion.

ABSTRACT:

Due to the need of precision when controlling robotic systems in a natural way it is proposed to implement an open loop control system on a robotic mechanical hand prototype using a 3D motion sensor and gesture control. The V model methodology was used being a standard for the design of mechatronic systems where the general stages are the system requirements, system design, specific design and system integration, resulting in the final product. The data model created obtains the parameters

DEDICATORIA

Dedico el presente trabajo a mi padre por brindarme su apoyo y cariño

incondicional e impulsarme a mejorar en todos los aspectos posibles de mi

vida, por siempre creer en mí y ser mi guía en todas las etapas de mi vida, sin

el nada hubiera sido posible este es tanto su logro como mío. A mi madre por

haberme enseñado a ser una persona de buen corazón y haberme inculcado

el ser un buen ser humano, este logro y cada uno de los que vienen es en su

memoria y su cariño. A mi hermano por aconsejarme, acompañarme y estar

siempre pendiente, en todo lo que puede. A mis amigos que son la familia que

elegí y brindarme su apoyo en todo lo que pueden.

AGRADECIMIENTOS

Agradezco este logro a Dios por jamás abandonarme ni dejarme a la deriva,

también estoy muy agradecido con mi padre por ser el pilar de mi familia,

siempre estar presente y pendiente de mí, para darme su apoyo. A mi

hermano por el apoyo constante así como a mis amigos por ser un factor

importante y un aliento para llegar a esta meta, agradezco a mis maestros que

sin su sabiduría y enseñanzas esto no sería posible.

i

INDICE DE CONTENIDO

PÁGINA RESUMEN ..................................................................................................... 1

ABSTRACT ................................................................................................... 2

1. INTRODUCCIÓN ................................................................................ 3

Arquitectura del sistema de adquisición de datos Leap Motion® ................ 8

Sistema de comunicación para aplicaciones nativas .................................. 9

Mano Robótica .......................................................................................... 11

2. METODOLOGÍA Y DISEÑO ............................................................... 9

Requerimientos funcionales ...................................................................... 18

Restricciones del sistema .......................................................................... 18

Especificaciones del sistema .................................................................... 19

Análisis funcional ...................................................................................... 19

Diseño conceptual ..................................................................................... 22

Arquitectura Modelo – Vista - Controlador ................................................ 24

Diseño especifico sistema electrónico y de control ................................... 38

Diagrama de procesos para recepción de señal y control de

Servomotores en MCU .............................................................................. 46

Mantenimiento y calibración del prototipo físico ........................................ 50

Integración de sistemas ............................................................................ 50

Validación de sistemas .............................................................................. 51

3. RESULTADOS Y DISCUSIÓN ......................................................... 45

4. CONCLUSIONES Y RECOMENDACIONES .................................... 70

BIBLIOGRAFÍA ........................................................................................... 71

ii

INDICE DE TABLA

PÁGINA

Tabla 1. Comparativa de lenguajes de alto nivel ......................................... 10

Tabla 2. Comparación Modelos Mecánicos Existentes de Mano Robótica . 11

Tabla 3. Datos de Servo-motor.................................................................... 38

Tabla 4. Comparativa placas con MCU para control ................................... 41

Tabla 5. Datos promedio de "huesos" y dedos obtenidos a partir de SDK

Leap Motion ................................................................................................. 53

Tabla 6. Datos de variación porcentual de "huesos" y dedos, en muestra

de datos Leap Motion - mano abierta .......................................................... 55

Tabla 7. Datos estadísticos tiempo de envío de datos ordenador – Serial

Com/Xbee maestro ...................................................................................... 61

Tabla 8. Datos estadísticos de tiempo de respuesta Xbee esclavo - MCU . 64

Tabla 9. Datos estadísticos de tiempo de respuesta de todo el sistema ..... 66

Tabla 10. Porcentaje de desviación del dedo físico vs datos de Leap

Motion .......................................................................................................... 67

iii

INDICE DE FIGURAS

PÁGINA

Figura 1. Campo de Vista Leap Motion ......................................................... 5

Figura 2. Partes de Sistema DAQ ................................................................. 6

Figura 3. Arquitectura del Sistema para interfaz de aplicaciones Nativas ..... 9

Figura 4. Demora con USB 2 60Hz en pantalla y sincronización de

pantalla encencida ....................................................................................... 13

Figura 5. Demora con USB 3 60Hz en pantalla y sincronización de

pantalla apagada ......................................................................................... 13

Figura 6. Esquema de Proyecto .................................................................. 14

Figura 7. Desviación (%) Leap Motion vs Dedo .......................................... 15

Figura 8. Velocidad de respuesta Sistema Zigbee ...................................... 15

Figura 9. Fuerza ejercida por cada dedo mano robótica UTE ..................... 16

Figura 10. Metodología en V con sistemas embebidos ............................... 17

Figura 11. Análisis Funcional del Proyecto ................................................. 21

Figura 12. Diseño Conceptual del Proyecto ................................................ 23

Figura 13. Arquitectura MVC ....................................................................... 24

Figura 14. Modelo de Datos Leap Motion ................................................... 25

Figura 15. Estructura de clase LeapApp .................................................... 26

Figura 16. Controlador de Aplicación .......................................................... 27

Figura 17. Diseño de interfaz gráfica de aplicación para el ordenador

JavaFx ......................................................................................................... 29

Figura 18. Jerarquía objetos aplicación JavaFx .......................................... 30

Figura 19. Cilindro con rotación eje Z ......................................................... 34

Figura 20. Flujo de aplicación con arquitectura MVC .................................. 37

Figura 21. Dimensiones de Servo Motor ..................................................... 38

Figura 22. Captura de Configuración Xbee Master&Slave 1 ....................... 42





Figura 27. Simulación de Sistema electrónico y de Control con

ATMEGA328 - MCU Arduino Nano .............................................................. 46

Figura 28. Clase ServoBarrido Arduino ....................................................... 47

Figura 29. Flujo de Control y recepción de señal ........................................ 49

Figura 30. Sistema de coordenadas cartesianas Leap Motion.................... 56

Figura 31. Gráfico de vectores de dedo Índice en el espacio sistema de

coordenadas (X, Y, Z) .................................................................................. 57

Figura 32. Tipo de "Hueso" SDK Leap Motion ............................................ 58

Figura 33. Vista de medición de dedo índice en sistema de coordenadas

3D (X, Y, Z) .................................................................................................. 58

iv

Figura 34. Interfaz gráfica para visualización de datos JavaFx, toma de

muestras ...................................................................................................... 59

Figura 35. a). Ensamble final Mano Robótica Vista isométrica – b).

Ensamble final Mano Robótica Vista lateral ................................................. 60

Figura 36. Ensamble de Prototipo Físico con Motores ................................ 60

Figura 37. Prueba de movimiento con prototipo físico y software

desarrollado en JavaFx ................................................................................ 60

Figura 38. Pruebas de movimiento del conjunto total del proyecto a)

Mano Abierta – b) Mano cerrada ................................................................. 61

Figura 39. Datos estadísticos tiempo de respuesta -Serial Com. CPU -

Xbee (Master) .............................................................................................. 62

Figura 40. Datos estadísticos tiempo de respuesta - Xbee Com. (Slave) -

MCU ............................................................................................................. 65

Figura 41. Datos estadísticos tiempo de respuesta todo el sistema ........... 66

Figura 42. Medida de angulos en variación de dedos a) 15° - b)45° .......... 68

v

INDICE DE ANEXOS

PÁGINA

ANEXOS ...................................................................................................... 74

ANEXO 1 ..................................................................................................... 74

Detalle lectura fin de posición huesos ....................................................... 74

ANEXO 2 ..................................................................................................... 76

Detalle variación porcentual en pos. de huesos ........................................ 76

ANEXO 3 ..................................................................................................... 78

Porcentaje de desviación del dedo físico vs datos de leap motion ........... 78

ANEXO 4 ..................................................................................................... 78

Dispersión respuesta com serial ............................................................... 78

ANEXO 5 ..................................................................................................... 79

Medición de ángulos resultantes en prototipo físico .................................. 79

1

RESUMEN

Debido a la necesidad de precisión al controlar sistemas robóticos de una

manera natural se propone implementar un sistema de control de lazo abierto

sobre una mano robótica mediante un sensor de movimiento 3D y control de

gestos. Se utilizó la metodología de modelo en V siendo un estándar para el

diseño de sistemas mecatrónicos donde las etapas generales son los

requerimientos del sistema, diseño de sistemas, diseño especifico e

integración de sistemas, resultando el producto final. El modelo de datos

creado obtiene los parámetros para el controlador de tareas sobre los datos

en el sistema conectado al sensor y en el ordenador, este envía los datos

hacia la interfaz gráfica como también al sistema de control de los actuadores.

El ángulo enviado es mapeado dentro del micro-controlador para acoplarse a

los rangos de movimiento del prototipo físico. Los datos obtenidos como

muestra fueron analizados y así se obtuvo resultados estadísticos como los

son los valores promedio y variación porcentual de cada vector de posición,

manteniendo la mano estatica sobre el sensor. La interfaz gráfica muestra los

datos que arroja el sensor y los transforma en vectores, una vez que se

obtienen estos datos se los va mostrando cuadro por cuadro dependiendo de

la unidad de procesamiento gráfico que el ordenador posea para un mejor

desempeño de la aplicación. Finalmente se integró los sistemas desarrollados

en conjunto para controlar el prototipo físico de manera que la adquisición de

datos esté vinculada con el control del prototipo físico y también tenga

sincronización en la interfaz. La respuesta del prototipo físico generada por el

sistema de control y envío de datos implementado para Leap Motion, fue

calibrada con posiciones directamente hacia los dedos del prototipo.

Palabras clave: interfaz gráfica del usuario, interacción humano-computadora,

radiotransmisión, comunicación serial, emisor, receptor, sensor., mano

robótica, Leap motion.

2

ABSTRACT

Due to the need of precision when controlling robotic systems in a natural way

it is proposed to implement an open loop control system on a robotic

mechanical hand prototype using a 3D motion sensor and gesture control. The

V model methodology was used being a standard for the design of mechatronic

systems where the general stages are the system requirements, system

design, specific design and system integration, resulting in the final product.

The data model created obtains the parameters for the task controller on the

data in the system connected to the sensor and in the computer, which sends

the data to the graphic interface as well as to the control system of the

actuators. The angle sent is mapped within the microcontroller to fit the ranges

of motion of the physical prototype. The data obtained as a sample were

analyzed and thus statistical results were obtained, such as the average

values and percentage variation of each position vector, keeping the static

hand on the sensor. The graphical interface shows the data thrown by the

sensor and transforms them into vectors, once these data are obtained they

are shown frame by frame depending on the graphic processing unit that the

computer has for a better performance of the application. Finally, the systems

developed together were integrated to control the physical prototype so that

the data acquisition is linked to the control of the physical prototype and also

has synchronization in the interface. The response of the physical prototype

generated by the control and data delivery system implemented for Leap

Motion was calibrated with positions directly towards the fingers of the

prototype.

Keywords: graphical user interface, human-computer interaction, radio

transmission, serial communication, transmitter, receiver, sensor, Robotic

hand, Leap motion.

1. INTRODUCCIÓN

3

La electrónica y el control en contexto de manipulación de sistemas en los

últimos años se ha visto soportada de diferentes fuentes científicas para

mejorar la manera de interactuar entre el usuario y los sistemas robóticos o

conjuntos de actuadores.

Debido a la necesidad de precisión al controlar sistemas robóticos, de una

manera natural, es decir sin artefactos que deban colocarse físicamente o se

deban manipular con contacto físico.

Existen diferentes variaciones de diseños para control de Mano robótica, entre

estos esta la creación de un guante que incluye sensores de flexión en cada

dedo, para poder obtener la señal del movimiento o los vectores aproximados

de la posición de cada dedo. (Zubrycki & Granosik, 2014)

En comparación con la opción de un guante con sensores, o un sensor de

gestos electromiógrafo se propuso implementar un sistema de control con un

sensor de gestos 3D, que permita el movimiento de una mano robótica que

seguirá los movimientos de la mano normal solo con la lectura del sensor.

De los diseños revisados como son: Modelo de control con señales EMG

(Micera, Carpaneto, & Raspopovic, 2010) o el modelo con sensores en un

guante (Zubrycki & Granosik, 2014), son modelos que funcionan directamente

sin procesamiento de datos o sin GUI.

De las diferentes maneras observadas en el control de una mano robótica, se

pudo analizar que no se ha encontrado un modelo con la misma arquitectura,

entre el sistema de control de lazo abierto.

La adquisición, procesamiento de datos y sistema de envío de datos, de

manera que permita el manejo sin utilizar artefactos en la mano que controla

el modelo robótico.

También se observó que con sensores analógicos, la calibración viene a ser

una etapa importante, y en vista de que son equipos físicos y en constante

manipulación la tendencia a perder precisión es repetitiva.

Como utilidad principal la elaboración e implementación de este sistema se

tiene la obtención de valores vectoriales en un plano con referencia inicial en

el centro del sensor y posiciones que le corresponden a cada parte de la

mano.

Se observó en el prototipo físico el momento que se tiene el sistema en línea

y se coloca la mano sobre el sensor, la transferencia de datos y posiciones en

4

tiempo “real” hacia el modelo físico, se encuentra precisamente en poder

obtener datos acercados a la realidad de los movimientos.

Sin necesidad de continuas calibraciones se debe notar que el sensor de

movimiento 3D y control de gestos junto con el driver de conexión y el módulo

de adquisición de datos, puede utilizarse en diferentes tipos de sistemas

físicos como:

brazos robóticos

robots pincher

robots exploradores

drones, entre otros. (Justinico, Cárdenas, & Rodríguez, 2015)

Con la información mencionada anteriormente se planteó como objetivos del

proyecto, los siguientes:

El objetivo general es implementar un sistema de control de lazo abierto sobre

una mano robótica mediante un sensor de movimiento 3D y control de gestos.

Para poder completar el objetivo antes mencionado se debe ejecutar los

siguientes objetivos específicos, para que de esta manera se valide la

implementación del sistema de control para el prototipo físico.

Implementar sistema de adquisición de datos desde el sensor de

movimiento 3D y control de gestos.

Diseñar la interfaz de visualización de acciones y datos adquiridos desde

el sensor de movimiento 3D y control de gestos.

Integrar los modelos de adquisición, visualización, procesamiento y control.

Controlar movimientos en la mano robótica por medio de señales

adquiridas desde el sensor de movimiento 3D y control de gestos.

La interacción Humano-Computadora (HCI)(Silva, S, Eduardo., Anderson,

Jader., Henrique, Janiel., Teichrieb & Ramalho, 2013) se ha convertido en un

importante campo de estudio que ha ido ganando atención de parte de la

investigación en diferentes y nuevos dispositivos de interacción como: Control

remoto del Nintendo Wii (Nintendo©, 2017), Kinect Microsoft(Microsoft©,

2017a), Leap Motion (Leap Motion inc., 2012), entre otros.

Controlador Leap Motion®

El Leap Motion® trabaja con dos cámaras infrarrojas y tres leds IR, como

sensores de profundidad, en un campo de alcance limitado de 8 pies cúbicos

(aproximadamente 61 centímetros cúbicos).

5

Utilizando la estereoscopia desde las dos cámaras, el dispositivo puede

minimizar el error mediante las herramientas, los dedos y la mano son

características construidas con un único modelo matemático para maximizar

la velocidad y la precisión.(Silva, S, Eduardo., Anderson, Jader., Henrique,

Janiel., Teichrieb & Ramalho, 2013)

De acuerdo a la figura 1 se observa, las distancias que aproximadamente se

tiene desde el punto inicial del sensor hacia cada uno de sus extremos, las

medidas son aproximadas debido a variables físicas que limitan estos

extremos como pueden ser la luz o la posición del sensor.

Figura 1. Campo de Vista Leap Motion

(Silva, S, Eduardo, 2013)

De acuerdo a los autores Pedro Andrey Cañón, Pedro Cárdenas, Oscar

Rodríguez, el sensor Leap Motion, permite al usuario utilizarlo como un

servicio dentro de Windows, el cual permite conectar el controlador del aparato

a través del protocolo USB.

Los API (Application Programming Interface)(Cañón, Cárdenas, & Rodríguez,

2015) que se tiene a disposición para manipular este dispositivo son dos, el

SDK (Software Development Kit) propio de los creadores/proveedores y una

interfaz que permite el uso de WebSockets, la cual facilita el uso de Leap

Motion® mediante aplicaciones Web.

El reconocimiento de gestos es utilizado en robótica con mayor frecuencia, en

general de manera simple con señales hechas con la mano.(Justinico et al.,

2015). Prácticamente viene a ser un sistema de visión artificial, y se lo puede

programar para reconocer ciertos patrones repetitivos, y recibir las posiciones

de la mano, asignándole así una acción el momento de reconocer este patrón.

Leap Motion® es un sistema que combina la visión artificial mediante sus

cámaras infrarrojas, la ventaja que este dispositivo muestra frente a otros del

6

mismo tipo (HCI), está en la eficacia para el análisis de los gestos y

movimientos de la mano, con mayor precisión y resolución frente a sus

adversarios(González, Bellucci, & Cuevas, 2012).

Las tecnologías de Interacción Humano-Computadora (HCI), han sido

exploradas para varias aplicaciones como juegos, modelado 3D inmersivo,

aplicaciones de realidad aumentada, pintado de aire, escritura y diseño, entre

otros.(Khademi et al., 2014)

Adquisición de Datos (DAQ)

Adquisición de datos (DAQ), es el procedimiento para poder medir fenómenos

físicos o eléctricos como la corriente, el voltaje, temperatura, presión o sonido,

entre otros. Y poder transferir los datos a un repositorio u ordenador.

Un sistema de adquisición de datos está compuesto por elementos como:

sensores, sistemas de medición, y ordenadores con software programable

(figura 2), a diferencia de los sistemas de medición actuales el sistema de

medición DAQ, obtiene el mayor desempeño de procesador del ordenador

disponible, las capacidades de conexión, conectividad, producción del

estándar industrial y flexible brinda una solución más viable. (National

Instruments, 2016)

Figura 2. Partes de Sistema DAQ

(National Instruments, 2016)

Para el desarrollo del enlace de adquisición de datos se utilizó un lenguaje de

alto nivel, con el que se generó los respectivos módulos que comunican el

sensor con la interfaz gráfica y el envío de datos al sistema de control.

Entre los principios más importantes para una interfaz gráfica están la

simplicidad, funcionalidad, el contexto, la consistencia, sensibilidad y el

diseño.

Dentro de los lenguajes de programación de alto nivel existen diferentes

opciones aptas para lograr generar un GUI compatible con el sistema como

7

aplicación de escritorio, el cual permita tener control y visualización adecuada

de las funcionalidades contenidas en el proyecto.

La interfaz gráfica debe cumplir características y satisfacer las necesidades

hacia el usuario cumpliendo cualidades como lo son ser intuitiva, permitir al

usuario enfocarse en la función principal y la información del sistema, no en

cómo debería funcionar el GUI, también debe ser de rápida

respuesta.(Dragutin Petkovic, 2015)

Los lenguajes de alto nivel permiten a la solución de un problema específico

en términos cercanos a los usados por humanos, estos tipos de lenguajes

como C, C++, Java, C#, entre otros. Fueron diseñados para facilitar la

programación, menos susceptible a errores y para evitar que el programador

se vea obligado a conocer la estructura interna de un ordenador en particular.

(Sun, 2016)

Para los lenguajes abiertos como son: Java y Python, se tiene una gama

amplia de IDEs de desarrollo sin necesidad de pagar una licencia con la

ventaja de utilizar todos los beneficios y herramientas disponibles en estos

lenguajes, como son Netbeans o Eclipse para Java y Eclipse o PyDev para

Python.

En C# se puede utilizar versiones anteriores de Visual Studio de Microsoft

para desarrollo sin necesidad de licencia, pero si se necesita un IDE

actualizado con herramientas completas se debe adquirir una licencia.

(Microsoft©, 2017b)

Para esta aplicación se utilizaron las siguientes reglas y convenciones para

clases reutilizables que son implementadas dentro de la codificación:

Inicio de recursión. Si una clase se comunica con un atributo de otra clase,

la interfaz entre estas debe ser la misma (tipo de dato).

Eliminar el análisis de casos. Los métodos de una clase deben ser creados

en varias posibles clases de un objeto para responder a los diferentes

casos generando un código dinámico en las respuestas.

Reducir el número de argumentos. Los mensajes o respuestas generados,

deben ser construidos por el programa para reducir la cantidad de

opciones que se codifican.

Reducir el tamaño de los métodos. Los métodos efectivos usualmente son

pequeños, es fácil sub-instanciar una clase con métodos pequeños.

Las jerarquías de clases deben ser profundas y estrechas. Una buena

jerarquía de clases debe ser de profundidad con varias capas, haciendo el

programa estable y difícil de craquear.

8

La clase de la parte superior de la jerarquía debe ser abstracta. La herencia

o la compartición de código usualmente indica la necesidad de una nueva

subclase.

Minimizar acceso a las variables. Los atributos deben ser privados, y

respetando la jerarquía y la herencia.

Las sub-clases deben ser especializaciones. La especialización de una

clase consiste en que los atributos de la clase padre sean genéricos y en

la sub-clase estos tengan funciones específicas.

Dividir clases largas. Si una clase tiene entre 50 a 100 métodos entonces

representara una difícil abstracción, por lo que debe ser redefinida en

diferentes clases.

El factor de las diferencias de implementación en los subcomponentes. Si

un método es implementado de una manera y otros son implementados de

otra diferente de ese mismo método, eso crea un método independiente

de la super-clase lo cual se debe depurar encapsulando este método en

un componente separado.

Separar métodos que no se comunican. Una clase debe ser siempre

dividida cuando la mitad de sus métodos acceden a la mitad de sus

variables implementadas.

Enviar mensajes a componentes en vez de a sí misma. Una estructura

basada en jerarquía puede convertirse en una estructura basada en

componentes, reemplazando los métodos sobrescritos por componentes

enviados.

Reducir el paso de parámetros implícitos. A veces es difícil dividir una clase

den dos partes, ya que los métodos pueden ir a diferentes clases y acceder

a la misma variable implementada, esto puede suceder debido a que la

variable es global, cambiando los métodos para pasar el parámetro

explícitamente hará la división de esta clase dinámica. (Johnson & Foote,

1988).

ARQUITECTURA DEL SISTEMA DE ADQUISICIÓN DE DATOS

LEAP MOTION®

El software de Leap Motion® se ejecuta como un servicio dentro de Windows.

Este servicio conecta al sensor mediante comunicación USB. Las aplicaciones

acceden al servicio de Leap Motion® para recibir los datos del seguimiento

del movimiento.

El SDK del proveedor tiene dos variedades de API, para poder obtener los

datos del sensor: Un sistema de comunicación nativo (Interfaz) y un sistema

de comunicación mediante WebSocket.

9

Estos APIs permiten crear aplicaciones con acceso al sensor en varios

lenguajes de programación los que se pueden encontrar en la documentación

del sensor incluyendo Javascript ejecutado en un navegador web. (LEAP

MOTION DEVELOPER PORTAL, 2017)

SISTEMA DE COMUNICACIÓN PARA APLICACIONES

NATIVAS

La interfaz para aplicaciones nativas es funcional mediante una librería

cargada dinámicamente. La cual conecta al servicio de Leap Motion® y

permite obtener los datos en la aplicación. Se puede conectar a esta librería

directamente mediante lenguajes como C++, Objective-C, Java, C# y Python,

en la figura 3 se explica gráficamente la arquitectura del sistema.

Figura 3. Arquitectura del Sistema para interfaz de aplicaciones Nativas

(LEAP MOTION DEVELOPER PORTAL, 2017)

1. El servicio de Leap Motion®, recibe los datos mediante comunicación

USB, procesa la información y la envía a las aplicaciones con acceso al

sensor. Por defecto el servicios solo envía datos en primer plano a la

aplicación, pero las aplicaciones pueden obtener los datos en segundo

plano (backend) estas peticiones pueden ser negadas por el usuario local.

2. La aplicación de Leap Motion®, esta se ejecuta por separado del servicio

(API) y permite que el usuario del ordenador configurar el sensor. Esta

aplicación nativa del proveedor, es un panel de control en Windows.

3. Aplicación con acceso de primer plano, recibe los datos de del

seguimiento del movimiento directamente del servicio, la aplicación está

conectada directamente con los lenguajes de alto nivel antes

mencionados.

10

4. Aplicación con acceso de segundo plano, cuando la aplicación pierde

foco, es decir está funcionando en segundo plano (backend) en el

ordenador, esta aplicación debe estar configurada como proceso en

segundo plano dentro del sistema. (LEAP MOTION DEVELOPER

PORTAL, 2017).

Leap Motion® ha generado diferentes APIs para el desarrollo de aplicaciones,

y tanto como el lenguaje y el SDK de desarrollo están disponibles en los 3

lenguajes elegidos, C# y Java son lenguajes compilados.

La ventaja sobre los desarrollos en estos ya que el código compilado puede

ser ejecutado directamente por el CPU del ordenador mientras los lenguajes

interpretados (Python) deben ser primero traducidos a lenguaje de máquina

para luego ser ejecutados. (Sun, 2016)

En Java se tiene la plataforma de desarrollo de JavaFx (RUZMAN, 2014) la

cual permite a los desarrolladores construir rápidamente aplicaciones gráficas

multiplataforma, en Python se tiene el módulo de interfaz “Tk interface” o

“Tkinter”, consiste en un número de módulos, son herramientas desde el

código, “Tkinter” es una plataforma disponible para sistemas Unix, Windows y

Macintosh, desde la versión 8.0 “Tk” tiene un aspecto nativo para cada

plataforma. (Lundh, 2003)

Entre las opciones de lenguaje de alto nivel que se pudo tomar en cuenta por

su facilidad de implementación e interfaces de desarrollo comprensibles,

están: C#, Python, Java, la selección del lenguaje de alto nivel para realizar el

desarrollo se lo hizo bajo parámetros de comparativa citados en la tabla 2.

En la tabla 1, los lenguajes seleccionados se analizaron, C# tiene la limitante

que solo puede ejecutarse en SO Windows, mientras que Java y Python tienen

la ventaja de ser compatibles con cualquier SO.

Tabla 1. Comparativa de lenguajes de alto nivel

Características Java C# Python

Multiplataforma

(Sistema Operativo)

X X

Compatible con Leap

Motion

X X X

SDK Disponible X X X

Compilado X X

IDE Necesita Licencia X

Toolkit para GUI X X X

Experiencia previa con

el lenguaje

X X X

11

Para C#, ocupa Windows Forms, la cual es fácil de configurar y utilizar dentro

del IDE de Microsoft: Visual Studio 2017 o posteriores versiones, esta

plataforma de desarrollo es intuitiva y fácil, utilizando un método de

“drag&drop”, con lo que solo se debió arrastrar y ubicar los componentes

según se requiere en la pantalla.(Microsoft©, 2017b)

MANO ROBÓTICA

La habilidad de sujetar es una función motora humana fundamental, como

también un prerrequisito para desempeñar una innumerable cantidad de

manipulaciones en objetos. Por lo tanto “sujetar” viene a ser también una

habilidad fundamental para asistencia robótica.(Ben Amor, Kroemer,

Hillenbrand, Neumann, & Peters, 2012)

En la tabla 2 se compara y analiza diferentes opciones de diseños

previamente implementados en otros proyectos similares, los que pueden ser

extruidos en impresora 3d, y se puede construir el prototipo sin necesidad de

recurrir a procesos de manufactura que requieran recursos que sobrepasen

el presupuesto y alcance de este proyecto:

Tabla 2. Comparación Modelos Mecánicos Existentes de Mano Robótica

a) (Cyborg Beast, 2017) b) (As, 2011)

c) (Martínez, 2016) d) (HACKberry, 2016)

e) (InMoov, 2017) f) (GYROBOT, 2015)

Cyborg

Beast (a)

Robohand

(b)

Mano

robótica

U.T.E.(c)

Exii-

Hackberry (d)

Bionic

Inmoov (f)

FLEXY

HAND 2

(g)

Impresión 3d TRUE TRUE TRUE TRUE TRUE TRUE

Modelo

mecánico

disponible

FALSE FALSE TRUE TRUE TRUE FALSE

Modelo

Impresión

disponible

TRUE TRUE TRUE TRUE TRUE TRUE

Producto

Final (Modelo

comercial)

TRUE FALSE FALSE TRUE FALSE FALSE

Flexibilidad de

Modelo


Control de

dedos por

separado

TRUE TRUE TRUE TRUE TRUE TRUE

Movimiento

de muñeca


Posibilidad de

Control con

MCU

FALSE FALSE TRUE TRUE TRUE TRUE

12

Los resultados de la comparativa en los modelos anteriores permiten tener

claro el panorama en el momento de seleccionar el modelo para el prototipo,

este modelo debe cumplir ciertos requerimientos como son:

Permita controlar los dedos por separado.

Exista movimiento de muñeca

Se pueda controlar mediante un MCU (micro-controller unit)

Permita extruir las piezas por impresión 3D

Realizando la comparación entre los modelos aptos para la implementación y

desarrollo de objetivos así como también acorde con el cumplimento de

requerimientos y restricciones, están los modelos Bionic Inmoov, mano

robótica UTE(Universidad Tecnológica Equinoccial).

Donde por motivos de ensamble y construcción siendo este trabajo la

implementación lazo abierto sobre una mano robótica mediante un sensor de

movimiento 3D y control de gestos se procede a elegir el modelo construido

en la UTE, teniendo este prototipo las características necesarias en cuanto al

cumplimiento de requerimientos.

Este es un prototipo físico ya construido por el Ingeniero Josué Martínez en el

año 2016 previo a la obtención de su título de ingeniero mecatrónico, este

modelo optimizó la utilización de recursos y sirvió como prototipo de pruebas

para el sistema de control en general.

Una ventaja del modelo escogido es que los actuadores se ubican dentro del

antebrazo y estéticamente parece un brazo y mano real, también esto ayuda

a la portabilidad del prototipo, así como la adaptabilidad con diferentes

sistemas electrónicos para el control de este modelo robótico.

El capturar los movimientos y transmitirlos, fue inicialmente creado para

propósitos médicos y militares, los sistemas de visión y reconocimiento

pueden ser utilizados directamente para la manipulación de brazos o manos

robóticas. (Vani & Reddy, 2015)

Los datos pueden venir de diversos artefactos de sensado ya sea de visión

artificial, como pueden ser dispositivos EMG (Electromiografía) multicanal que

son nada más que electrodos para detectar señales eléctricas, la velocidad de

conductividad del musculo, el tiempo de acción, entre otros.. (Micera et al.,

2010)

También existen otros métodos como son escáner 3D o guantes con

sensores, transformando así los comandos gestuales de la mano hacia el

nodo generador de trayectoria de los actuadores. (Zubrycki & Granosik, 2014)

13

Se puede observar como las restricciones en el hardware, software e interfaz

gráfica pueden juntarse para producir latencia, la manera más entendible de

ilustrar el impacto de estos diferentes factores es observar sus contribuciones

en los diferentes escenarios. (BEDIKIAN, 2017)

Se observa en la figura 4 como los tiempos de latencia con una mala

comunicación serial (USB2) y con sincronización de video mediante software

crea una demora alta solo en la lectura serial y adquisición de datos desde el

sensor.

Figura 4. Demora con USB 2 60Hz en pantalla y sincronización de pantalla encencida

(BEDIKIAN, 2017)

Al elegir una mejor tecnología en cuando a la comunicación serial (USB3) y

retirando la sincronización de video mediante software mejora notablemente

el tiempo de respuesta, esto se observa en la figura 5.

Figura 5. Demora con USB 3 60Hz en pantalla y sincronización de pantalla apagada

(BEDIKIAN, 2017)

En conclusión según los estudios en la demora de Leap Motion, se tiene un

tiempo aproximado de entre 5 [ms] a 15 [ms] en la obtención de datos y

procesamiento en el API de forma nativa, cabe mencionar que todas las

aplicaciones de Leap Motion utilizan el API de este sensor, incluso aquellas

14

que vienen de fábrica, debido a que el sensor posee un firmware embebido

que responde específicamente a su SDK y su API para obtención de datos.

Se toma en cuenta en las figuras 3 y 4 sobre el conjunto de procesos de

obtención de datos, uso de API, procesamiento gráfico y muestra de datos en

interfaz gráfica con su demora total.

Los autores del artículo “ROBOTIC HAND CONTROLLED THROUGH VISION

AND BIOMECHANICAL SENSORS” (ALPISTE PENALBA, TORNER RIBE, &

BRIGOS HERMIDA, 2017) esquematizan el sistema como se muestra en la

figura 6.

Figura 6. Esquema de Proyecto

Donde cada dedo del prototipo físico es direccionado por un servomotor, estos

actuadores son controlados por una placa programable Arduino UNO, los

servomotores halan un cable para causar el movimiento en el ensamble que

constan los dedos, estos filamentos tienen un diámetro de 0.45mm y una

resistencia de 91Kg. (ALPISTE PENALBA et al., 2017)

En la figura 7 se muestran resultados de la variación porcentual de los datos

enviados a los actuadores en comparación de los dedos en el prototipo físico,

los autores en este artículo utilizaron el modelo de Bionic – Inmoov.

15

Figura 7. Desviación (%) Leap Motion vs Dedo

(ALPISTE PENALBA et al., 2017)

El autor Josué Martínez en la tesis “DISEÑO Y CONSTRUCCIÓN DE MANO

ROBÓTICA CONTROLADA A DISTANCIA CON UN MANDO DE GUANTE”

cuyo proyecto consiste en un guante con sensores de flexión en cada dedo

para poder obtener el ángulo de giro de cada dedo, el mismo que se transmite

a los servo-motores.

Utiliza un sistema de comunicación en una red Zigbee, en los que tanto

maestro como esclavo están conectados a placas Arduino independientes

para generar la comunicación.

Los resultados en el tiempo de transmisión de datos que obtiene este proyecto

son de aproximadamente 184[ms] a 548.6[ms] en los diferentes dedos como

se muestra en la figura 8, el autor redacta el haber tomado como referencia

una muestra de 5 datos por cada dedo en el prototipo físico.

Figura 8. Velocidad de respuesta Sistema Zigbee

(Martínez, 2016)

16

Uno de los resultados importantes de este proyecto es el de la prueba de

fuerza en el prototipo físico, donde el autor toma una muestra de 5 datos por

cada dedo y muestra un promedio de cada dedo, donde se puede apreciar en

la figura 9 que ninguno de dichos dedos supera a 1[N].

Figura 9. Fuerza ejercida por cada dedo mano robótica UTE

(Martínez, 2016)

2. METODOLOGÍA Y DISEÑO

17

El proyecto consistió en implementar un sistema de control de lazo abierto

sobre una mano robótica mediante un sensor de movimiento 3D y control de

gestos, los datos fueron adquiridos y procesados mediante un ordenador.

Tuvo como tarea por medio de un lenguaje de alto nivel, mapear y decodificar

la señal adquirida desde el sensor de movimiento 3D y control de gestos, y

transmitirla mediante la interfaz de comunicación serial (SCI).

Se utilizó un emisor y un receptor para crear una red de radiodifusión Zigbee,

el uno conectado directamente al ordenador con protocolo universal

asíncrono (UART) y el otro funcionando en conjunto con la placa Arduino,

respectivamente.

Los datos y acciones se reflejaron en la interfaz gráfica del usuario (GUI) la

que por su diseño con la persona que estuvo utilizando el sistema, se mostró

un modelo de mano gráficando las posiciones y cada articulación de la mano

sensada respecto a la adquisición de datos y el envío de los mismos hacia el

prototipo físico.

La metodología que se utilizó es la del modelo en V (figura 10) o metodología

en V, siendo un procedimiento estándar para el diseño de sistemas

mecatrónicos, donde el proceso se divide en etapas generales tomando como

referencia los requerimientos del sistema que da origen al diseño de sistemas,

diseño especifico e integración de sistemas, resultando el producto final.

Figura 10. Metodología en V con sistemas embebidos

(Ivanov, Augsburg, Ruderman, Schiffer, & Horn, 2017)

18

Cada una de estas etapas puede también dividirse en algunas sub-etapas,

dependiendo de los diseños específicos y las tareas de estos mismos,

considerando los sistemas mecatrónicos, modelos complejos y con

estándares avanzados. (Ivanov et al., 2017)

Se analizó los requerimientos del sistema, para poder estimar los alcances del

mismo, luego se procedió a esquematizar un diseño de cada sistema

embebido dentro del producto final.

Se implementó un software para adquirir y procesar los datos del sensor, el

mismo que transmite sus datos al GUI, detrás de estos 2 sistemas

funcionando conjuntamente existe un módulo para envío de datos del

ordenador al emisor Zigbee o de ser el caso por comunicación serial, que es

ejecutado como un hilo separado.

Como elemento final al sistema completo se añade el envío de datos del

emisor Zigbee hacia el sistema de recepción y control montado en el prototipo

físico, el que procede a generar los movimientos en los actuadores.

Estos sistemas diseñados y creados por separado se integraron para poder

obtener resultados en conjunto, los que fueron evidenciados con el

movimiento del prototipo físico, sincronizado con tiempos de demora de

aproximadamente 10[ms] o 1000[ms] en modo serial o Zigbee

respectivamente.

REQUERIMIENTOS FUNCIONALES

Debe adquirir datos de posiciones y movimientos desde el sensor de

movimiento 3D y control de gestos en tipo de vector para procesarlo y

enviarlo hacia los actuadores y la interfaz gráfica.

El sistema debe procesar y verificar los datos y transmitirlos al sistema de

control de actuadores del prototipo físico.

El sistema debe mostrar los datos obtenidos y transferidos en tiempo real

sobre el GUI que es observado por el usuario.

El sistema debe recibir los datos y de serializarlos para generar el

movimiento en los actuadores del prototipo físico.

RESTRICCIONES DEL SISTEMA

El sistema maneja el desbordamiento de datos desde el emisor hacia el

receptor el momento que el MCU durante la recepción esté procesando los

datos y no esté disponible para seguir recibiendo datos hasta terminar el

proceso anterior.

19

El sistema propuesto no controla la exactitud de las fuerzas aplicadas en

cada dedo, así como la magnitud del torque que este genera en cada

actuador.

El sistema no posee ningún repositorio de almacenamiento de históricos o

base de datos de los movimientos realizados por la mano, genera una

interfaz gráfica y un enlace de comunicación para el control con datos en

línea, es decir todos los datos adquiridos por el sensor se llevan

conjuntamente a la interfaz y al prototipo físico.

ESPECIFICACIONES DEL SISTEMA

El sistema se basa en un Sensor de movimiento 3D y control de gestos que

recolecta los vectores generados por movimientos que se realizan en una

mano humana, estos datos se procesan y se envían al ordenador donde el

usuario visualiza diferentes cuadros de simulación.

Se gráficaron los vectores adquiridos, también estos datos se envían hacia el

prototipo físico mediante comunicación inalámbrica y serial, desde el

ordenador.

Los vectores se obtienen con el SDK del sensor de movimiento 3D y control

de gestos utilizando un lenguaje de alto nivel que facilitó el desarrollo de la

interfaz por encima del enlace de comunicación para adquisición y control.

El envío hacia el MCU se lo hace mediante comunicación serial y esta se logra

con módulos de comunicación inalámbrica, emisor y receptor

respectivamente.

El sistema tiene una alimentación externa tanto para los motores que

conforman el prototipo físico como para la parte del control, que necesita estar

protegida y aislada debido a las altas corrientes que se puedan generar en los

motores.

La alimentación del sensor es la misma que ocupa el ordenador por lo que

estos se aíslan del resto del sistema.

ANÁLISIS FUNCIONAL

El sistema en general consta de un sensor movimiento 3D y control de gestos,

un sistema de adquisición de datos, una interfaz gráfica y un sistema de

control para accionar actuadores, estos dan movimiento a un prototipo físico

prediseñado.

20

El sensor de movimiento 3D y control de gestos posee accesibilidad mediante

un SDK de desarrollo. El sensor permite mapear y reconocer una mano

humana con sus articulaciones y dedos como también posee comunicación

directa con diferentes sistemas operativos, como IOS (Mac) o Microsoft

Windows, entre otros.

La interfaz gráfica que se diseñó tiene como funcionalidades principales, la

visualización de vectores adquiridos en tiempo real, junto con una simulación

de una mano virtual generada a partir de lo obtenido por el sensor.

El sistema de adquisición de datos tiene como cometido la recepción de

señales desde el sensor, el procesamiento de los vectores adquiridos para

poder mapearlos y la transmisión de estas señales según sea el requerimiento

hacia el sistema de control, la interfaz gráfica y el prototipo físico.

El sistema de control de actuadores del prototipo físico, como funcionalidad

principal transmite los vectores por las comunicaciones serial y

radiofrecuencia de ser el caso de uso.

En el caso del proyecto, se utiliza el protocolo serial tanto en las pruebas con

comunicación directa (serial) hacia el sistema de control de actuadores, como

en la comunicación por radiofrecuencia.

En la figura 11 se puede observar un diagrama de la estructura y las

funcionalidades del sistema, con sus tareas principales.

21

Figura 11. Análisis Funcional del Proyecto

22

DISEÑO CONCEPTUAL

En la figura 12 se aprecia un diagrama de comportamiento, para inicio del

diseño conceptual del proyecto, se diseña el sistema de manera específica

prestando importancia a todas las funciones para cada subsistema.

Notando la importancia que los elementos y protocolos seleccionados para el

proyecto cumplan las funciones y tareas requeridas y que sean compatibles

entre estos para facilitar la comunicación.

Los vectores obtenidos provienen del sensor Leap Motion® que es un aparato

HCI(Human Computer Interface) que gracias a su tecnología, logra detectar

los movimientos realizados por la mano humana.

Los vectores que arroja el sensor son transmitidos hacia el ordenador, luego

se procesan mediante el software desarrollado para el proyecto en lenguaje

de alto nivel Java con la plataforma JavaFx que es la base de la aplicación

gráfica.

También se utiliza un controlador que permite la transmisión de estos vectores

hacia la GUI (Graphical user interface) como también al sistema de control

que se comunica con el ordenador por protocolo serial.

La interfaz gráfica recibe las posiciones en tiempo real, después que el

sistema entrega las posiciones por protocolo serial, la información viaja hacia

el micro-controlador o emisor RF de ser el caso.

Una vez que el sistema de control entrega las posiciones al micro-controlador,

los valores se des-encriptan, y se asignan las posiciones a los servo-motores.

Estos valores son mapeados para los rangos permitidos dentro de cada motor.

Los rangos de posición vienen dados como restricción del modelo

prediseñado utilizado, una vez que estos datos se mapean se envían los

pulsos a cada servo-motor y se completa el ciclo, el mismo que se repite hasta

que el usuario cierra la aplicación.

23

Figura 12. Diseño Conceptual del Proyecto

24

ARQUITECTURA MODELO – VISTA - CONTROLADOR

La arquitectura utilizada para poder controlar y mostrar los datos es la de MVC

(Model-View-Controller) (figura 13), este modelo permite la separación de la

Vista, el controlador y el modelo, estos componentes cuyas alteraciones no

afectan la accesibilidad del sistema de comunicación y el sistema de

actuadores.

Figura 13. Arquitectura MVC

MODELO DE DATOS

El modelo representa todo lo referente a la estructura de datos que se necesita

exponer y controlar en la aplicación esta estructura permite informar al objeto

los cambios y operaciones que son aplicadas por los factores internos y

externos de la aplicación.

Dentro del proyecto la persistencia de datos no existe, por lo que los vectores

son almacenados temporalmente en arreglos dentro de la estructura del

controlador.

Una vez en el controlador son manipulados y enviados a los subsistemas de

control e interfaz gráfica por lo que los históricos desaparecen para almacenar

los nuevos vectores que ingresan.

Para la manipulación del modelo se encuentra las principales funciones que

se programaron para poder realizar la conexión y obtención de datos con el

sensor.

25

Estos métodos son derivados de la clase principal de la librería de Leap

Motion, utilizando el objeto Controller el que utiliza el API para sincronizar el

programa con los datos que se obtuvieron del sensor.

En la figura 14 se tiene una descripción de la estructura de datos que maneja

Leap Motion con su API estos son los datos arrojados en cada lectura, en el

caso de este proyecto 60 lecturas por segundo.

Figura 14. Modelo de Datos Leap Motion

Para el desarrollo realizado fueron utilizadas las estructuras de ImageList para

obtención de la lectura, HandList para obtener el número de manos sobre el

sensor y validar que solo exista una.

Dentro de la estructura de la mano se obtuvo las sub estructuras de dedos y

huesos, en el caso de la estructura de herramienta y gestos, no se les dio

ningún uso.

DISEÑO DE CONTROLADOR PARA MANEJO Y RECEPCIÓN DE DATOS

Para el desarrollo del controlador y que este pueda realizar el envío de datos

hacia el sistema de control se utilizan 3 objetos que interactúan conjuntamente

para poder manejar correctamente cada actualización de datos del sensor.

El objeto principal dentro del diseño del controlador viene a ser la clase

LeapEventHandler la que se instancia mediante el objeto generado en

26

LeapEvent este a su vez interactúa con la interfaz que actualiza los datos

obtenidos en toda la aplicación.

La clase programada (figura 15) utiliza las principales funciones y validaciones

para el sensor como son crear el evento de obtención de datos (getInstance),

registrar movimientos, obtener la instancia de la conexión, obtener el estado

de la conexión, obtener el número de las manos reconocidas sobre el sensor

y actualizar los datos del controlador, entre otros métodos nativos del API del

sensor.

Figura 15. Estructura de clase LeapApp

En la figura 16 se puede observar el papel que cumple cada uno de estos

objetos, junto con los métodos que contienen para poder controlar los datos y

enviarlos a los subsistemas correspondientes.

27

Figura 16. Controlador de Aplicación

Específicamente dentro de la clase principal que maneja los eventos del

sensor, existe el método utilizado en la interfaz gráfica para la actualización

constante y la visualización en línea de los movimientos de la mano.

Este método es el que esta sincronizado con el sensor, también es el puente

entre los datos detectados en cada cuadro del sensor llevados hacia el

ordenador.

Parte del controlador también hace referencia la transferencia de datos y su

manipulación, funciones creadas para transferir las posiciones al sistema de

control de actuadores, así como controlar la comunicación serial del

ordenador.

En el paso inicial se tuvo que declarar el puerto al que se va a acceder, la tasa

de envío, el estado de conexión y de ser necesario el dispositivo a donde se

envía.

1

2

3

4

5

6

private static final String PORT = "COM3";

// TODO Replace with the baud rate of your sender module.

private static final int BAUD_RATE = 9600;

private static final String DATA_TO_SEND = "\nInicializando Comunicación

serial\n";

28

7

8

9

private static XBeeDevice myDevice;

private boolean sendDataState = true;//if busy =false if open = true

Dentro de la inicialización de esta clase existen 2 métodos importantes para

la estabilización de la conexión y el envío de datos, estos métodos contienen

el control de errores y de excepciones para de ser el caso no se detenga el

programa completamente y vuelva a realizar el ciclo.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

public XBeeDevice openConn() {

try {

myDevice = new XBeeDevice(PORT, BAUD_RATE);

if(!myDevice.isOpen()){

myDevice.open();

}else{

System.out.println("Conexión ya establecida");

}

} catch (XBeeException e) {

System.out.println("Error");

e.printStackTrace();

System.exit(1);

}

return myDevice;

}

Es importante aclarar que el método de abrir conexión se lo instancia una sola

vez para que no exista una sobrecarga de llamados sobre este puerto, y de

ser el caso se cierra la conexión y se la vuelve a instanciar una vez cerrada la

última que estuvo activa.

Como se había comentado, el método para envío de datos también es

declarado, y es utilizado a lo largo del programa para enviar la información

tomada del sensor, esto agiliza y dinamiza el uso de esta clase siendo este

un método privado de la instancia que se crea en un inicio.

1

2

3

4

5

6

7

8

9

10

private void sendData(String message){

this.setSendDataState(false);

try {

byte[] dataToSend = message.getBytes();

myDevice.sendBroadcastData(dataToSend);

System.out.println("Success");

this.setSendDataState( true);

} catch (XBeeException e) {

System.out.println("Error");

29

11

12

13

14

15

e.printStackTrace();

//System.exit(1);

this.setSendDataState(true);

}

}

DISEÑO ESPECÍFICO DEL GUI

En la figura 17 se puede observar un bosquejo de la interfaz gráfica que se

planteó obtener con el lenguaje escogido, de ser necesario se tendrá que

redibujar la interfaz completa en cada cuadro gráfico mostrado al usuario.

Se tomó en cuenta que los datos ingresan en tiempo real, y la posición puede

variar aproximadamente cada 16.6 [ms], debido a la lectura estándar del

sensor es de 60fps (frames per second).

Figura 17. Diseño de interfaz gráfica de aplicación para el ordenador JavaFx

1. Indicador de conexión Indica si el dispositivo está en línea o

conectado.

2. Tabla de datos de Posiciones Muestra las posiciones vectoriales en

el sistema de referencia prestablecido por el proveedor de Leap Motion® de

cada nodo dentro de la mano sensada por el Leap Motion®.

3. Tabla de posiciones de motores Representa las posiciones

angulares de cada uno de los motores utilizados en el prototipo mecánico.

4. Representación de mano en Ordenador Es la representación gráfica

de cada una de las posiciones de articulaciones en la mano sensada por el

Leap Motion.

30

Para haber llegado al resultado del bosquejo propuesto, se debe desarrollar

la aplicación sobre la plataforma JavaFx con cada uno de sus elementos

tomando en cuenta que para poder mostrar la variación de cada movimiento

en la pantalla en la aplicación gráfica se necesita tener los siguientes

elementos en la jerarquía mostrada en la figura 18.

Figura 18. Jerarquía objetos aplicación JavaFx

Donde la escena viene a ser la zona completa de la aplicación la cual contiene

al marco, que a su vez contiene estos otros elementos que son el contenedor

y la barra superior.

Lo primero que se realizó fue generar la escena dentro de la clase principal

que viene a ser una subclase de Applicatión, esta es una clase nativa de

JavaFx que le da a la aplicación el ciclo de vida correspondiente para este tipo

de aplicaciones gráficas: crear preparar iniciar parar.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

public class MainApp extends Application {

public static void main(String[] args) {

launch(args);

}

@Override

public void start(Stage primaryStage) throws Exception {

Group group = new Group();

Scene scene = new Scene(group, 500, 500);

PerspectiveCamera camera = new

PerspectiveCamera(true);

camera.setTranslateZ(-10);

scene.setCamera(camera);

group.getChildren().add(create3DBall());

primaryStage.setScene(scene);

primaryStage.show();

}

}

EscenaMarco o cuadro

Contenedor

Barra superior

31

Se tomó en cuenta que el sistema de referencia que retorna el API de Leap

motion frente al sistema de referencia de una escena en JavaFx es invertido

en los ejes Z y Y, es decir en la aplicación JavaFx se debe rotar la cámara de

manera que los puntos que se gráfican sean los mismos que detecta en la

mano desde el sensor.

Para esto se insertó los siguientes comandos de manera que el objeto dentro

de la escena rote:

1

2

3

4

5

PerspectiveCamera camera = new PerspectiveCamera(true);

camera.setTranslateZ(-500);

camera.setTranslateY(-200);

camera.setFarClip(1000);

camera.setFieldOfView(40);

Para poder tener una sincronización precisa entre la interfaz gráfica y los datos

obtenidos del sensor que vayan acorde con el tiempo de ejecución, se

instancia un objeto Timeline, que llevó el proceso integrado.

Cabe recalcar que este método también declara la cantidad de cuadros por

segundo que el programa obtiene del sensor y muestra al usuario, en la línea

5 se observa la variable “ea” que es la cantidad de fps (frames per second)

que se obtienen en el sensor y genera una instancia temprana que ejecuta el

método de la clase LeapApp.

1

2

3

4

5

6

7

8

9

10

private void synchronizeWithLeapMotion() {

Timeline timeline = new Timeline();

timeline.setCycleCount(Timeline.INDEFINITE);

timeline.getKeyFrames().add(

new KeyFrame(Duration.seconds(1.0 / 60.0), ea ->

LeapApp.update()));//

timeline.play();

}

De los elementos más importantes dentro del desarrollo de la interfaz gráfica

se tuvo el método pointMoved, el mismo que es llamado cada que la aplicación

gráfica muestra los vectores en la interfaz (frame) dentro de la escena, de

manera que con nuevos vectores en escena los anteriores son eliminados,

este método es generado como comportamiento dentro de la clase principal

por lo que debe declararse con el tag de @Override.

32

1

2

3

4

@Override

public void pointMoved(PointEvent event) {

int handId = event.getSource().id();

Hand3DCreatorUpdatehand = hands.get(handId);

El momento que se generó el método pointMoved, como se observa en la

línea 4 se instanció un objeto de la clase encargada de tomar los datos

directamente del API de Leap Motion.

Se debió empezar por crear el objeto esfera para poder instanciarlo,

inicializarlo y ubicarlo en la escena, para esto se debe crear un método que

permita realizar esta acción cada que sea necesaria la gráfica.

Hand3DCreatorUpdate contiene el método para creación de esferas dentro de

la interfaz gráfica, esta clase permite canalizar todos los datos hacia la

aplicación principal, utilizando los atributos que facilita el SDK del sensor y

plasmándolos en la escena para que el usuario pueda observar el esqueleto

de la mano.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

public class Hand3DCreatorUpdate extends Group {

private Sphere palm;

private Sphere wrist;

private Sphere[] fingers = new Sphere[5];

private Sphere[] distal = new Sphere[5];

private Sphere[] proximal = new Sphere[5];

private Sphere[] intermediate = new Sphere[5];

public Hand3DCreatorUpdate (int handId) {

palm = createSphere();

wrist = createSphere();

for(int i = 0; i < fingers.length; i++) {

fingers[i] = createSphere();

distal[i] = createSphere();

intermediate[i] = createSphere();

proximal[i] = createSphere();

getChildren().addAll(fingers[i], distal[i],

proximal[i], intermediate[i]);

}

getChildren().addAll(palm, wrist);

}

}

33

La clase Hand3DCreatorUpdate se utilizó para la generación de una gráfica

de los puntos de las juntas de cada dedo, palma y muñeca, de esta manera

se gráfica cada cuadro por segundo, en esta clase se puede aumentar los

elementos que varían en la escena de acuerdo a los datos que ingresen desde

el sensor.

En las líneas 2 a 7 se generan los arreglo de puntos, que vienen a ser esferas

3D, por cada punto referencial de la mano graficada, en las líneas 12 a 20 se

aprecia un bucle que genera y renderiza las esferas por cada dedo y cada

parte del tendón.

Una vez que se creó la gráfica 3D de la mano es necesario declarar el método

que se llamó en cada cuadro de actualización el momento que se empezó a

ejecutar la aplicación, este método actualiza el gráfico en cada cuadro por

segundo.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

public void update(Hand hand) {

FXUtil.translate(palm, hand.palmPosition());

Iterator itFinger = hand.fingers().iterator();

Finger finger = null;

for (int i = 0; i < fingers.length; i++) {

finger = itFinger.next();

FXUtil.translate(fingers[i], finger.tipPosition());

FXUtil.translate(distal[i],

finger.bone(Type.TYPE_DISTAL).prevJoint());

FXUtil.translate(intermediate[i],

finger.bone(Type.TYPE_INTERMEDIATE).prevJoint());

FXUtil.translate(proximal[i],

finger.bone(Type.TYPE_PROXIMAL).prevJoint());

}

FXUtil.translate(metacarpal,

finger.bone(Type.TYPE_METACARPAL)

.prevJoint());

for (MergeJoint3D joint : joints) {

joint.update();

}

}

Para poder simular los tendones y generar una conexión entre las esferas y

de esta manera obtener una gráfica acorde con una mano humana, se utiliza

34

otro gráfico 3D nativo de JavaFx, los cuales son los cilindros como se observa

en la figura 19.

Figura 19. Cilindro con rotación eje Z

Dentro de la clase Hand3DCreatorUpdate fue necesario crear una subclase

que sirva para fusionar las figuras 3D utilizadas, en el caso de las esferas que

son los puntos referenciales de cada dedo de la mano así como la muñeca y

la palma, junto con los cilindros que vienen a representar las uniones entre los

puntos referenciales, lo que le da una forma más parecida al esqueleto de una

mano real.

La clase llamada MergeJoint3D contiene los atributos necesarios para realizar

esta fusión de objetos así como su constructor para atributos los objetos

principales en el objeto declarado.

1

2

3

4

5

6

7

8

9

10

11

12

13

private class MergeJoint3D {

private Sphere fromSphere;

private Sphere toSphere;

private Cylinder bone;

private Rotate joint;

public MergeJoint3D(Sphere fromSphere, Sphere

toSphere) {

this.fromSphere = fromSphere;

this.toSphere = toSphere;

this.joint = new Rotate();

this.bone = createBone(joint);

}

}

Se definió un método que crea la unión entre 2 esferas mediante un cilindro,

ubicándolo y configurando sus atributos como tamaño, color y acabado de

superficie de las imágenes en 3D.

1 private Cylinder createBone(Rotate joint) {

35

2

3

4

5

6

7

8

9

10

11

12

PhongMaterial material = new PhongMaterial();

material.setSpecularColor(Color.BLUE);

material.setDiffuseColor(Color.DARKBLUE);

Cylinder cylinder = new Cylinder();

cylinder.setRadius(2);

cylinder.setMaterial(material);

cylinder.getTransforms().add(joint);

return cylinder;

}

Dentro de la clase MergeJoint3D se encuentra también un método que se

utilizó para la actualización constante de las uniones con cilindros en la

visualización gráfica, este método realiza las funciones de translación y

rotación de las uniones para que la gráfica forme la mano, y es ejecutada cada

que se generan los puntos de referencia de las articulaciones de la mano.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

public void update() {

double dx = (float) (fromSphere.getTranslateX() -

toSphere.getTranslateX());

double dy = (float) (fromSphere.getTranslateY() -

toSphere.getTranslateY());

double dz = (float) (fromSphere.getTranslateZ() -

toSphere.getTranslateZ());

bone.setHeight(Math.sqrt(Math.pow(dx, 2) + Math.pow(dy, 2) +

Math.pow(dz, 2)));

bone.setTranslateX(fromSphere.getTranslateX());

bone.setTranslateY(fromSphere.getTranslateY() - bone.getHeight() / 2);

bone.setTranslateZ(fromSphere.getTranslateZ());

joint.setPivotY(bone.getHeight() / 2);

joint.setAxis(new Point3D(dz, 0, -dx));

joint.setAngle(180 - new Point3D(dx, -dy, dz).angle(Rotate.Y_AXIS));

}

Este método se ejecuta una vez que la función update de la clase principal

Hand3DCreatorUpdate se efectúa, de esta manera se obtiene en una primera

instancia las esferas de referencia de las articulaciones de los dedos para

después completar la gráfica con las conexiones mediante cilindros.

En la figura 20 es representado el algoritmo con el que se adquiere, actualiza

y envía los datos, mediante el movimiento cartesiano (X, Y y Z), cada que los

datos de un cuadro son adquiridos, para refrescar de nuevo la interfaz gráfica,

36

y volver a gráficar las posiciones, así como enviar los datos a el sistema de

comunicación donde inicia el control.

37

Figura 20. Flujo de aplicación con arquitectura MVC

38

DISEÑO ESPECIFICO SISTEMA ELECTRÓNICO Y DE

CONTROL

1. Sistema de Servo-Motores

En la figura 21 se esquematiza el servo motor de manera que sus medidas se

puedan reconocer a continuación.

Figura 21. Dimensiones de Servo Motor

(Robotzone, 2017)

Se utilizó cinco motores en el proyecto para poder mover los diferentes dedos

en el ensamble mecánico. Al tener una fuente de computador para alimentar

los servo-motores es necesario calcular la corriente que se necesita, para

asegurarse de que la salida a utilizar en la fuente de alimentación es la

correcta.

El modelo implementado en el prototipo físico viene a ser Turnigy 380MAX

Micro Servo (Metal Gear) según cita el autor este modelo fue el que

proporcionaba mayor torque, velocidad y menor tamaño (tabla 3), para

acoplarse al ensamble realizado. (Martínez, 2016)

Tabla 3. Datos de Servo-motor

2. Fuente de poder 12V3A y regulador de Voltaje

Corriente de alimentación

Marca Torque

(Kgf.cm)

Velocidad

(grados/s)

Dimensión

(mm)

Engrane

Metálico

Precio

(USD)

Turnigy 380MAX

Micro Servo

(Metal Gear)

4.1 60/0.16 A=13

M=22

H+G=33

J=37

SI 16.7

39

Debido a que solo se utilizó el sistema mecánico del proyecto de la mano

robótica, se debió realizar cálculos que se acoplen al sistema electrónico del

presente proyecto tomando como referencia los cálculos del autor en la tesis

de diseño del prototipo físico. (Martínez, 2016)

Para el cálculo de la corriente máxima consumida por los servomotores, se

considera la corriente con un voltaje de 5V que es el recomendado por el

proveedor y utilizado por el autor Martínez, para funcionar al torque máximo

en el motor.

Donde:

𝑇 = 𝑇𝑜𝑟𝑞𝑢𝑒

𝜔 = 𝑉𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝐴𝑛𝑔𝑢𝑙𝑎𝑟

𝑃 = 𝑃𝑜𝑡𝑒𝑛𝑐𝑖𝑎

𝐼 = 𝐶𝑜𝑟𝑟𝑖𝑒𝑛𝑡𝑒

𝑉 = 𝑉𝑜𝑙𝑡𝑎𝑗𝑒

𝑇 = 8.5 [𝐾𝑔𝑓 ∗ 𝑐𝑚]

𝝎 =𝟔𝟎[°]

𝟎. 𝟐[𝒔]

𝑻 = 𝟖. 𝟓 [𝑲𝒈𝒇 ∗ 𝒄𝒎] 𝟗. 𝟖[𝑵]

𝟏[𝑲𝒈]

𝟏[𝒎]

𝟏𝟎𝟎[𝒄𝒎]= 𝟎. 𝟖𝟑𝟑[𝑵 ∗ 𝒎]

𝝎 =𝟔𝟎

𝟎. 𝟐𝒔

𝝅

𝟏𝟖𝟎= 𝟓. 𝟐𝟑𝟓𝟗[

𝒓𝒂𝒅

𝒔]

𝑷 = (𝟓. 𝟐𝟑𝟓𝟗[𝒓𝒂𝒅

𝒔]) (𝟎. 𝟖𝟑𝟑 [𝑵 ∗ 𝒎]) = 𝟒. 𝟑𝟔𝟏𝟓[𝑾]

𝑰 =𝑷

𝑽=

𝟒. 𝟑𝟔𝟏𝟓[𝑾]

𝟔[𝑽]= 𝟎. 𝟕𝟐𝟔𝟗[𝑨]

La corriente requerida para los 5 motores es:

𝑰 = 𝟎. 𝟕𝟐𝟔𝟗[𝑨] ∗ 𝟓 = 𝟑. 𝟔𝟑[𝑨]

Se alimenta esta fuente con 110VAC de entrada con una frecuencia de 50/60

Hz, la fuente tiene las salidas de 5V con diferentes amperajes como son:

0.5[A], 2[A] y 14[A], con esta información se selecciona la salida que arroja un

voltaje de salida de 5VDC 14A para alimentar los servomotores.

3. MCU

La selección del Micro controlador Programable (Microcontroller Unit) se lo

realiza bajo los parámetros de comparativa: modelo, procesador, fabricante,

40

memoria flash, RAM/SRAM, EEPROM, reloj Interno, puertos digitales, puertos

analógicos, IDE (Entorno de desarrollo integrado), tamaño (mm) y precio ($).

Como se observa en la tabla 3, las mejores características se encuentran en

la placa Mbed NXP LPC1768 en cuanto a memoria, velocidad y tamaño viene

a ser la mejor opción sin embargo el precio es elevado sin mencionar que

sobrepasa las características necesarias para el proyecto el cual está

inclinado al control de servomotores y recepción de señales, por lo que esta

placa con MCU para control estaría subutilizando.

Las placas restantes: Arduino y Pingüino, por comparación de tamaño y

precio, así como la disponibilidad en el mercado local, también la capacidad

de almacenamiento del programa, como la memoria RAM.

En los dos procesadores es la misma, las características en pines digitales

con capacidad de utilizar PWM (para control de servo-motores) son suficientes

en las dos opciones.

La opción que se ajusta a las necesidades y alcance del proyecto sin

problemas es la placa de Arduino.

En la tabla 4 se presenta la comparativa de las diferentes placas con cada una

de sus características tomadas en cuenta para la finalización del proyecto.

41

Tabla 4. Comparativa placas con MCU para control

a) (Arduino LLC, 2015)

b) (Pinguino Shop, 2017)

c) (Mbed, 2010)

4. Comunicación Serial y transmisor RF (Master&Slave)

Para la comunicación entre el sistema de control de lazo abierto y el prototipo

físico se utilizó comunicación serial

La cual se puede cambiar para el envío directo mediante serial hacia el MCU

o mediante radiofrecuencia utilizando un emisor conectado mediante

protocolo UART con el ordenador.

En cuanto a la comunicación serial directa, se utilizó la librería serial para Java

RxTx, la que mediante una clase implementada permite al ordenador

comunicarse con cualquier dispositivo conectado mediante protocolo serial.

Para la comunicación mediante radiofrecuencia se escogió el protocolo

Zigbee por la apertura que tiene para poder crear una red Maestro esclavo

privada ocupando el adaptador de Xbee USB para el ordenador mediante

protocolo serial transmite automáticamente los datos obtenidos por el sensor

(Leap Motion) previamente encriptados para ser recibidos y des encriptados

por el MCU.

Características Arduino(a)

Pinguino (b)

Mbed NXP Sem.(c)

Modelo Nano 45K50 NXP LPC1768

Procesador ATmega328 PIC18F45K50 ARM Cortex-M3

core

Fabricante Microchip Atmel Microchip ARM Ltd

Memoria Flash 32 KB 32 KB 512 KB

RAM/SRAM 2 KB 2 KB 64 KB

EEPROM 1 KB 256 Bytes 4 KB

Reloj Interno 16 MHz 48 MHz 100 MHz

Puertos

Digitales

14 17 40

Puertos

Analógicos

8 5 6

IDE (Entorno

de desarrollo

integrado)

Arduino Pinguino The mbed Compiler

Tamaño (mm) 43.18x17.78 71x26 55.25x23.35

Precio ($) 12 20 70

42

La ventaja de este adaptador y de utilizar Xbee es la conexión directa con el

módulo FTDI embebido en el adaptador lo que agiliza la comunicación desde

la aplicación Java hacia el módulo transmisor Master Xbee.

Para configurar la red Zigbee de estos módulos se utilizó el software XCTU el

mismo que permite configurar y guardar los datos necesarios para la red P2P

que se utilizó, con esto se logra la radiodifusión del módulo maestro a los

esclavos en este caso existirá solo un esclavo.

En la figura 22 se aprecia que al abrir el software utilizado para configuración

de módulos Zigbee, XCTU automáticamente reconoce los dispositivos

seriales conectados gracias al adaptador USB Xbee, lo primero que se debe

realizar es elegir el módulo que se va a proceder a configurar.

Figura 22. Captura de Configuración Xbee Master&Slave 1

Una vez seleccionado el dispositivo, XCTU procede a cargar y leer el módulo,

al momento que el software tiene lista la interface, se procede a configurar el

canal para la radiodifusión en la opción ID – PAN ID.

Este número es un hexadecimal en el rango de 0 a FFFF, en este caso se ha

escogido el canal 777, los esclavos también deben ser configurados en el

mismo canal para poder ser compatibles en la comunicación; como también

43

se debe colocar la opción CE-Coordinator Enable en Enabled [1] para el

módulo Master y Disabled [0] para los esclavos (figura 23).


Como último paso en el módulo Master, se debe cambiar la opción DH-

Destination Address High a 0 y DL-Destination Address Low a FFFF, esto

permite a el modulo RF que se configure en modo de radiodifusión, y transmita

a todos los módulos RF que se encuentren en el mismo PANID (figura 24).

44


Para configurar el router o receptor dentro de la red de radiodifusión, se debe

colocar el mismo canal en ID-PANID como también JV-Channel Verification

se debe colocar la opción de Enabled[1] para que el dispositivo permita al

coordinador verficar el canal de funcionamiento, otra de las opciones que se

debe cambiar es la de CE-Coodinator Enable se debe colocar Disabled[0] de

esta manera se configura el dispositivo como esclavo (figura 25).

45


Una vez que los módulos están configurados, y su configuración se ha

cargado en cada uno de los dispositivos, se puede proceder a realizar pruebas

de la red de radiodifusión y verificar la velocidad y retraso de la señal.

Como se puede apreciar en la figura 26, para poder realizar las pruebas se

debe abrir dos instancias separadas del programa XCTU e iniciar con los

diferentes módulos en cada instancia del programa. La figura indica las

instancias, se selecciona el botón de Terminal (A) en las dos instancias y se

cierra la conexión (B) para empezar la radiodifusión.

Para efectos de pruebas XCTU permite programar un bucle infinito para envío

de paquetes insertando estos en la lista de paquetes de la interfaz gráfica del

programa (C), se inserta el tiempo de latencia entre paquetes enviados (D) en

este caso se coloca el intervalo en 400 milisegundos [ms].

46


El diseño de la figura 27 indica el esquemático de la conexión de cada uno de

los elementos en el diseño del sistema de comunicación para el prototipo

mecánico de la mano robótica.

Figura 27. Simulación de Sistema electrónico y de Control con ATMEGA328 - MCU Arduino

Nano

DIAGRAMA DE PROCESOS PARA RECEPCIÓN DE SEÑAL Y

CONTROL DE SERVOMOTORES EN MCU

47

El micro controlador forma un papel importante en el proyecto, como se puede

notar es el dispositivo encargad

UNIVERSIDAD TECNOLÓGICA...

Documents

Transcript of UNIVERSIDAD TECNOLÓGICA...