Herramienta para la enseñanza del uso de dispositivos interactivos de acceso limitado

(1)

Departamento de Ingenier´ıa de Sistemas y Computaci´

on

((Herramienta para la Ense˜

nanza del Uso de Dispositivos

Interactivos de Acceso Limitado))

TESIS QUE PRESENTA: Andr´es Roberto G´omez Vargas

PARA OBTENER EL T´ITULO DE:

Magister en Ingenier´ıa de Sistemas y Computaci´on

DIRECTOR DE TESIS: Pablo Alejandro Figueroa Forero

JURADO INTERNO:

Mario Fernando De La Rosa Rosero

JURADO EXTERNO:

Christian Orlando Benavides Erazo

(2)

RESUMEN

En este trabajo se presenta la motivación, diseño, desarrollo, ejecución de pruebas y resultados de un laboratorio virtual que permite interactuar con recursos de baja disponibilidad como son el Razer Hydra [1] y el 3D Connexion SpaceNavigator [2]. El laboratorio implementado permite grabar, editar y reproducir la interacción que se puede realizar con estos dispositivos, dándole la posibilidad al usuario de realizar pruebas de programación sobre dicha plataforma sin la necesidad de contar con los equipos. Se realizan pruebas con usuarios que se encuentran en un proceso de experimentación y aprendizaje sobre desarrollo de videojuegos, el cual tiene una duración de un mes y se realiza de forma totalmente en l´ınea v´ıa Internet. Se logra obtener resultados positivos, confirmando que existe un buen potencial para herramientas de este tipo. Se recopila una serie de oportunidades de mejora que se vislumbran a partir de los comentarios realizados por los participantes de las pruebas, y a partir de experiencia encontrada en la literatura.

(3)

ABSTRACT

In this document, it is presented the motivation, design, development, test and results of a virtual lab that permits to interact with resources of low availability like Razor Hydra [1] and 3D Connexion SpaceNavigator [2]. The lab implemented allows to record, to edit, and to playback interaction that can be made with this devices, which gives to the user the possibility to realize development tests even when he doesn’t have them. Trials where made with users that are in a process of experimenting and learning about videogames during one month. All the communication between the users is made via Internet. Positive results are obtained, which confirms the potential for this kind of tools. Based in comments made by participants of the test and in experience found in the literature, some improvement opportunities are recollected to take into account for future work.

(4)

Plantilla para tesis por David Luna se encuentra bajo una Licencia Creative Commons Atribuci´on-NoComercial-CompartirIgual 3.0 Unported

(5)

´

_{INDICE GENERAL}

RESUMEN II

ABSTRACT III

´_{INDICE GENERAL} _V

´_{INDICE DE TABLAS} _VIII

´_{INDICE DE FIGURAS} IX

1. INTRODUCCI ´ON 1

1.1. Contexto y Caracterizaci´on del Problema . . . 1

1.2. Formulaci´on de la Pregunta de Investigaci´on. . . 6

1.3. Objetivos . . . 6

1.3.1. Objetivo general . . . 7

1.3.2. Objetivos espec´ıficos . . . 7

2. MARCO TE ´ORICO 8 2.1. Laboratorios Virtuales . . . 8

2.2. Laboratorios Remotos . . . 9

2.3. Laboratorios en l´ınea . . . 10

2.4. Unity . . . 11

2.4.1. Plugins . . . 11

2.4.2. Edici´on de interfaz . . . 12

2.4.3. Persistencia . . . 13

2.5. VRPN . . . 14

2.5.1. Plugins para Unity . . . 15

2.6. Dispositivos para Interacci´on Hombre-M´aquina . . . 16

2.6.1. Razer Hydra . . . 16

2.6.2. 3DConnexion SpaceNavigator. . . 17

(6)

2.7. Interfaz de Editores de Audio y Video . . . 17

2.7.1. Audacity . . . 19

2.7.2. Adobe Premiere . . . 19

3. DISE ˜NO DEL PROTOTIPO 20 3.1. Estudio Preliminar: Plataforma de Pruebas Remotas en Kinect . . . 21

3.2. Justificaci´on de la Elecci´on de Tecnolog´ıas . . . 29

3.3. Definici´on de Requerimientos Funcionales . . . 30

3.4. Dise˜no de la Arquitectura . . . 30

3.5. Dise˜no de la Interfaz . . . 32

4. IMPLEMENTACI ´ON DEL PROTOTIPO 36 4.1. Actualizar VRPNWrapper . . . 36

4.2. Adecuaci´on de Plugin VRPNWrapper a las Necesidades del Proyecto . . . 39

4.2.1. Retirar capacidades innecesarias del plugin . . . 39

4.2.2. Implementar servicio de mensajer´ıa. . . 40

4.3. Implementar Funcionalidad para Grabar . . . 40

4.4. Implementar Funcionalidad para Reproducir. . . 40

4.5. Implementar Funcionalidad para Editar . . . 41

4.6. Implementar Escenas de Ejemplo . . . 41

4.6.1. Prefabs . . . 42

4.7. Grabaci´on de Datos de Prueba . . . 42

5. PRUEBAS DE USUARIO 43 5.1. Metodolog´ıa . . . 43

5.1.1. De.Vi.C.E. . . 43

5.2. Dise˜no . . . 45

5.2.1. Tareas especiales a realizar . . . 45

5.3. Realizaci´on . . . 51

5.4. Resultados Obtenidos . . . 51

5.4.1. Encuesta semana 2 . . . 51

5.4.4. Postmortem . . . 54

5.5. An´alisis . . . 56

6. CONCLUSIONES Y TRABAJO FUTURO 58

(7)

B. GRABACIONES REALIZADAS CON VRPN-TOOL 80

B.1. Razer Hydra . . . 80

B.1.1. Trackers . . . 80

B.1.2. An´alogos . . . 82

B.1.3. Botones . . . 82

B.2. 3DConnexion SpaceNavigator . . . 83

B.2.1. An´alogos . . . 83

B.2.2. Botones . . . 84

C. TUTORIAL VRPN-TOOL 85 C.1. ¿Qu´e es VRPN? . . . 85

C.1.1. ¿C´omo funciona VRPN? . . . 85

C.1.2. ¿C´omo facilita la interacci´on entre aplicaciones y dispositivos? . . . 86

C.2. ¿Cu´ales son los tipos de dispositivo en VRPN? . . . 86

C.3. ¿C´omo usar VRPN en Unity? . . . 87

C.4. ¿Cu´ales son los requerimientos para usar VRPN-Tool en Unity? . . . 87

C.5. ¿D´onde puedo encontrar el VRPN-Tool Package? . . . 88

C.6. ¿C´omo agregar VRPN-Tool en un proyecto? . . . 88

C.7. ¿C´omo usar VRPN-Tool en un proyecto? . . . 89

C.8. Prefabs Save y Play . . . 92

C.9. ¿D´onde puedo encontrar el servidor VRPN? . . . 93

C.10.No entiendo, ¿es posible un ejemplo pr´actico? . . . 93

C.11.¿C´omo puedo grabar y reproducir una grabaci´on?. . . 99

C.12.¿C´omo usar el VRPN Recordings Editor? . . . 104

C.13.Pero y ¿c´omo voy a hacer si no tengo acceso a los dispositivos del tema del mes? . . . . 108

C.14.¿D´onde puedo encontrar las grabaciones de ejemplo? . . . 109

C.15.¿Hay alguna explicaci´on completa de las funciones del VRPNEventManager? . . . 109

C.16.Algo no me funciona, tengo dudas, ¿d´onde pregunto? . . . 110

(8)

1.1. Conceptos con los que se ha definido el uso de la computaci´on en educaci´on.. . . 2

1.2. Conceptos con los que se ha definido el uso del Internet en educaci´on. . . 3

1.3. Ambientes de experimentaci´on. . . 4

1.4. Tipos de cursos en l´ınea. . . 5

5.1. Resultados de encuesta de la semana 2. . . 52

5.4. Resultados de encuesta postmortem para desarrolladores. . . 55

5.5. Resultados de encuesta postmortem para Dise˜no/Arte y M´usica/Sonido. . . 55

(9)

´

_{INDICE DE FIGURAS}

2.1. La ventana Inspector de Unity. . . 12

2.2. La ventana Animation de Unity. . . 13

2.3. Modelo de funcionamiento de UIVA. . . 15

2.4. Razer Hydra. . . 17

2.5. 3DConnexion SpaceNavigator. . . 18

2.6. Interfaz de Audacity. . . 18

2.7. Interfaz de Adobe Premiere. . . 19

3.1. Manejo de solicitudes en BackEnd de plataforma de pruebas remotas en Kinect. . . 22

3.2. Detalle de ejecuci´on de solicitudes en BackEnd de plataforma de pruebas remotas en Kinect.. . . 23

3.3. Lista de ejercicios que ofrece la plataforma. . . 24

3.4. Datos de entrada al abrirlos con el Kinect Studio.. . . 25

3.5. Plantilla de proyecto en Visual Studio. . . 25

3.6. P´agina para enviar fragmento a prueba. . . 26

3.7. Correo con mensaje en el que se indican las salidas que se generaron. . . 26

3.8. Ejemplo de pantallazo de respuesta. . . 27

3.9. Secuencia de pantallazos para comprender el comportamiento del fragmento de c´odigo. . 27

3.10. Componentes de la herramienta VRPN-Tool. . . 31

3.11. Detalle clase VRPNEventManager. . . 31

3.12. Parte superior de la interfaz de VRPN-Tool.. . . 32

3.13. Parte media de la interfaz de VRPN-Tool. . . 33

3.14. Parte inferior de la interfaz de VRPN-Tool. . . 33

3.15. Se puede arrastrar grabaciones a la l´ınea de tiempo, se puede arrastrar grabaciones dentro de la l´ınea de tiempo. . . 34

3.16. Interfaz para elegir sensores activos para grabaci´on de tipo tracker. . . 34

4.1. C/C++ ->Additional Include Directories. . . 38

4.2. Linker ->Additional Dependencies. . . 38

(10)

4.3. Linker ->Additional Library Directories. . . 39

5.1. Tareas propuestas para semanas 1 y 2 de De.Vi.C.E. . . 44

5.2. Tareas propuestas para semanas 3 y 4 de De.Vi.C.E. . . 44

5.3. Tema del evento De.Vi.C.E. Noviembre-Diciembre. . . 45

A.1. Uso de la Plataforma de Pruebas Remotas. . . 62

A.2. Satisfacci´on. . . 63

A.3. Resultado del Grupo Focal. . . 64

A.4. Resultado del Grupo Focal 2. . . 65

A.5. Facilidad de uso. . . 66

A.8. Aprendizaje y desempe˜no. . . 69

A.10.Resultado del Grupo Focal 6. . . 71

A.14.Motivaci´on. . . 75

A.15.Uso de la Plataforma de Pruebas Remotas. . . 76

A.16.Uso de la Plataforma de Pruebas Remotas 2. . . 77

A.17.Uso de la Plataforma de Pruebas Remotas 3. . . 78

(11)

CAP´

ITULO 1

INTRODUCCI ´

ON

En éste cap´ıtulo se va a presentar la pregunta de investigación que se propuso como proyecto de Tesis, en conjunto con el contexto que la motiva. Para esto primero se expone el contexto de la problemática a abordar, seguido por la pregunta de investigación que se ha formulado. Finalmente se establecen los objetivos que se han planteado para este proyecto.

1.1. Contexto y Caracterizaci´

on del Problema

Desde el nacimiento de la computación se ha buscado desde todos los campos del conocimiento la forma de hacer uso de ésta de la forma más eficiente y efectiva posible. Uno de los campos que le ha prestado gran interés a la posibilidad de explotar las capacidades y caracter´ısticas de la computación es el campo de la educación, experimentando con este recurso de diferentes maneras, dando como resultado al nacimiento de diferentes conceptos que han cambiado de acuerdo a las posibilidades de la tecnolog´ıa y al enfoque que se le ha dado a su uso (Tabla1.1).

Con la llegada del Internet se generó una nueva familia de conceptos que tienen como objetivo el enmarcar el uso de este nuevo recurso en la educación (Tabla1.2). Entre estos conceptos se encuentra el de e-Learning, el cual tiende a cubrir todos los usos que se le dan al uso de Internet como herramienta para la enseñanza y el aprendizaje. Este concepto es definido por Marc Rosenberg en 2001 [4] como “el uso de tecnolog´ıas Internet para la entrega de un amplio rango de soluciones que mejoran el conocimiento y el rendimiento. Está basado en tres criterios fundamentales: 1. El e-Learning trabaja en red, lo que lo hace capaz de ser instantáneamente actualizado, almacenado, recuperado, distribuido y permite compartir instrucción o información. 2. Es entregado al usuario final a través del uso de ordenadores utilizando tecnolog´ıa estándar de Internet. 3. Se enfoca en la visión más amplia del aprendizaje que va más allá de los paradigmas tradicionales de capacitación”. En 2014 el grupo de investigación GRIAL (GRupo de Investigación en InterAcción y e-Learning) de la Universidad de Salamanca, tras hacer una revisión de la evolución del concepto de e-Learning [4] proponen redefinirlo

(12)

Tabla 1.1: Conceptos con los que se ha definido el uso de la computación en educación [3]. Acrónimo

(Por su nombre en

ingl´es)

Concepto Enfoque del concepto

CAI (Computer-Assisted Instruction)

Ense˜nanza Asistida por Computadora

Uso de la computadora para facilitar y evaluar el aprendizaje, con enfoque en la instituci´on de ense˜nanza.

ALE (Artificial Learning Environments)

Ambientes

Artificiales de Aprendizaje

Uso de un artefacto como un mediador en el aprendizaje. CAL (Computer-Assisted Learning) Aprendizaje Asistido por Computadora

Enfocado en los individuos m´as que en tareas.

REAL (Rich

Environments for Active Learning)

Ambientes Ricos para Aprendizaje Activo

Responsabilidad e iniciativa del estudiante. Generación de actividades de aprendizaje. Contextos de aprendizaje auténticos. Estrategias de valoración auténticas. Apoyo cooperativo. CFL (Computer-Facilitated Learning) Aprendizaje Facilitado por Computadora

Emula la ense˜nanza guiada por un profesor, contrastando con la aproximaci´on constructivista.

El ambiente tiene como objetivos el agrupar aplicaciones en categor´ıas de acuerdo a su funcionalidad, y resaltar los procesos y resultados que se espera que sean proporcionados por cada una de estas categor´ıas.

SRE (Self-Regulatory Efficacy)

Eficacia Auto-Regulada

Valoraci´on independiente del estudiante de su habilidad de aprendizaje auto-regulada. CAE (Computer-Assisted

Education)

Educaci´on Asistida por Computadora

Usos de la computadora. Producci´on de material.

Uso de la computadora de parte del estudiante.

CBE (Computer-Based Education)

Educaci´on Basada en Computadora

Variedad de usos de la computadora.

CMI (Computer-Managed Instruction) Ense˜nanza Administrada por Computadora

(13)

Tabla 1.2: Conceptos con los que se ha definido el uso del Internet en educaci´on [3]. Acr´onimo

(Por su nombre

en ingl´es)

Concepto Enfoque del concepto

e-Learning Aprendizaje Electr´onico

Uso de la Red para hacer disponible informaci´on, sin importar el momento y el lugar.

LMS (Learning Management Systems) Sistemas de Administraci´on del Aprendizaje

Registro, seguimiento y entrega de contenido a estudiantes.

Reporta a instructores el progreso del estudiante, resultados de evaluaciones y comparaci´on de habilidades.

“Incluye contenidos para el aprendizaje e interacciones con los profesores”.

LCMS (Learning Content Management Systems) Sistemas de Administraci´on de Contenido para el Aprendizaje

Administradoras de contenido como plataformas de lanzamiento para contenido de terceros que la organizaci´on podr´ıa comprar o encargar.

SDL (Self-Directed Learning)

Aprendizaje Auto-Dirigido

Se enfoca en el m´etodo de ense˜nanza-aprendizaje. “El estudiante asiste a clase solo para registrar el momento, lugar, tema y para alterar el orden de las clases a las que asiste”.

“El n´ucleo de aprendizaje es los estudiantes y cada servicio ofrecido por el e-Learning”.

ILM (Internet-based learning medium)

Medio de

aprendizaje basado en Internet

“Los objetivos principales de usar un ILM son el apoyar y mejorar el aprendizaje del estudiante”.

CSCL (Computer Support for Collaborative Learning) Soporte por Computadora para el Aprendizaje Colaborativo

Las computadoras facilitan, aumenta y redefinen el apoyo al aprendizaje en grupos.

MOOC (Massive Open Online Course)

Curso en L´ınea Masivo y Abierto

Difusión gratuita del contenido de cursos para un uso global a través de la Red. Integra la conectividad de las redes sociales, la disponibilidad de un experto reconocido en un campo de estudio, y una colección de recursos en l´ınea a los que se puede acceder de forma gratuita.

(14)

Tabla 1.3: Ambientes de experimentaci´on [5]. Recurso real Recurso simulado

Acceso local Laboratorio presencial Laboratorio virtual individual Acceso remoto Laboratorio remoto Laboratorio virtual compartido

como “proceso formativo, de naturaleza intencional o no intencional, orientado a la adquisición de una serie de competencias y destrezas en un contexto social, que se desarrolla en un ecosistema tecnológico en que interactúan diferentes perfiles de usuarios que comparten contenidos, actividades y experiencias y que, en situaciones de aprendizaje formal, debe ser tutelado por actores docentes cuya actividad contribuya a garantizar la calidad de todos los factores involucrados”.

La teor´ıa alrededor del e-Learning se puede dividir en tres componentes de acuerdo a Dabbagh [3], que son: “Tecnolog´ıas para el aprendizaje”, “Estrategias de Enseñanza” y “Modelos pedagógicos”. Dentro del componente de las “Tecnolog´ıas para el aprendizaje”, podemos ubicar los diferentes tipos de recursos multimedia para apoyar la enseñanza y el aprendizaje en ambientes virtuales [4], los cuales en educación se pueden clasificar como tecnolog´ıas de redes sociales, tecnolog´ıas de aprendizaje basado en juegos, simulaciones y otros. A partir de estos recursos multimedia se ha generado una serie de aproximaciones para apoyar el aprendizaje, las cuales se pueden clasificar como: Herramientas de aprendizaje colaborativo, los sistemas de administración del aprendizaje, herramientas de generación de contenido multimedia, los cursos en l´ınea masivos y abiertos, las redes sociales, herramientas de aprendizaje basadas en juegos y narración de historias, simulación, y otros [4].

En el área de simulación se puede encontrar un recurso conocido como laboratorios en l´ınea, los cuales son ambientes de experimentación en los cuales los estudiantes pueden practicar y experimentar con los conocimientos adquiridos, de forma que se suelen usar como complemento o reemplazo de los laboratorios que se utilizan en la educación tradicional para permitir interactuar con los sistemas f´ısicos reales. Es as´ı que los ambientes de experimentación pueden ser clasificados de acuerdo a la forma en que se accede a los mismos (acceso remoto o acceso local) y a la naturaleza del recurso (simulación o real) (Tabla1.3) [5].

Cada uno de estos tipos de ambientes de experimentaci´on tiene una serie de elementos a favor y en contra de acuerdo al tipo de recurso del que hace uso, siendo los siguientes los m´as importantes:

Recurso real: Cuando se hace uso de un recurso real se tiene un l´ımite en tiempo y espacio proporcional a la disponibilidad del recurso real con el que se interact´ua. Al ser un recurso real, los resultados que se obtienen corresponden a la realidad.

Recurso simulado: Cuando se hace uso de un recurso simulado no existe un l´ımite en tiempo o espacio. Al ser un recurso simulado, los resultados pueden variar un poco con respecto a la realidad.

(15)

Tabla 1.4: Tipos de cursos en l´ınea [6]. Proporci´on del

contenido que es

puesto en l´ınea

Tipo de curso Descripci´on t´ıpica

0 % Tradicional Curso que no hace uso de tecnolog´ıa en l´ınea el contenido es entregado de manera escrita u oral. 1 % a 29 % Facilitado por la

Red

Curso que usa tecnolog´ıa basada en la Red para facilitar lo que es esencialmente un curso presencial. Usa un CMS (sistema de administración de cursos por sus siglas en inglés) o páginas web para por ejemplo publicar el programa del curso y tareas.

30 % a 79 % Hibrido o

combinado

Curso que combina la entrega de contenidos v´ıa online y presencial. Una proporci´on sustancial del contenido es entregado en l´ınea, normalmente hace uso de discusiones en l´ınea y normalmente tambi´en tiene clases presenciales.

+80 % En l´ınea Un curso donde la mayor´ıa o todos los contenidos son entregados en l´ınea. Normalmente no tiene clases presenciales.

(16)

clasificar en cuatro diferentes grupos, dependiendo de la proporci´on del contenido que es puesto en l´ınea (Tabla1.4) [6].

En la Universidad de los Andes, como parte de un proyecto de innovación educativa con TIC [7], se rediseñó e implementó un curso de Ambientes Interactivos en 3D para modalidad combinada o h´ıbrida. Dicho curso, cuando se realiza de forma tradicional, suele tener en su programa la realización de proyectos en el laboratorio, los cuales deben hacer uso de dispositivos para interacción hombre-máquina [8]. Al rediseñar el curso se vio la necesidad de ofrecer un nuevo ambiente de experimentación que les permitiera a los estudiantes realizar ejercicios prácticos que involucren dispositivos para interacción hombre-máquina desde ubicaciones por fuera del campus universitario. Al revisar la literatura y el mercado disponible, se encontró que si bien existe una amplia variedad de laboratorios virtuales y remotos diseñados para su uso en áreas de las ciencias y las ingenier´ıas, no existe experiencia con ambientes de experimentación para aprender a hacer uso de dispositivos de interacción hombre-máquina.

Teniendo en mente la falta de laboratorios en l´ınea diseñados para aprender a hacer uso de dispositivos de interacción hombre-máquina, se realizó el diseño e implementación de un laboratorio remoto para aprender a hacer uso del dispositivo Kinect de Microsoft [9]. Este ambiente de experimentación fue puesto a prueba durante la primera ejecución del curso de Ambientes Interactivos 3D en modalidad combinada o h´ıbrida, el cual se realizó durante la primavera de 2015 (primer semestre). De los resultados obtenidos (AnexoA), se resaltó por parte de los estudiantes que si bien la plataforma de pruebas es útil para la experimentación con el dispositivo Kinect, existen algunos inconvenientes por el hecho de tener que salir del ambiente de desarrollo para hacer pruebas, y por el tiempo de respuesta del sistema que se generaba por ser un laboratorio remoto de uso compartido.

1.2. Formulaci´

on de la Pregunta de Investigaci´

on

De los resultados obtenidos en la experiencia del curso de Ambientes Interactivos 3D con el laboratorio remoto para el dispositivo Kinect de Microsoft, se concluyó que hace falta un ambiente de experimentación que permita superar inconvenientes que suelen ser inherentes de los laboratorios remotos, pero en lo posible sin perder las ventajas que ofrece un laboratorio de este tipo. Con esta conclusión en mente surge la pregunta de investigación que ha guiado el desarrollo de este trabajo de Tesis: ¿Una herramienta integrada al ambiente de desarrollo que permita grabar, editar y reproducir de forma local los datos generados por un dispositivo de interacción hombre-máquina puede ser un apoyo eficaz para la enseñanza/aprendizaje de la forma de uso de este tipo de dispositivos?

1.3. Objetivos

A partir de la pregunta de investigaci´on, se ha formulado un objetivo general y una serie de objetivos espec´ıficos para este proyecto.

(17)

1.3.1. Objetivo general

El objetivo principal que se pretende abordar con esta tesis es el revisar la efectividad de facilitar el aprendizaje del uso de dispositivos de interacci´on hombre-m´aquina mediante un sistema que permita hacer pruebas con datos generados por el mismo dispositivo, sin que esto implique que se deba desarrollar de manera distinta a como se har´ıa para el dispositivo f´ısico.

1.3.2. Objetivos espec´ıficos

A partir de este objetivo principal se desprende la siguiente lista de objetivos espec´ıficos:

1. Se desea probar que se puede desarrollar una herramienta de pruebas integrada al ambiente de desarrollo que permita grabar, editar y reproducir la información generada por un dispositivo de interacción hombre-máquina.

2. Se desea probar que es posible que el desarrollo realizado por el estudiante para realizar pruebas con datos grabados, también pueda ser usado por el estudiante para realizar pruebas con el dispositivo real. Esto quiere decir que la herramienta desarrollada debe permitir que con el mismo código el usuario pueda ser capaz de realizar pruebas tanto con los datos grabados, como con el dispositivo conectado directamente cuando éste exista.

3. Se desea probar que el estudiante puede aprender a programar para un dispositivo de interacción hombre-máquina de manera efectiva al poner a su disposición la herramienta desarrollada, un tutorial que explique el uso de la herramienta y del dispositivo, y grabaciones previamente realizadas con el dispositivo.

4. Se desea probar que la herramienta desarrollada puede ser usada de manera efectiva aunque toda la enseñanza se haga en l´ınea y el estudiante nunca haga uso del dispositivo de interacción hombre-máquina de forma directa.

(18)

MARCO TE ´

ORICO

Al revisar la bibliograf´ıa se puede encontrar que en torno a la idea de laboratorios en l´ınea se ha hecho una amplia investigaci´on y se han implementado una gran cantidad de ellos. En este cap´ıtulo se va a exponer inicialmente una revisi´on de la literatura existente sobre laboratorios virtuales, seguida por la literatura sobre laboratorios remotos y la literatura sobre laboratorios en l´ınea en general.

Más adelante se va a hacer una revisión de las tecnolog´ıas que se usaron para el desarrollo del prototipo con el que se hicieron las pruebas destinadas a responder la pregunta de investigación. Para esto primero se describe el motor de videojuegos Unity junto con algunas de sus caracter´ısticas y capacidades más relevantes para el proyecto a realizar. Enseguida se describe VRPN junto a una revisión de los plugins disponibles para poderlo usar en conjunto con Unity. Luego se hace una descripción de las caracter´ısticas de los dispositivos de Interacción Hombre-Máquina para los que se va a desarrollar la herramienta, y por último se hace una revisión de la interfaz y los protocolos de uso que se utilizan en aplicaciones de edición de audio y/o video.

2.1. Laboratorios Virtuales

De acuerdo a la clasificaci´on realizada por Bencomo de los ambientes de experimentaci´on [5], los laboratorios virtuales son aquellos que permiten de forma local o remota el acceso a un modelo simulado del recurso con el que se quiere experimentar.

De este tipo de laboratorios se puede encontrar una gran variedad de ejemplos. Para su uso en educación primaria y media se encuentran casos como el de un laboratorio virtual de qu´ımica que se diseñó y desarrolló de manera coordinada con los contenidos preestablecidos en el curr´ıculum para las escuelas de secundaria en Turqu´ıa [10], siendo éste un factor importante a tener en cuenta para mejorar la efectividad del producto desarrollado. Y es precisamente en el área relacionado con la qu´ımica donde se encuentra una mayor cantidad de ejemplos de laboratorios virtuales para estudiantes de todos los niveles de educación [11].

(19)

Al revisar el nivel de educación universitario se encuentran nuevos ejemplos de laboratorios virtuales para qu´ımica como herramienta para permitir que los estudiantes se preparen antes de enfrentarse al laboratorio real [12], permitiendo que los estudiantes se familiaricen con el mismo, aunque sin lograr el objetivo de eliminar el estrés que produce el enfrentarse al uso de laboratorios reales. También se encuentran ejemplos de laboratorios en otras áreas del conocimiento, en especial en electrónica, como el de un laboratorio virtual de instrumentación y medición [13] con el cual se observa que si bien es útil un laboratorio de este tipo, no deja de tener limitaciones dependiendo de qué tan completo y complejo sea el modelo de simulación con el que se trabaja; y el ejemplo de un laboratorio virtual de diseño digital que permite realizar un primer acercamiento a este tipo de tareas [14]. En otros campos también se usan laboratorios para familiarizar al usuario con el uso de la instrumentación, como es el caso de un laboratorio virtual de herramientas de perforación para un programa universitario de maquinaria [15]; o se crean herramientas especiales para el diseño, desarrollo e implementación de laboratorios virtuales por parte de los profesores [16].

En el campo espec´ıfico de la computación a nivel universitario encontramos que también se ha hecho un uso extensivo de los laboratorios virtuales. Es as´ı que se encuentran ejemplos exitosos de laboratorios diseñados para apoyar la enseñanza de programación básica [17, 18] y la enseñanza de temas base como la lógica de compuertas [19], como también de temas más espec´ıficos y avanzados como la recuperación de información [20], el desempeño de sistemas de Entrada/Salida en aplicaciones [21], tecnolog´ıa dirigida a la conectividad en veh´ıculos [22], conceptos de seguridad en Java [23], y redes [24], entre otros. Es de resaltar que estos laboratorios para temas avanzados tienden a ser usados no solo en la enseñanza y aprendizaje, sino también en tareas de investigación y pruebas conceptuales.

Además de ejemplos y experiencias con laboratorios virtuales, la literatura tiene una amplia cantidad de estudios dirigidos a revisar las ideas y conceptos que pueden servir de apoyo a estos ambientes de experimentación. Entre estos se encuentran la herramienta para la construcción de experimentos virtuales en ambientes 3D para qu´ımica que hab´ıamos mencionado anteriormente [11], un sistema de aprendizaje colaborativo en el entorno de un laboratorio virtual [25] en el que se resalta la importancia del sincronismo de la interacción, y un modelo de evaluación para laboratorios virtuales para la enseñanza de la qu´ımica [26] en el que se resalta cómo los laboratorios son apropiados para algunos tipos de aprendiz mientras que para otros no tanto.

2.2. Laboratorios Remotos

De acuerdo a la clasificaci´on realizada por Bencomo de los ambientes de experimentaci´on [5], al pasarse del uso local o remoto de un modelo simulado de los recursos, al uso de los recursos f´ısicos de manera remota, se llega a aquellos laboratorios conocidos como laboratorios remotos.

Como en el caso de los laboratorios virtuales, existe una amplia variedad de ejemplos de laboratorios remotos en todos los niveles de educación. En educación primaria se encuentra el ejemplo de un laboratorio remoto [27] que permite a los estudiantes el entender mediante la observación el

(20)

comportamiento de circuitos electrónicos. En educación universitaria se encuentran ejemplos que cubren diferentes campos de las ciencias [28, 29] en los que se concluye que este tipo de laboratorios pueden ser de especial importancia para empoderar a estudiantes con discapacidades, pero que deben ser diseñados pensando en que son diferentes a los laboratorios presenciales. A nivel de investigación se encuentra un ejemplo particular que lleva el concepto de compartir un recurso limitado y escaso a su mayor expresión, compartiendo una gran base de datos multinacional entre varios investigadores de manera remota, permitiendo la construcción del mismo recurso de forma colaborativa [30].

En el ´area espec´ıfica de la ingenier´ıa se encuentra una amplia cantidad de ejemplos en torno a las ´

areas de electrónica y mecánica, que contrastan con la falta de ejemplos en áreas de la computación. Se encuentran ejemplos de laboratorios remotos como apoyo a la enseñanza de temas como la mecatrónica [31], control [32,33], motores AC [34], microcontroladores [35] y sistemas electro-neumáticos [36], entre otros. En algunos de estos ejemplos se resalta de nuevo el hecho de que es mejor usar un laboratorio remoto como un complemento y no como un reemplazo de los laboratorios presenciales [32].

Para revisar las ideas y conceptos que pueden servir de apoyo a estos ambientes de experimentación también existe una amplia literatura, entre la que resalta el diseño y desarrollo de plataformas que permiten reunir, integrar y presentar conjuntos de laboratorios remotos de forma abierta [37], de forma conjunta entre instituciones educativas [38], y de forma espec´ıfica para laboratorios del área de electrónica (como muestra de la importancia que tiene este tipo de laboratorios en esta área) [39]. Además del desarrollo de estas plataformas se ha revisado enfoques para extender el acceso de laboratorios en ciencia e ingenier´ıa para personas discapacitadas [40], métodos para permitir conducir experimentos remotos con acceso multiusuario [41], y arquitecturas para experimentos remotos que protejan el hardware que se usa de posibles daños [42], entre otros.

2.3. Laboratorios en l´ınea

Además de ejemplos de laboratorios virtuales y remotos, también existen ejemplos del uso de estas dos plataformas de forma conjunta en diferentes áreas como la qu´ımica [43], la electrónica y la óptica [44], la robótica [45] y la mecatrónica [46]. Se resalta la posibilidad que brinda la combinación de estos dos tipos de ambientes de experimentación para explorar formas innovativas de enseñanza [43], como por ejemplo el usar los laboratorios virtuales como herramienta de prueba y error que permita al estudiante prepararse antes de experimentar con el hardware real [45]. Uno de los objetivos que se tiene para este tipo de ambientes combinados de experimentación es la posibilidad de comercializar la plataforma de manera que sirva como herramienta de actualización para los empleados de empresas de tecnolog´ıa [46], al ser plataformas que se pueden estar actualizando constantemente, lo que podr´ıa responder a la necesidad que tienen este tipo de empresas de tener empleados que posean conocimiento del estado del arte del área en que trabajan.

Alrededor de los conceptos y las ideas que existen sobre la combinaci´on de estos dos tipos de laboratorios tambi´en existe una gran cantidad de estudios, que van desde experiencias en el

(21)

levantamiento de requerimientos [47] y recomendaciones de diseño [48], hasta modelos de evaluación para este tipo de ambientes de experimentación [49]. De estos se pueden sacar conclusiones como la importancia de tener en cuenta la sostenibilidad, mantenibilidad y extensibilidad [48], y la relevancia de proveer una interfaz apropiada y la posibilidad de discutir entre los estudiantes [49]. Esto se ve complementado por el diseño de infraestructuras para almacenar y administrar repositorios de laboratorios tanto virtuales como remotos [50].

Para finalizar es interesante revisar las comparaciones que se hacen entre laboratorios virtuales, remotos y presenciales [51], de las que se puede concluir que no se encontró diferencias significativas, aunque se puede notar que los laboratorios que ofrecen datos reales generan mejores resultados [52]. Además se observa que es mejor promover el trabajo individual cuando se hace uso de laboratorios remotos [52]. Es interesante ver teor´ıas en que se expone la posibilidad de que el ciclo de vida de los ambientes de experimentación se comporte de manera similar a como funciona la evolución de las especies, resaltando que solo aquellos laboratorios más fuertes (mejor diseño y más constancia en su desarrollo y actualización) se mantienen en uso a lo largo del tiempo [53].

2.4. Unity

Unity es una plataforma de desarrollo flexible y poderosa para crear juegos y experiencias interactivas 3D y 2D multiplataforma. Es un ecosistema completo para todo aquel que busque desarrollar un negocio a partir de la creaci´on de contenido de alta gama y conectarse con sus jugadores y clientes m´as fieles y entusiastas [54].

2.4.1. Plugins

En Unity normalmente se hace uso de scripts para implementar las funcionalidades, pero se puede incluir tambi´en c´odigo creado por fuera de Unity en la forma de un plugin. Hay dos tipos de plugins que se pueden usar en Unity: Plugins Administrados y Plugins Nativos.

Los Plugins Administrados son ensambles administrados .NET creados con herramientas como Visual Studio o MonoDevelop. Ellos contienen únicamente código .NET lo que significa que no pueden acceder a ninguna caracter´ıstica que no se encuentre soportada por librer´ıas .NET. Es importante tener en cuenta que el código administrado es accesible para las herramientas .NET estándar de las que Unity hace uso para compilar sus scripts, por lo que es poca la diferencia en uso entre código de Plugins Administrados y código de scripts de Unity, a excepción del hecho de que los plugins son compilados por fuera de Unity por lo que los archivos fuente pueden no encontrarse disponibles.

Los Plugins Nativos son librer´ıas de c´odigo nativo que suelen ser espec´ıficos para una plataforma. ´

Estos pueden acceder a caracter´ısticas como llamados del sistema operativo y librer´ıas de c´odigo de terceros que de otra manera no estar´ıan disponibles en Unity. Es importante tener en cuenta que estas librer´ıas no son accesibles para las herramientas de Unity de la misma forma en que lo son las librer´ıas administradas. Por ejemplo, si se olvida agregar un archivo de un plugin administrado al proyecto, lo

(22)

Figura 2.1: La ventana Inspector de Unity.

que se recibe son mensajes de error est´andar del compilador, mientras que si se hace lo mismo con un plugin nativo, solo se ve un reporte de error cuando se trata de correr el proyecto [55].

2.4.2. Edici´

on de interfaz

Unity permite extender el editor con inspectores y ventanas personalizados, adem´as de permitir definir el c´omo las propiedades son presentadas en el inspector con Property Drawers personalizados [56].

Inspector

La forma en que se presentan los diferentes componentes en Unity se puede modificar mediante una caracter´ıstica conocida como Custom Editors o Editores Personalizados. El objetivo de esta caracter´ıstica es permitir que se modifique mediante código la forma en que la interfaz gráfica del editor presenta los diferentes componentes en el Inspector de Unity, lo cual se realiza mediante las mismas herramientas con las que se hac´ıa anteriormente las interfaces gráficas en Unity (Figura 2.1) [57].

(23)

Figura 2.2: La ventana Animation de Unity.

Editor de ventanas

En Unity existe la posibilidad de construir cualquier cantidad de ventanas personalizadas para el editor. Estas ventanas se comportan igual que las dem´as ventanas que hacen parte del editor de Unity de forma predeterminada como lo son la del Inspector, Escena, Consola y dem´as. Esto es posible gracias a que Unity ofrece las mismas herramientas con las que ellos mismos construyen la interfaz original (Figura2.2) [58].

2.4.3. Persistencia

Unity ofrece tres métodos básicos para almacenar información, con un enfoque especial hacia la posibilidad de almacenar información para las aplicaciones que se desarrollan en su plataforma; al tratarse principalmente de juegos, se trata de mantener información de una escena a otra (por ejemplo para llevar un seguimiento del avance del jugador) o de mantener información de una ejecución a otra (por ejemplo para mantener las preferencias del jugador). En ambos casos la cantidad de información que se busca mantener es pequeña, por lo que para contenido más grande se debe usar métodos como la serialización [59].

Serializaci´on

La serializaci´on de “cosas” es parte del n´ucleo de Unity ya que muchas de sus caracter´ısticas se encuentran construidas sobre este sistema:

La ventana del inspector: La ventana del inspector no revisa directamente cada componente para conocer que valores tienen sus propiedades. Lo que hace es pedirle al objeto que se serialice y enseguida ella procede a presentar la informaci´on serializada.

(24)

pueden mantener Pre-Fabricados para su posterior uso. Internamente un Prefab est´a compuesto por los datos serializados de uno o m´as objetos y sus componentes.

Instanciación: Cuando se hace un llamado a la función Instantiate() para cualquier tipo de objeto, lo que se hace es serializar el objeto, crear un nuevo objeto y des-serializar la información en dicho nuevo objeto.

Grabar: Es posible solicitarle a Unity que guarde las escenas mediante serializaci´on.

Cargar: La posibilidad de cargar proyectos creados con versiones anteriores de Unity se da gracias al sistema de serializaci´on.

Recarga en caliente de código en el editor: Siempre que se hace un cambio en código del editor (Edición de la interfaz), todas las ventanas del editor son serializadas y se destruyen. Una vez realizado esto se descarga el antiguo código del editor, se carga el nuevo código del editor, se recrean las ventanas y se des-serializa los datos de regreso a las nuevas ventanas.

Resource.GarbageCollectSharedAssets(): Este es el colector de basura nativo de Unity, el cual es un poco diferente al colector de basura original de C#. El colector de basura nativo de Unity hace uso del serializador para reconocer qu´e elementos que se encontraban en una escena ya no hacen parte de la siguiente escena y por lo tanto deben ser descargados.

El sistema de serializaci´on est´a escrito en C++ y se usa en todos los tipos internos de objetos de Unity [60].

2.5. VRPN

La Red de Periféricos de Realidad Virtual (Virtual-Reality Peripherical Network) es un conjunto de clases dentro de una librer´ıa y un conjunto de servidores que están diseñados para implementar una interface (para la cual la red le sea transparente) entre aplicaciones y el conjunto de dispositivos f´ısicos usados en un sistema de realidad virtual. La idea es tener un computador u otro anfitrión para cada estación de realidad virtual que controla los periféricos. VRPN provee las conexiones entre la aplicación y todos los dispositivos usando la clase-de-servicio adecuada para cada tipo de dispositivo que comparte esta conexión. La aplicación no necesita conocer la topolog´ıa de la red. Se debe notar que es posible usar VRPN con todos los dispositivos conectados directamente a la máquina en la que la aplicación está corriendo, haciendo uso de programas de control separados o corriendo todo como un solo programa.

VRPN también provee una capa de abstracción que hace que todos los dispositivos de la misma clase base se vean igual; por ejemplo, todos los dispositivos de tracking se ven como si fueran del tipo vrpn Tracker. Esto simplemente significa que todos los trackers producen el mismo tipo de reportes. Al mismo tiempo, es posible para una aplicación que requiere acceso a caracter´ısticas especiales de

(25)

Figura 2.3: Modelo de funcionamiento de UIVA1_.

un dispositivo de tracking el derivar una clase que se comunica con este tipo de tracker. Si esta clase especializada se usara con un tracker que no cuenta con este tipo de caracter´ıstica especial, los comandos especializados ser´ıan ignorados por el tracker. Los tipos actuales del sistema son Análogo, Botón, Selector (Dial), Dispositivo de Fuerza, Generador de Imágenes, Sonido, Texto y Tracker. Cada uno de estos abstrae un conjunto de semánticas para un cierto tipo de dispositivo. Existe uno o más servidores para cada tipo de dispositivo y una clase propia del cliente para leer los valores del dispositivo y controlar su operación [61].

2.5.1. Plugins para Unity

Para hacer uso de VRPN en Unity se debe tener un Plugin que lo permita. Se hizo una revisi´on de los plugins disponibles y se encontraron los siguientes:

VRPNWrapper [62]: El plugin VRPNWrapper es una sección del proyecto UART (Unity AR Toolkit) del Augmented Environments Laboratory del Georgia Institute of Technology. Éste tiene la opción de comunicarse v´ıa VRPN con dispositivos de tipo Tracker, Análogo y Botón, de manera remota o local. En caso de tratarse de un dispositivo que se encuentra localmente, el plugin se encarga de levantar el servidor necesario para éste. Este plugin tiene la ventaja de realizar una conexión directa entre el servidor VRPN y el cliente VRPN de forma idéntica a como se hace por fuera de Unity, lo cual se logra gracias a que el plugin está implementado directamente en C++ nativo. Hasta hace poco esto era una desventaja ya que solo en versiones profesionales de Unity se pod´ıa usar este tipo de plugins, pero desde la versión 5 de Unity esta posibilidad se encuentra disponible en la versión gratuita del motor. Lamentablemente desde 2011 no recibe actualizaciones, y tiene un sistema de mensajer´ıa incompleto.

UIVA [63]: UIVA (Unity Indie VRPN Adapter) es un middleware basado en sockets para adaptar VRPN a la versi´on Indie del motor de videojuegos Unity. ´Este consiste de un cliente y de un servidor. El cliente UIVA es un archivo DLL que reside en el motor de juegos Unity, y expone algunas funciones

(26)

de recolección de datos para los scripts C# que lo deseen usar. El servidor UIVA contiene un cliente VRPN que se comunica con el servidor VRPN para obtener los datos actuales del sensor, lo cual usará para responder a las solicitudes del cliente UIVA. Este plugin se desarrolló teniendo en mente el brindar una alternativa para aquellos que no pudieran usar VRPNWrapper por no tener la licencia profesional de Unity. Esto se logra al sacrificar parcialmente el rendimiento al agregar una capa extra (el servidor UIVA) a la comunicación entre la aplicación y el servidor VRPN (Figura 2.3). Tiene una limitada cantidad de dispositivos para la cual funciona, aunque se puede extender mediante instrucciones que provee el desarrollador. Permite comunicarse con dispositivos de tipo Tracker, Análogo y Botón pero no usa un modelo Publicador-Suscriptor como el que se suele usar en VRPN.

VRPN2Unity [64]: Proyecto personal de un integrante del Departamento de Ciencias de la Computación de la Universidad de Wyoming. Es una versión básica que permite realizar una conexión directa entre el servidor VRPN y el cliente VRPN de forma similar a como lo hace VRPNWrapper. Una de sus caracter´ısticas principales es la sencillez de uso que ofrece, ya que solo se debe registrar una función de callback para cada tipo de dispositivo que se desee usar. Debido a la sencillez que provee se omiten algunas caracter´ısticas con las que se suele contar en VRPN como son la marca de tiempo del momento en que se generan los reportes, pero si funciona de manera similar al VRPN original con un modelo Publicador-Suscriptor. Permite comunicarse con dispositivos de tipo Tracker, Análogo y Botón, pero solo un dispositivo por tipo por equipo. Tiene la ventaja de funcionar con la última versión de VRPN.

unityVRPN [65]: Proyecto disponible en GitHub. De manera similar a VRPN2Unity provee una gran sencillez de uso (incluso mayor) lo cual conlleva sus mismas ventajas y desventajas en cuanto a que se omiten algunas caracter´ısticas con las que se suele contar en VRPN, y que solo permite un dispositivo por tipo por equipo. Permite comunicarse con dispositivos de tipo Tracker, An´alogo y Bot´on, pero no usa un modelo Publicador-Suscriptor como el que se suele usar en VRPN, de manera similar a lo que sucede con UIVA.

2.6. Dispositivos para Interacci´

on Hombre-M´

aquina

En el mercado se cuenta con una gran variedad de dispositivos de Interacción Hombre-Máquina, los cuales permiten una gran variedad de posibilidades de interacción. Se revisan dos dispositivos que cuentan con la siguiente serie de cualidades clave: Se tienen disponibles en el laboratorio Colivri, son dispositivos de acceso limitado por su baja popularidad pero proveen formas de interacción novedosas e interesantes, y son soportados por VRPN.

2.6.1. Razer Hydra

El Razer Hydra es un dispositivo que consta de una base y dos controles (Figura2.4). La base hace uso de un campo magnético de bajo poder que le permite detectar la posición y orientación de los

1

(27)

Figura 2.4: Razer Hydra2_.

controladores con una precisión de 1mm y 1 grado. Al hacer uso de un campo magnético, los controles no deben encontrarse a la vista para su correcto funcionamiento. Los controles cuentan cada uno con un joystick análogo, 4 botones, un trigger y un bumper para complementar la interacción generada por la detección de posición y orientación. Los controles son alámbricos, poseen una superficie antideslizante y son bastante livianos [1].

2.6.2. 3DConnexion SpaceNavigator.

El controlador SpaceNavigator posee un sensor con 6 grados de libertad diseñado para manipular contenido digital o posiciones de cámara (Figura2.5). Está compuesto por un sencillo capuchón que permite ser oprimido, halado, rotado e inclinado en todos sus ejes, gestos que se suelen usar para hacer paneos, zoom y rotación. Esta interacción se ve complementada por dos botones que el dispositivo trae en cada costado [2].

2.7. Interfaz de Editores de Audio y Video

En el mercado se encuentra una amplia variedad de aplicaciones que permite edición de audio y/o video. Estas ofrecen diferentes técnicas para permitir que el usuario organice el contenido que desea editar para generar una nueva versión del mismo. A continuación se revisan dos de estas aplicaciones que cuentan con una gran popularidad y un nivel de maduración alto.

2_{<http://assets.razerzone.com/eeimages/products/64/razer-hydra-portal2-gallery-3.png>}

3

(28)

Figura 2.5: 3DConnexion SpaceNavigator3.

(29)

Figura 2.7: Interfaz de Adobe Premiere5_.

2.7.1. Audacity

Audacity es un editor y grabador de audio multi-track, gratuito y f´acil de usar, que se encuentra disponible para Windows, MAC OS X y GNU/Linux entre otros sistemas operativos (Figura 2.6). Audacity se puede usar para:

Grabar audio en vivo.

Grabar audio generado por el computador.

Convertir casetes y discos en grabaciones digitales.

Editar archivos de sonido de una amplia variedad de formatos. Cortar, copiar o mezclar sonidos.

Aplicar numerosos efectos. Y m´as. . .

Audacity es un software gratuito desarrollado por un grupo de voluntarios y distribuido bajo licencia GNU GPL [66].

2.7.2. Adobe Premiere

Premiere es un conjunto de herramientas de producci´on de video con el que se puede editar videos de una gran variedad de formatos en su formato nativo para crear producciones profesionales (Figura 2.7) [67].

4_{<http://audacityteam.org/about/images/audacity-windows.png>}

5

(30)

DISE ˜

NO DEL PROTOTIPO

Teniendo en cuenta la necesidad detectada de un laboratorio virtual para dispositivos de interacción hombre-máquina se desprende el objetivo principal de este trabajo de investigación, en el que se busca revisar la efectividad de facilitar el aprendizaje del uso de dispositivos de interacción hombre-máquina mediante un sistema que permita hacer pruebas con datos generados por el mismo dispositivo, sin que esto implique que se deba desarrollar de manera distinta a como se har´ıa para el dispositivo f´ısico.

Con este objetivo en mente se encuentra la necesidad de desarrollar un prototipo que permita probar que se puede desarrollar una herramienta de pruebas integrada al ambiente de desarrollo que permita grabar, editar y reproducir la información generada por un dispositivo de interacción hombre máquina; probar que es posible que el desarrollo realizado por el estudiante para realizar pruebas con datos grabados, también pueda ser usado por el estudiante para realizar pruebas con el dispositivo real; probar que el estudiante puede aprender a programar para un dispositivo de interacción hombre-máquina de manera efectiva al poner a su disposición la herramienta desarrollada, un tutorial que explique el uso de la herramienta y del dispositivo, y grabaciones previamente realizadas con el dispositivo; y probar que la herramienta desarrollada puede ser usada de manera efectiva aunque toda la enseñanza se haga en l´ınea y el estudiante nunca haga uso del dispositivo de interacción hombre-máquina de forma directa. Para realizar dicha evaluación, el prototipo se debe poner a prueba con usuarios que de preferencia se encuentren en un contexto en el cual tengan un gran interés en aprender a usar este tipo de dispositivos en sus proyectos, además de estar en disposición de realizar este aprendizaje de manera virtual en l´ınea. Los resultados de esta prueba de usuarios deben ser suficientes para responder a la pregunta de investigación que enmarca este trabajo de Tesis: ¿Una herramienta integrada al ambiente de desarrollo que permita grabar, editar y reproducir de forma local los datos generados por un dispositivo de interacción hombre-máquina puede ser un apoyo eficaz para la enseñanza/aprendizaje de la forma de uso de este tipo de dispositivos?

En este cap´ıtulo se presenta el diseño del prototipo desarrollado, empezando por un estudio preliminar desde el que se diseña, la definición de los requerimientos funcionales, seguido por una justificación de la elección de las tecnolog´ıas a usar, el diseño de la arquitectura y por último el diseño

(31)

de la interfaz.

3.1. Estudio Preliminar: Plataforma de Pruebas Remotas en

Kinect

A continuaci´on se va a describir el desarrollo y resultados de la plataforma de pruebas remotas en Kinect de la que se desprende el desarrollo de esta Tesis.

El objetivo de la plataforma de pruebas remotas en Kinect era aprovechar las capacidades de la herramienta Kinect Studio que viene incluida en el SDK que provee Microsoft, para permitir que los estudiantes puedan probar de manera remota secciones de código que estén encaminadas a hacer uso de este dispositivo, sin que tengan que tener un Kinect en sus casas. La capacidad especial que ofrece la herramienta Kinect Studio es la de grabar la información que recibe el dispositivo Kinect, y permitir posteriormente su reproducción de manera que las aplicaciones la vean como información que proviene directamente del dispositivo. La desventaja que esta herramienta posee, y por la cual es justificado el desarrollo de un laboratorio remoto, es que únicamente se puede reproducir una grabación si se tiene un dispositivo Kinect conectado en el momento de reproducción.

Para esto se desarrolló un primer prototipo básico que permitiera probar el concepto que se ten´ıa en mente (Julián Arcos, asistente graduado del grupo de investigación Imagine del laboratorio Colivri de la Universidad de los Andes, 2014). Dicho prototipo aprovechaba la posibilidad que existe de interactuar mediante l´ınea de comandos con la interfaz gráfica de Visual Studio y el Kinect Studio, lo cual se hac´ıa de la siguiente manera: Se expon´ıa una página web mediante el servidor Web IIS (Internet Information Services) de Microsoft, la cual permit´ıa que el usuario ingresara el código a probar. Este código era recibido por una aplicación implementada con el framework ASP.NET, la cual se encargaba de interactuar por l´ınea de comando con la interfaz gráfica de Visual Studio para cargar el fragmento de código en un proyecto predeterminado, compilar y ejecutar el proyecto predeterminado con el fragmento de código insertado, interactuar con la interfaz gráfica del Kinect Studio para poner a correr información previamente grabada, y registrar los mensajes que la aplicación generaba durante su ejecución. Una vez terminada la prueba se proced´ıa a mostrar al usuario los resultados en la página web. Este primer prototipo sirvió para comprobar que si era posible automatizar este tipo de pruebas, y revisar los aspectos a tener en cuenta a la hora de implementar un laboratorio remoto de este tipo. Se decidió aprovechar la experiencia obtenida con este primer prototipo básico como base para un segundo prototipo más robusto (Andrés Roberto Gómez Vargas, asistente graduado del grupo de investigación Imagine del laboratorio Colivri de la Universidad de los Andes, 2015) que deber´ıa poder ser usado como laboratorio remoto por estudiantes del curso de Ambientes Interactivos 3D, el cual se encontraba en un proceso de rediseño hacia un modelo combinado o h´ıbrido, 50 % en l´ınea y 50 % presencial. Para esta segunda versión del prototipo era necesario tener en cuenta que al estarse interactuando con la interfaz gráfica de Visual Studio y del Kinect Studio, no se pod´ıa ejecutar más de una prueba a la vez; que además la información de entrada pod´ıa variar entre experimento y

(32)

Recibir de solicitudes

Encolar solicitudes

Cola de solicitudes

Ejecución de solicitudes

Figura 3.1: Manejo de solicitudes en BackEnd de plataforma de pruebas remotas en Kinect.

experimento, por lo cual tampoco se pod´ıa ejecutar m´as de una prueba a la vez; y que cualquier c´odigo que el usuario incluyera en su env´ıo ser´ıa compilado y ejecutado, lo cual podr´ıa representar un riesgo para el sistema.

En esta segunda versión se hizo uso nuevamente de la herramienta Kinect Studio para grabar y reproducir la información obtenida a través del dispositivo Kinect, pero se hizo mejoras en el resto de la arquitectura que permitieran mitigar los problemas que se detectaron en la primera implementación. Para esto lo primero que se hizo fue dividir la aplicación en dos capas: un FrontEnd que se desarrolló de nuevo sobre el framework ASP.NET con IIS como servidor web, y una aplicación de consola que hace la tarea de BackEnd, encargándose del procesamiento de la información. Estas dos capas se comunican haciendo uso del framework WCF (Windows Comunication Fundation) que permite el env´ıo y recepción de mensajes entre éstas.

Mientras el FrontEnd únicamente se encargaba de exponer los campos necesarios para ingresar la información en una página web, el BackEnd se encargaba de una serie de tareas que permit´ıan la apropiada ejecución de las pruebas. Para esto se realizaba el proceso que se ilustra en la Figura3.1, en la que se puede observar de forma general el manejo que se le da a las solicitudes, el cual consiste en la recepción de éstas, su encolamiento en una cola que es consultada por el sistema cada vez que éste se encuentra desocupado, y su ejecución. De este último paso se puede observar el detalle en la Figura 3.2, en la cual se puede ver que cada vez que se va a ejecutar una solicitud lo que se hace es insertar el fragmento de código recibido en una copia de la plantilla del proyecto con el que se desea experimentar, enseguida se intenta compilar el proyecto resultante y de ser exitoso se lanza el ejecutable que se ha obtenido como resultado, se desv´ıa la salida de consola y de errores para poder capturarlos, se reproducen los datos de entrada con la herramienta Kinect Studio y una vez termina la reproducción se cierran datos de entrada, se cierra el ejecutable, y finalmente se env´ıa un correo al solicitante con los datos capturados de la salida de consola y de errores, junto con un pantallazo si se programó para realizarlo.

Desde el punto de vista del usuario se deb´ıa realizar el siguiente procedimiento: Se acced´ıa a la p´agina <http://device.virtual.uniandes.edu.co/kinect> y se iniciaba sesi´on en la misma.

(33)

Fragmento de código

Insertar fragmento en plantilla predeterminada

Intentar compilar proyecto (MSBuild)

Lanzar ejecutable

Desviar salida de consola

Desviar salida de errores

Ejecutar datos de entrada (Kinect Studio) Cerrar datos de entrada

Cerrar ejecutable Enviar correo Pantallazo si lo hay

Datos recopilados durante compilación y ejecución

Si compila

No compila

Si ejecuta

No ejecuta

(34)

Figura 3.3: Lista de ejercicios que ofrece la plataforma.

Dicha p´agina se encontraba realizada sobre Wordpress y presentaba los diferentes ejercicios a realizar. El primer ejercicio le indicaba al usuario que deb´ıa instalar en su equipo el SDK para Kinect, las herramientas para desarrollador para Kinect, y Visual Studio. Una vez realizado esto pod´ıa proceder a realizar un ejercicio de prueba o directamente pasar a realizar los dem´as ejercicios propuestos.

De cada uno de estos ejercicios se encontraban dos links, de los cuales el primero redirig´ıa a la p´agina en que se pod´ıa realizar las pruebas de c´odigo, mientras que el segundo link permit´ıa descargar un archivo comprimido que inclu´ıa el enunciado del ejercicio a realizar, la plantilla del proyecto con el que se iba a trabajar, y el archivo de datos de entrada con los que se probar´ıa el ejecutable resultante (Figura3.3).

Tras haber descargado en el segundo link los archivos disponibles del ejercicio a realizar, el estudiante deb´ıa revisar el enunciado y el archivo de datos de entrada con los que se probar´ıa el ejecutable resultante (Figura3.4).

Una vez revisado lo que se deb´ıa hacer, el estudiante ten´ıa que abrir el proyecto en Visual Studio, donde encontrar´ıa con un “TODO” el lugar de la plantilla en el que deb´ıa introducir su código (Figura 3.5). Se suger´ıa al usuario que cuando considerara que su código se encontraba correctamente terminado lo compilara, lo cual deb´ıa poder realizar de forma satisfactoria aunque no tuviera un Kinect disponible si ten´ıa el SDK correctamente instalado y si el código propuesto no ten´ıa errores de sintaxis.

Una vez que se ten´ıa el código listo y probado, el estudiante ten´ıa que dirigirse al primer link del ejercicio, donde se presentaba la posibilidad de ingresar una dirección de correo y un fragmento de código (Figura3.6). Una vez llenos estos campos el usuario deb´ıa enviarlos para su procesamiento, el cual pod´ıa tardar dependiendo de la cantidad de env´ıos realizados recientemente por todos los usuarios.

(35)

Figura 3.4: Datos de entrada al abrirlos con el Kinect Studio.

(36)

Figura 3.6: P´agina para enviar fragmento a prueba.

(37)

Figura 3.8: Ejemplo de pantallazo de respuesta.

Figura 3.9: Secuencia de pantallazos para comprender el comportamiento del fragmento de c´odigo.

Una vez procesado el fragmento de c´odigo, el estudiante recib´ıa en su correo un mensaje de texto en el que se indicaba las salidas que se generaron por errores o mensajes de consola (Figura3.7).

A este mensaje se le adjuntaba un pantallazo si el usuario hab´ıa programado su fragmento de c´odigo para tal fin (Figura3.8).

Dependiendo del ejercicio se le recomendaba al estudiante que programara su fragmento de código para que enviara un pantallazo generado en cierto momento de la ejecución, y que luego realizara esta misma solicitud para diferentes momentos de ejecución. Esto deb´ıa permitirle observar de manera más clara el comportamiento que su fragmento de código estaba generando (Figura3.9).

De la experiencia con el desarrollo del laboratorio remoto para pruebas con el dispositivo Kinect quedaron una serie de ense˜nanzas que se desean aplicar en este proyecto. De estas ense˜nanzas hay dos en especial que nos han dado un rumbo fijo a seguir. La primera es que el hecho de tener que salir

(38)

del ambiente de desarrollo para hacer pruebas dificulta la realización de las mismas, por lo que se debe procurar realizar un desarrollo que se integre directamente al ambiente de desarrollo objetivo, de forma que el usuario no tenga que cambiar de aplicación en ningún momento para realizar pruebas. La segunda es que el hecho de tener que esperar un tiempo considerable para conocer el resultado del desarrollo realizado rompe totalmente el proceso mental y de pruebas que realiza el usuario, por lo que se tiene que buscar una manera de eliminar este tiempo de espera. Teniendo en cuenta que los laboratorios remotos hacen uso de dispositivos, tiempos y espacios limitados, una de las maneras para eliminar este tiempo de espera es permitiendo el acceso a los “datos de entrada” de manera individual e independiente. De este segundo punto se podr´ıa concluir que la solución se puede encontrar al pasar de un laboratorio remoto a un laboratorio virtual.

Además de este aprendizaje desde la experiencia obtenida con estos primeros prototipos, se suman algunos hallazgos de la revisión de literatura. El principal es el de la importancia de tener en cuenta la sostenibilidad, mantenibilidad y extensibilidad a la hora de diseñar el laboratorio [48], lo cual es de especial relevancia a la hora de elegir la tecnolog´ıa a usar. El segundo es el de uno de los resultados que se obtuvieron al comparar laboratorios presenciales, laboratorios remotos y laboratorios virtuales, en el cual se indica que se puede notar que los laboratorios que ofrecen datos reales generan mejores resultados [52], lo cual se debe considerar a la hora de decidir la forma en que se va a implementar el laboratorio virtual. Teniendo en cuenta que en el primer prototipo lo que se hac´ıa era aprovechar la posibilidad de grabación de los datos generados por el dispositivo de interacción, lo que se puede hacer en este caso es diseñar un laboratorio virtual que comparta algunos privilegios de los laboratorios remotos, como lo es el usar datos reales.

Para el desarrollo de este proyecto se tuvo que tener en cuenta además un cambio reciente en el mercado con la salida a la venta del nuevo Kinect v2 para el Xbox One. La razón por la que esta novedad se debe tener en cuenta, es porque el SDK para el Kinect v2 inclu´ıa también una segunda versión de la herramienta Kinect Studio, la cual ahora incluye una funcionalidad muy importante que le hac´ıa falta a su primera versión: Puede reproducir información grabada desde el dispositivo, aunque no se cuente con él en el momento de reproducirla [68]. Teniendo en cuenta que la razón por la cual originalmente se tuvo que crear un laboratorio remoto desapareció, se evaluó que tipo de propiedades le hac´ıan falta a esta herramienta para ser realmente un laboratorio efectivo para el aprendizaje de parte de los estudiantes.

La limitante más grande que se encuentra a la hora de diseñar un laboratorio no presencial para aprender a manejar dispositivos de interacción, es que con estos dispositivos de interacción se puede hacer una gran variedad y cantidad de interacciones diferentes, y el estudiante puede desear hacer pruebas con cualquiera de éstas. Cuando se está haciendo uso de grabaciones, el usuario se encuentra limitado a las interacciones que se encuentran registradas en la grabación, con lo que le es imposible extender sus pruebas hacia interacciones de las que no exista una grabación. La solución que se propone para esto es la posibilidad de editar grabaciones de manera similar a como se hace en editores de audio y video, lo que permitir´ıa contar con una serie de grabaciones de interacciones básicas, las cuales

(39)

podr´ıan usarse para componer interacciones m´as complejas y variadas.

3.2. Justificaci´

on de la Elecci´

on de Tecnolog´ıas

Teniendo en cuenta los aprendizajes mencionados en la secci´on anterior, se empez´o a revisar las tecnolog´ıas y recursos que se tendr´ıan en cuenta a la hora de desarrollar el prototipo.

La primera decisión fue la de pasar de un prototipo que ten´ıa como ambiente de desarrollo objetivo el Visual Studio, a uno que tuviera como ambiente de desarrollo objetivo Unity, para lo cual existen varias razones. La primera de ellas es que Unity es un ambiente de desarrollo que está especialmente diseñado para el desarrollo de aplicaciones interactivas. Además de esto, Unity ofrece una API sencilla para extender sus funcionalidades como editor, lo que permite implementar uno de los aprendizajes que se obtuvieron a partir del primer prototipo (el ambiente de pruebas debe estar embebido en el ambiente de desarrollo) y una de las enseñanzas de la literatura (se debe garantizar la sostenibilidad, mantenibilidad y extensibilidad). Estas dos caracter´ısticas hacen de Unity el ambiente de desarrollo objetivo ideal para el desarrollo de este proyecto.

La segunda decisión fue la de pasar de un protocolo cerrado de comunicación como lo es el protocolo que maneja el dispositivo Kinect para comunicarse con las aplicaciones a través del SDK de Microsoft, a un protocolo abierto como VRPN. VRPN cuenta con una serie de ventajas que pueden servir para sacar el mayor provecho posible a este prototipo. La primera de ellas es el hecho de ser un protocolo abierto de comunicación, caracter´ıstica que le da una gran flexibilidad permitiéndonos hacer una gran cantidad de cosas como elegir la forma en que se almacena la información, y comprender la información de forma que ésta se pueda editar. La segunda ventaja es la gran variedad de dispositivos de interacción para los cuales existe la posibilidad de usarlos desde VRPN, y la facilidad con la que se pueden agregar dispositivos nuevos. Estas dos caracter´ısticas permiten de nuevo reforzar lo aprendido desde la revisión de la literatura que establece que se debe garantizar la sostenibilidad, mantenibilidad y extensibilidad del laboratorio.

De la decisión de usar VRPN en conjunto con Unity se generó la necesidad de realizar una nueva decisión: ¿Qué plugin se deber´ıa usar? De las cuatro posibilidades encontradas se optó por hacer uso de VRPNWrapper, ya que entre ellas era el desarrollo más completo y robusto, al ofrecer conexión directa con el servidor VRPN, la posibilidad de usar los tres tipos básicos de sensores y la similaridad de comportamiento con respecto al uso de VRPN por fuera de Unity. Otro punto a favor es el de proveer el código fuente del plugin lo que permitir´ıa realizar cambios sobre éste de ser necesario.

La última decisión que se tomó a nivel tecnológico fue la de pasar de un dispositivo famoso como el Kinect, a dispositivos de más baja disponibilidad como el Razer Hydra y el 3DConnexion SpaceNavigator. La razón para hacer este cambio es que se buscaba un tipo de dispositivo que aunque novedoso e interesante, no se encontrara fácilmente en las casas de los desarrolladores. Por otro lado se quer´ıa tratar de aprovechar la mayor cantidad posible de tipos de sensor con los que cuenta VRPN, que en este caso ser´ıan los de Tracker, Análogo y Botón, de los cuales dos se encuentran presentes en el

(40)

3DConnexion SpaceNavigator, y los tres se encuentran presentes en el Razer Hydra. La última razón por la que se hizo el cambio de dispositivo fue la llegada del Kinect Studio v2, ya que al existir ya una herramienta similar para este dispositivo, no se encontró que fuera suficientemente valioso crear una nueva herramienta para el Kinect as´ı incluyera nuevas funcionalidades, en especial teniendo en cuenta las dificultades que éste presenta al tener un protocolo de comunicación cerrado.

3.3. Definici´

on de Requerimientos Funcionales

Se definieron los siguientes requerimientos funcionales para el prototipo a desarrollar:

1. Se debe poder hacer uso de los dispositivos desde Unity.

2. Se debe poder grabar la informaci´on generada por los dispositivos desde Unity.

3. Se debe poder reproducir la informaci´on grabada previamente desde Unity.

4. Se debe poder realizar composiciones con la informaci´on grabada previamente desde Unity.

5. Se debe poder guardar las composiciones realizadas en Unity.

6. Se debe poder cargar las composiciones realizadas previamente en Unity.

7. Se debe poder reproducir las composiciones realizadas en Unity.

8. Debe ser transparente para el desarrollador si se está haciendo uso del dispositivo f´ısico o si se está haciendo uso de la reproducción de una grabación o de una composición.

9. Para el desarrollador, el desarrollar usando la herramienta debe ser similar a desarrollar para VRPN por fuera de Unity.

3.4. Dise˜

no de la Arquitectura

La herramienta VRPN-Tool, como se le llamó al prototipo desarrollado, está compuesto por los seis componentes básicos que se pueden observar en la Figura 3.10. El componente VRPNManager es propio del plugin VRPNWrapper y se encarga de gestionar la conexión con el servidor VRPN. Con éste se conecta el componente VRPNDevice el cual se encarga de solicitar la información de los dispositivos y sensores de interés, siendo también un componente propio del plugin VRPNWrapper. Esto lo hace mediante tres clases conocidas como VRPNTracker, VRPNAnalog y VRPNButton, cada una de las cuales se encarga de gestionar la conexión con un dispositivo que posee sensores del tipo correspondiente. Es de resaltar que, como un mismo dispositivo puede tener de los tres tipos de sensores (como en el caso del Razer Hydra), puede presentarse que a un mismo dispositivo se asocien instancias de las tres clases contenidas en el componente VRPNDevice.