Redirected Walk in Place using displacement embodiment

Facultad de Informática de Barcelona Grado en Ingeniería Informática Especialidad de Computación Redirected Walk in Place using displacement embodiment Trabajo de Fin de Grado Entrega 1 Dídac Giménez Bové Director: Alejandro Ríos Jerez Codirector: Núria Pelechano Gómez Tutor GEP: Joaquim Deulofeu Aymar 16 de enero de 2022 1 2 Resumen Dentro de la realidad virtual existe un fenómeno denominado motion sickness, una serie de síntomas como nauseas o jaquecas producidas por las discrepancias entre lo que vemos en los dispositivos y lo que hacemos en el mundo físico. Uno de los métodos que consigue reducir el problema es la metodología Walk-inplace, donde el usuario camina sobre un sitio fijo de forma que solo alza o baja los pies y, en base a este movimiento, se produce un desplazamiento en el entorno virtual. Al obtener una relación directa entre el desplazamiento y las acciones del usuario, los efectos negativos se ven reducidos. Esta solución al problema, sin embargo, cuenta con que el usuario se mueva sobre un mismo sitio, algo que, al carecer de una referencia del mundo real mientras se usan los dispositivos VR, acaba por suponer un desplazamiento físico del jugador dentro de la zona segura de juego pudiendo llegar a salirse de esta provocando accidentes (chocar con muebles, contra una pared, etc.). Teniendo en cuenta todo lo anterior, el objetivo de este proyecto es aprovechar el avatar (modelo 3D de las personas) del entorno y la reacción automática del usuario al darse cuenta de la discrepancia entre él y el modelo para incitar la vuelta de este al centro de su zona segura. De esta forma se hallaría una solución no intrusiva al desplazamiento inconsciente en el mundo físico que acabaría con los accidentes. Para llevar a cabo esta tarea, se ha diseñado un modelo con el que el usuario puede identificarse, que siempre está situado en el centro de la zona segura, de modo que cuando se produzca la desviación de la posición del usuario, este sea capaz de ver su modelo desplazado y pueda corregir su posición. Este proyecto pretende llevar a cabo un sistema que implemente esta idea ya sea de forma parcial o total y permita más adelante el análisis de los datos necesarios para extraer conclusiones. 3 Abstract Virtual Reality has a group of side effects related to it named motion sickness. These symptoms include dizziness, headaches and other ones due to some inconsistencies of the visual and Physical stimulus while being in a simulation. One of the methods used to reduce these symptoms is called Walk-in-place, which directly converts the static walking into real movement inside the simulation, therefore inconsistencies are decreased and with that, the sickness. This method however, has another problem that comes with it, and it involves a subtle movement that causes the player to walk away from the centre or the safe zone causing in the end accidents or unintended collisions with walls or furniture. This problem endangers user’s safety because of the limitations in the real world. Keeping this in mind, this project intends to use the avatar of the simulation to hint the user to relocate himself to the safe zone. In order to achieve this, the model is always located in the centre of the playing zone so that the user can identify the discrepancy between himself and the avatar while playing, therefore, allowing him to correct his position. The project pretends to solve this problem totally or partially implementing the idea and later making an experiment to analyse the results. 4 Índice 1. Introducción y contextualización .................................................................. 9 1.1. Contexto .................................................................................................. 10 1.2. Conceptos ................................................................................................ 10 Realidad Virtual ........................................................................................... 10 Espacio físico y virtual ................................................................................. 10 Walk In Place ............................................................................................... 12 Zona Segura ................................................................................................. 12 1.3. Identificación del Problema ................................................................... 13 Modelo 3D adecuado ................................................................................... 14 Animar el modelo ........................................................................................ 14 Recoger i analizar los datos ......................................................................... 15 1.4. Actores implicados .................................................................................. 15 2. Justificación ................................................................................................. 17 2.1. Soluciones Existentes ............................................................................. 17 2.2. Herramientas....................................................................................... 17 3. Alcance ......................................................................................................... 18 3.1. Objetivos ................................................................................................. 18 Búsqueda e inserción de un modelo adecuado al problema ....................... 18 Animación i programación de los movimientos del modelo ...................... 19 Recoger muestra de datos con diferentes usuarios ..................................... 19 Analizar los datos recogidos de la muestra ................................................. 19 Estudio de los resultados y comprobación de la hipótesis ......................... 19 3.2. Requerimientos. .................................................................................. 19 Requerimientos funcionales ........................................................................20 Requerimientos no funcionales ...................................................................20 3.3. Obstáculos y riesgos ............................................................................20 4. Metodología y Rigor .................................................................................... 22 5. Planificación temporal ................................................................................. 23 5.1. Descripción de las tareas ........................................................................ 23 GP – Gestión de Proyecto ............................................................................ 23 P - Programación ......................................................................................... 25 5 I - Investigación ........................................................................................... 26 5.2. Recursos .............................................................................................. 28 Recursos materiales ..................................................................................... 28 Recursos espaciales ..................................................................................... 29 5.3. Estimaciones de tiempo i Gantt ..........................................................30 5.4. Gestión del riesgo ................................................................................ 34 6. Planificación Económica ............................................................................. 35 6.1. Presupuesto ............................................................................................ 35 Coste del personal ........................................................................................ 35 Costes genéricos ........................................................................................... 36 Contingencia ............................................................................................... 40 Imprevistos ................................................................................................. 40 Coste total .................................................................................................... 41 6.2. Control de Gestión ............................................................................... 42 7. Sostenibilidad .............................................................................................. 44 7.1. Autoevaluación ....................................................................................... 44 7.2. Dimensión económica ......................................................................... 44 7.3. Dimensión Ambiental ......................................................................... 45 7.4. Dimensión Social ................................................................................. 46 8. Identificación y estado inicial ...................................................................... 48 9. Solución Propuesta ...................................................................................... 49 9.1. Limitaciones............................................................................................ 49 9.2. La Solución .......................................................................................... 50 10. Desarrollo .................................................................................................... 52 10.1. Espacio virtual ..................................................................................... 52 10.2. Walk in place ....................................................................................... 53 10.3. Modelo 3D del jugador ........................................................................ 54 10.4. Algoritmo Fast Inverse Kinematics (FastIK) ..................................... 59 10.5. Tareas de la simulación ....................................................................... 64 11. Análisis de los datos..................................................................................... 67 11.1. Variables .............................................................................................. 67 11.2. Fase de entrenamiento ........................................................................ 68 6 11.3. Muestreo .............................................................................................. 69 11.4. Análisis del muestreo .......................................................................... 70 12. Evaluación y mejoras futuras ...................................................................... 73 13. Conclusión ................................................................................................... 75 14. Referencias................................................................................................... 78 15. Anexo .......................................................................................................... 80 Índice de figuras Figura 1: Ejemplo de Walk-in-place. Elaboración propia. ................................ 12 Figura 2. Dos posibles modelos de los assets de Unity. [4] ................................ 14 Figura 3: Diagrama de Gantt, Elaboración propia vía Gantter. [8] ................ 33 Figura 4: Escenario virtual. Elaboración propia. ............................................. 52 Figura 5: Sensores HTC VIVE. Elaboración Propia .......................................... 53 Figura 6: Modelo 3D Y-Bot. Elabora propia. ..................................................... 55 Figura 7 : Space Robot Kyle. Unity Asset Store. [16]. ........................................ 56 Figura 8: Rocket Male 1. Elaboración propia. ................................................... 57 Figura 9 : Rocket male 1 modificado. Elaboración propia. ............................... 58 Figura 10: IK Backwards. Elaboración propia. ................................................ 60 Figura 11: IK Backwards. Elaboración propia. ................................................. 61 Figura 12: IK Backwards. Elaboración propia. ................................................. 61 Figura 13: IK Backwards. Elaboración Propia. ................................................. 62 7 Figura 14: Rotación del hueso. Elaboración propia. ......................................... 63 Figura 15: Máquina de Billetes de tren. Elaboración propia. ........................... 64 Figura 16: Andén número 3. Elaboración Propia. ............................................. 65 Figura 17: Máquina de Bebidas. Elaboración propia ........................................ 65 Figura 18: Bola de papel. Elaboración propia. .................................................. 66 Figura 19: Tres muestras de un solo usuario. Elaboración propia. .................. 70 Figura 20: Muestras de 3 usuarios distintos. Elaboración propia. .................. 71 Figura 21: Gráfico de la muestra a. Elaboración propia. ................................ 80 Figura 22: Gráfico de la muestra B. Elaboración propia. ................................ 80 Figura 23: Gráfico de la muestra C. Elaboración propia. ................................. 81 Figura 24: Gráfico de la muestra D. Elaboración propia. ................................ 81 Figura 25: Gráfico de la muestra E. Elaboración propia. ................................. 82 Figura 26: Gráfico de la muestra F. Elaboración propia. ................................. 82 Figura 27: Gráfico de la muestra G. Elaboración propia. ................................. 83 Figura 28: Gráfico de la muestra H. Elaboración propia. ................................ 83 Figura 29: Gráfico de la muestra I. Elaboración propia. .................................. 84 Figura 30: Gráfico de la muestra J. Elaboración propia. ................................. 84 Figura 31: Gráfico de la muestra K. Elaboración propia. ................................. 85 Figura 32: Gráfico de la muestra L. Elaboración propia. ................................. 85 8 Figura 33: Gráfico de la muestra M. Elaboración propia. ................................ 86 Figura 34: Gráfico de la muestra N. Elaboración propia. ................................ 86 Figura 35: Gráfico de la muestra O. Elaboración propia.................................. 87 Figura 36: Gráfico de la muestra P. Elaboración propia. ................................. 87 Índice de tablas Tabla 1: Planificación temporal en horas. Elaboración propia. ....................... 31 Tabla 2 : Coste de personal a partir de la guía de mercado laboral de Hays. Elaboración Propia. ............................................................................................. 36 Tabla 3: Tabla de partidas por tarea. Coste SS referente a la Seguridad Social. Roles: JP – jefe de proyecto, I – investigador, P – programador, T – tester. Elaboración propia. ............................................................................................. 38 Tabla 4: Costes de recursos Software. Elaboración propia. ............................. 39 Tabla 5: Costes de los recursos hardware y amortizaciones. Elaboración propia. .............................................................................................................................. 39 Tabla 6: Costes de contingencia. Elaboración Propia. ..................................... 40 Tabla 7: Tabla de sobrecoste añadido por imprevistos. Elaboración propia. .. 41 Tabla 8: Tabla de presupuesto final del proyecto. Elaboración propia. .......... 42 Tabla 9: Estadísticas de las Muestras. Elaboración Propia. ............................. 72 15 Recoger i analizar los datos Finalmente, una vez preparado el entorno y se cogerán muestras de varios usuarios para recoger información acerca de la distancia total recorrida y ver si en efecto, el usuario es capaz de autocorregir el desplazamiento involuntario. Este estudio quiere recoger la distancia entre el origen o centro del espacio de juego y la posición del usuario durante el trascurso de Walk-in-place. De este modo se obtendrán datos sobre las correcciones o desviaciones que hace el usuario durante las pruebas. 1.4. Actores implicados El objetivo final de este estudio es realizar la investigación para estimar si proseguir por este camino es viable o resulta en un recurso inviable. Si se confirma la hipótesis inicial, supondría un avance significativo en el estudio de la realidad virtual i el proceso de evitar el motion sickness [4] o mareos por movimiento. En el caso de que se confirme el estudio abriría todo un seguido de posibilidades para facilitar el uso de la propia reacción automática del usuario para solucionar otros problemas. Por el contrario, si la hipótesis resulta ser nula, se podrán descartar muchas otras ramas de investigación que podrían resultar en el gasto inconcluso de fondos y tiempo que podrían dedicarse a otras ramas de investigación mucho más interesantes o prometedoras. En ambos casos, este proyecto ayudará a estimar si vale o no la pena proseguir por esta rama de investigación. Esto supondrá una mejor optimización de recursos, de tiempo y en todo caso, supondrá un avance para el usuario, que prevendrá posibles colisiones o situaciones de riesgo, haciendo de la simulación una experiencia mucho más placentera. 16 Este tipo de proyecto se dirige a un tipo de usuario muy concreto, desde gente que quiere disfrutar de una experiencia diferente en un videojuego, hasta usuarios con necesidades más técnicas como médicos o ingenieros para mejorar el aprendizaje. En lo referente al desarrollador y a la empresa, este proyecto significa el futuro de las siguientes investigaciones y recursos en los que invertir. Además, el desarrollo y publicación de los resultados de esta investigación resultará de ayuda para la comunidad de investigadores aportando de este modo una visión nueva e información acerca de lo que pueden esperar si prosiguen por esta rama. Obviamente, si la hipótesis fuera nula en ambos casos estamos ayudando a la comunidad pues descartar toda una línea de investigación resultará en que otros investigadores se centren en otras ramas más prometedoras o con mejores resultados. Por otra parte, los usuarios también se verán beneficiados porque con cada resultado nos acercamos a encontrar una solución que sea satisfactoria para que los usuarios puedan usar estas tecnologías con todo el potencial que estas albergan. 17 2. Justificación La realidad virtual es un área nueva y en constante desarrollo, en particular el estudio para evitar las aflicciones como mareos y nauseas es una de las principales ramas dado que, ante todo, se pretende conseguir un entorno seguro para todo y todos. Aparte de que aporta un gran número de oportunidades y experiencias que de otro modo no serían posibles. Por esta razón, es crucial investigar las diversas formas que tenemos de evitar los problemas, y es por esto que se estudia si la reacción propia del usuario es suficiente para evitar el desplazamiento involuntario o en el caso opuesto que sea capaz de darse cuenta y corregirlo. 2.1. Soluciones Existentes En entornos parecidos se ha comprobado que el desacople de las manos virtuales con el cuerpo físico crea el impulso innato de corregir la postura para cuadrar los movimientos con el entorno virtual. Gracias a ese estudio se ha generado la hipótesis en la que se basa el proyecto [5]. Existen otras soluciones que no implican la respuesta inherente del usuario y que implican la adición de otros mecanismos tanto externos como internos. Sin embargo, dichos métodos buscan una solución que puede sacar al usuario de la inmersión y probablemente empeoran la experiencia en general. Es por esto que se busca usar la reacción autónoma del usuario para asegurar que el entorno es lo más fiable e inmersivo posible. 2.2. Herramientas Esto precisa un entorno que pueda usar un modelo y simular un escenario que pueda usarse para VR. Aun existiendo otros entornos para realidad virtual, usaremos Unity ya que proporciona muchas facilidades 18 para realizar este estudio y partimos de un proyecto ya preparado para este tipo de investigación. Se hará uso de dispositivos de realidad virtual como las gafas, unos controles para las manos, varios sensores situados en la sala y dos sensores colocados uno en cada pie. Esto permite hacer un seguimiento de la posición de los pies que permitirá mover al cuerpo virtual en función del movimiento físico. 3. Alcance Como en todo proyecto, es importante definir el alcance de este, dado que para la realización de este tiene una limitación temporal. Hay que definir un seguido de objetivos y requerimientos de la investigación. 3.1. Objetivos El objetivo de este proyecto es el desarrollo de una investigación sobre una escena VR ya formada. Para ello es preciso implementar las físicas de movimiento respecto al modelo introducido, que será la imagen virtual del usuario. Una vez completada esta fase de programación, se derivará en una fase de estadística en la que se recogerán datos en base a una muestra en la que varios usuarios probarán el sistema y se estudiarán las distancias recorridas, el tiempo de reacción y si en efecto la solución es viable para el problema presentado. Por lo tanto, como subobjetivos encontraremos: Búsqueda e inserción de un modelo adecuado al problema Principalmente se buscará un modelo que resulte suficiente para representar al usuario, se introducirá en Unity para usarlo como avatar. La complejidad del modelo puede resultar irrelevante dado que lo que estudiamos depende solo de la reacción del usuario y no con el modelo en sí. 19 Animación i programación de los movimientos del modelo Se animarán las articulaciones del modelo para simular de forma efectiva el movimiento del usuario simulando las capacidades de andar que muestra un humano. Esto se logrará mediante la aplicación de Inverse Kinematics en base a los sensores situados en los pies del usuario. Recoger muestra de datos con diferentes usuarios Una vez el entorno esté listo se preparará un script que recoja la información requerida acerca de la distancia recorrida, el tiempo de reacción, etc. De modo que devuelva los datos recogidos en un formato cómodo para proceder al análisis estadístico. Analizar los datos recogidos de la muestra Se procederá a analizar los datos mediante la aplicación de RStudio que nos permitirá abrir y analizar con facilidad el archivo recopilado. Con este programa se estudiarán los diversos datos recogidos para sacar una conclusión. Estudio de los resultados y comprobación de la hipótesis Una vez el análisis este completo, se sacará una conclusión acerca del problema que estimará si la hipótesis es correcta o por el contrario habrá que descartar esta rama de estudio para encontrar una solución al problema presentado. 3.2. Requerimientos. Este proyecto precisa de varios requerimientos para poder proceder correctamente, algunos funcionales que se ocupan de que el sistema funcione sin errores, y otros no funcionales, necesarios para asegurar el buen desarrollo tanto del proyecto como de la aplicación. 20 Requerimientos funcionales Es necesario que los dispositivos VR sean compatibles con la aplicación, dado que cada vez hay más dispositivos y debe asegurarse el correcto funcionamiento. Es necesario integrar todas las novedades en la aplicación de base para que no supongan problemas a largo plazo y sirvan para futuros experimentos, ya sea la inserción de uno o varios modelos o la codificación del movimiento de este. Requerimientos no funcionales El software usado para el funcionamiento de los dispositivos VR debe pasar los cánones de Usabilidad. La aplicación debe ser fácil de usar o modificar cuando sea requerido. El código implementado debe ser Eficiente dado que las aplicaciones gráficas actuales requieren una potencia de cómputo. Es imprescindible que el código no contenga cosas irrelevantes o redundantes. El software debe ser Reusable, ya que en un futuro las funcionalidades desarrolladas podrían ayudar a nuevas investigaciones o implementaciones sobre la misma base. 3.3. Obstáculos y riesgos Es necesario evaluar los riesgos y dificultades que se pueden encontrar durante el desarrollo y es importante minimizar su impacto y buscar alternativas. Por ello, aquí se estipulan con más detalle los posibles riesgos u obstáculos. - Dado que la realidad virtual es una tecnología en constante desarrollo es difícil encontrar manuales, librerías o incluso el hardware para 21 desarrollar estos proyectos. Por ello se le dedicaran más horas de las realmente estimadas con el objetivo de no caer en retrasos por estos pequeños inconvenientes. - Se requiere un ordenador con especificaciones muy concretas y habitualmente altas para poder realizar o emular una escena de estas características. Debe tener una buena CPU y GPU. En este caso se contará con el ordenador personal además del equipo que se encuentra en el Centro de Realidad Virtual. - Hay que controlar el acceso limitado al uso de los dispositivos VR dado que el desarrollo del proyecto se llevará a cabo en el Centro de Realidad Virtual compartiéndolos con otros proyectos simultáneos y añadiéndole a esto los protocolos adicionales que supone la reciente pandemia global. Si fuera el caso podrían asignarse nuevos días para completar las tareas que lo requieran dado que se le asignará mucho más tiempo del requerido como prevención. - Es importante tener en cuenta que un fallo del ordenador de trabajo supondría un grave retraso a nivel global del proyecto, aunque puede evitarse o remediar el problema mediante el uso de control de versiones online, ya sea la propia de Unity o mediante Github. 22 4. Metodología y Rigor La ejecución de este proyecto requiere de un modo de trabajo adaptable y muy flexible ya que se depende de factores muy importantes y parte de los riesgos conlleva la necesidad de adaptarse a un entorno variable. Dado el proyecto de partida basado en un entorno de realidad virtual, es preciso asegurar que los avances o las implementaciones cumplen con las normativas de usabilidad, eficiencia y reusabilidad estudiadas en IDI y Gráficos por computador ambas asignaturas de la especialidad de Computación. Además, se hará uso de otras técnicas y programas usados posteriormente en Videojuegos o Robótica que permiten animar un modelo de una forma precisa y correcta usando el entorno de Unity. Siempre se evaluará la eficiencia del código para cumplir con los conocimientos impartidos en Algoritmia o posteriores. De esta forma se asegura que no solo sea eficiente, si no que cumpla con las normas de modularidad. Para mantener el desarrollo en orden se usará un gestor de referencias (Zotero [6]), además de un diagrama de Gantt (Gantter [7]) para llevar al día la organización y evolución de las tareas a realizar. Aparte se dividirá el trabajo en tareas y subtareas para evitar cargas de trabajo muy pesadas según el método de trabajo Scrum. Todo esto viene acompañado de una o varias reuniones semanales con el tutor con el objetivo de mantener un flujo constante de comunicación y revisión del experimento para asegurar un funcionamiento adecuado y fluido. Se usará Discord como medio de comunicación principal con un chat abierto para hacer las consultas que sean precisas en todo momento. Adicionalmente, se harán revisiones habituales del escrito para asegurar la corrección y coherencia de las explicaciones. 23 5. Planificación temporal Para realizar el proyecto dentro de un plazo limitado es necesario el uso de un sistema de trabajo organizado y dinámico para poder adaptar los esfuerzos a las posibles causalidades que pudieran suceder. Por ello también es preciso definir las tareas y delimitar sus objetivos para aprovechar mejor el tiempo. 5.1. Descripción de las tareas En un principio tal y como se describe en la Figura 2, se han dividido las tareas en grandes subgrupos que luego han sido en tareas más pequeñas con dependencias entre ellas para proceder con facilidad. Mediante el programa de Gantter se ha estimado un tiempo para la realización de todas las tareas en días. No obstante, el número de horas estimado es de entre 34 horas. GP – Gestión de Proyecto La gestión del proyecto es esencial para planificar, definir y documentar el trabajo a realizar. Esto también engloba las reuniones para la validación y propuesta de objetivos semanales. Se estima que la gestión de proyecto conllevará un total de 260 horas. GP.1 - Estudio Previo Se realiza una investigación y recopilación de información de sobre el tema a tratar. Desde definiciones a artículos sobre investigaciones previas o en otras ramas. Esto tiene como objetivo informar al autor del proyecto acerca de lo que se va a hacer y cómo debe hacerse. Para la realización de esta tarea se estiman 32 horas. GP.2 – Entrega 1 Esta tarea requiere el desarrollo de la introducción de la memoria, la elaboración del contexto del proyecto, la justificación de la investigación, 24 la definición del alcance del trabajo y concretar la metodología y rigor que este va a necesitar para llegar a los objetivos designados. Para la realización de esta tarea se estiman 28 horas. GP.3 – Entrega 2 Esta tarea requiere que se estime de forma extensiva las tareas a realizar, sus objetivos, un cálculo en horas de las tareas a realizar en total de modo que se estructure el proyecto para no caer en retrasos u otros problemas de organización. Además, se contemplarán los tiempos en caso de que sucedan los posibles inconvenientes. Para la realización de esta tarea se estiman 16 horas. GP.4 – Entrega 3 Esta tarea requiere que se haga una estimación en base a los recursos necesarios para realizar las tareas de los costes del proyecto. Se realizarán cálculos sobre el coste de cada tarea para definir un presupuesto general del trabajo. Dado que se precisan dispositivos muy costosos, es necesario llevar un inventario correcto y preciso. También se hará un estudio de la sostenibilidad del proyecto. Para la realización de esta tarea se estiman 20 horas. GP.5 – Entrega Final Esta tarea requiere terminar la primera parte de documentación del proyecto en la que resultan todas las entregas previas junto con las revisiones y correcciones oportunas a realizar después de la evaluación de cada apartado. Para ello se le han destinado unas 20 horas. GP.6 – Memoria del Proyecto Esta tarea consiste en la recopilación y escritura del informe que recoge los pasos seguidos para la programación del entorno junto con la recolección de los datos resultantes de las pruebas y análisis estadísticos. 31 Tarea #días #horas/día #horas/tarea Recursos Roles Dependencias GP.1 8 4 32 PC, W JP - GP.2 7 4 28 PC, W JP P.1 GP.3 4 4 16 PC, W, G JP GP.2 GP.4 5 4 20 PC, W, G JP GP.3 GP.5 5 4 20 PC, W JP GP.4 GP.6 20 4 80 PC, W JP GP.5 GP.7 16 4 64 PC, W JP GP.6 Total GP 260 P.1 3 4 12 PC P GP.1 P.2 4 4 16 PC, CRV, HTC P P.1 P.3 3 4 12 PC P P.2 P.4 10 4 40 PC, CRV, HTC P P.2 P.5 10 4 40 PC, W, CRV, HTC P, T P.4 P.6 5 4 20 PC P P.5 Total P 140 I.1 15 4 60 PC, CRV, HTC I P.6 I.2 10 4 40 PC, W, CRV, HTC, R I, P P.6 I.3 5 4 20 PC, W, R I I.1, I.2 Total I 120 R.1 5 4 20 PC, W JP GP.7, I.3 R.2 5 4 20 PC, W JP R.1 Total R 40 Total 560 TABLA 1: PLANIFICACIÓN TEMPORAL EN HORAS. ELABORACIÓN PROPIA. 32 Dependencias Como puede observarse en la Tabla 1 y la Figuras 2, tenemos tres caminos diferentes a seguir. Dos de las ramas de dependencias, la rama de programación pintada en rojo y la rama de documentación pintada en verde, parten ambas de una misma tarea, el estudio previo. No obstante, luego estas dos ramas son independientes entre sí hasta el final del proyecto donde ambas deben unir los progresos de sus respectivas ramas en la memoria final del proyecto (GP.7). Por otro lado, tenemos una rama de color amarillo que corresponde a las reuniones de seguimiento del proyecto en las que se puede ver una única tarea continuada, aunque es simbólica, dado que las reuniones se realizarán según convengan. Una vez se unen las tres ramas como se puede observar en la Figura 2 hay un par de tareas que concluyen el desarrollo del proyecto y precisan de la finalización de todas las previas. Cada rama de tareas es independiente entre sí e internamente suelen ser lineales, aunque en el caso de la rama de programación e investigación, aparecen varias tareas que pueden realizarse simultáneamente. 33 FIGURA 3: DIAGRAMA DE GANTT, ELABORACIÓN PROPIA VÍA GANTTER. [8] 34 5.4. Gestión del riesgo Es importante tener en cuenta la prevención de los posibles riesgos u obstáculos que pueden surgir durante el desarrollo, concretamente en este proyecto, al hacer uso de las nuevas tecnologías, es probable que se produzcan cambios en la planificación inicial. A continuación, se describen los posibles obstáculos y las alternativas designadas para solventarlos. Errores en las librerías Dado que la realidad virtual es una tecnología en constante desarrollo es difícil encontrar manuales, librerías o incluso el hardware para desarrollar estos proyectos. Por esta razón se ha añadido una cantidad extra de horas al apartado de programación con el objetivo de prevenir y adelantarse a los posibles fallos que pudieran ocurrir durante el desarrollo del proyecto. De este modo si se produjeran dichos contratiempos el proyecto no se vería afectado. Rendimiento Se requiere un ordenador con especificaciones muy concretas y dado que se precisan altos rendimientos para poder realizar o emular una escena de estas características, debe tener una buena CPU y GPU. En este caso se contará con el ordenador personal además del equipo que se encuentra en el Centro de Realidad Virtual. En el caso de que sucediera un contratiempo con el equipo el CRV cuenta con más de un ordenador con estas prestaciones y en un caso fatídico en el que fallasen ambos se ha dedicado más tiempo del habitual para la el ámbito de experimentación y programación en el que requieran uso de dichos ordenadores. Falta de dispositivos El número de dispositivos de realidad virtual que tiene el CRV es limitado y actualmente el centro lleva más de un proyecto simultaneo con 35 lo que el uso de estos depende de la demanda de ellos y es necesario planificar en base a que deberemos adaptarnos a un horario variable y por lo tanto se dedicaran una mayor asignación de días con el objetivo de mantener una planificación flexible y estable. Fallo del Ordenador Personal Es importante tener en cuenta que un fallo del ordenador de trabajo supondría un grave retraso a nivel global del proyecto. No obstante, dado que las tareas de programación e investigación requieren el uso de programas de terceros se mantendrán copias en servicios cloud como Github [12] o Google Drive [13] para no perder el avance del proyecto. A su vez, se cuenta con un portátil extra que supliría el uso del ordenador principal de esta forma evitando el retraso y habilitando la reparación de este simultáneamente. 6. Planificación Económica Una vez realizada la planificación temporal del proyecto, se debe estimar el coste necesario para el desarrollo de este. Se identificarán diferentes tipos de costes que corresponden al personal, los espacios de trabajo, y las herramientas y dispositivos que van a ser usados. Además, habrá que hacer una estimación de los costes no programados provocados por los riesgos y obstáculos que puedan ocurrir. Se realizará un plan de contingencia, una partida de imprevistos y se propondrán los mecanismos para controlar el presupuesto. 6.1. Presupuesto Coste del personal A partir de la planificación de tareas se calcula el coste de personal. En este, se tienen en cuenta los distintos roles definidos en el apartado anterior: jefe de proyecto, investigador, programador y tester. En la Tabla 36 1, se ve el coste por hora de cada puesto. Dichos costes han sido obtenidos mediante la empresa de reclutamiento Hays [14]. Rol Coste/Hora Jefe de Proyecto 30€/h Investigador 20€/h Programador 16€/h Tester 16€/h TABLA 2 : COSTE DE PERSONAL A PARTIR DE LA GUÍA DE MERCADO LABORAL DE HAYS. ELABORACIÓN PROPIA. En la Tabla 2, se concreta el cálculo del total en base a los costes de la Tabla 1, y se estima que el coste de la seguridad social multiplicando los costes finales de cada tarea por 1,3. El coste final del apartado de personal es de 20,664€. Costes genéricos Se estima que se va a trabajar de lunes a viernes en el Centro de Realidad Virtual, y durante los fines de semana se trabajará desde casa. Por esto, como ambos espacios son compartidos y están en Barcelona, se estima el coste en función de la tarifa de un espacio coworking en Barcelona, con una mesa individual y acceso todos los días de la semana. El coste es de 300 euros al mes [15]. Esto incluye gastos de agua, electricidad e internet. Teniendo en cuenta que el proyecto se desarrolla a lo largo de 5 meses, el coste total del espacio se estima en 1500 euros. A continuación, se especificarán los costes de recursos de Software usados en el proyecto. En la Tabla 2 se encuentra un presupuesto de personal detallado. - Gantter [7] – Tiene un coste de 5 euros mensuales por usuario, solo es necesaria una licencia para el jefe de proyecto. 37 - Microsoft 365 [8] – Es gratis para empresas los 6 primeros meses y solo es necesario para el jefe de proyecto. - Unity3D [10] – Pago mensual de 150 euros por usuario y se necesita una licencia para el programador. - R-Studio [11] – Pago por una licencia de 50 euros y se precisa una licencia para el investigador. 38 Tarea #horas/tarea Recursos Roles Coste Coste SS GP.1 32 PC, W JP 960 € 1.248 € GP.2 28 PC, W JP 840 € 1.092 € GP.3 16 PC, W, G JP 480 € 624 € GP.4 20 PC, W, G JP 600 € 780 € GP.5 20 PC, W JP 600 € 780 € GP.6 80 PC, W JP 2.400 € 3.120 € GP.7 64 PC, W JP 1.920 € 2.496 € Total GP 260 7.800 € 10140 € P.1 12 PC P 192 € 249,6 € P.2 16 PC, CRV, HTC P 256 € 332,8 € P.3 12 PC P 192 € 249,6 € P.4 40 PC, CRV, HTC P 640 € 832 € P.5 40 PC, W, CRV, HTC P, T 1.280 € 1.664 € P.6 20 PC P 320 € 416 € Total P 140 2.880 € 3.744 € I.1 60 PC, CRV, HTC I, P 2.160 € 2.808 € I.2 40 PC, W, CRV, HTC, R I, P 1.440 € 1.872 € I.3 20 PC, W, R I 400 € 520 € Total I 120 4.000 € 5.200 € R.1 20 PC, W JP 600 € 780 € R.2 20 PC, W JP 600 € 780 € Total R 40 12.00 € 1.560 € Total 560 15.880 € 20.644 € TABLA 3: TABLA DE PARTIDAS POR TAREA. COSTE SS REFERENTE A LA SEGURIDAD SOCIAL. ROLES: JP – JEFE DE PROYECTO, I – INVESTIGADOR, P – PROGRAMADOR, T – TESTER. ELABORACIÓN PROPIA. 39 Software Coste/Mes Meses Total Microsoft 365 0 € 5 0 € Gantter 5 € 5 25 € Unity3D 150 € 5 750 € R-Studio 0 € 5 0 € Total - - 775 € TABLA 4: COSTES DE RECURSOS SOFTWARE. ELABORACIÓN PROPIA. Finalmente, se calcularán los costes de los dispositivos Hardware. Para hacer los cálculos de las amortizaciones, se ha calculado el coste por hora teniendo en cuenta que solo se contabilizan un total de 220 días laborables y 8 horas laborables al día. El coste de la amortización, por lo tanto, es de (Unidades * Horas * Precio) / (220 * 8 * Vida útil). Habitualmente se estima una vida útil de 4 años a los dispositivos electrónicos, no obstante, para los cascos VR se calculan unos 2 años de vida útil, pues rápidamente quedan obsoletos dada su evolución constante. En la Tabla 4 quedan detalladas las amortizaciones, horas de uso y costes de cada dispositivo mencionado en la planificación temporal. Hardware Coste/Unid ad Unidade s Vida Útil Hora s Amortizació n Ordenador Personal 2.100 € 1 4 560 167 € Ordenador CRV 2.000 € 2 4 196 111 € HTC Vive 800 € 2 4 196 45 € Total - - - - 323 € TABLA 5: COSTES DE LOS RECURSOS HARDWARE Y AMORTIZACIONES. ELABORACIÓN PROPIA. 40 Contingencia Todo proyecto debe añadir un sobrecoste para cubrir obstáculos e imprevistos. En este caso, al tratarse de un trabajo de investigación con tecnologías innovadoras, la probabilidad de encontrar problemas durante el desarrollo es importante, por lo tanto, se ha fijado un sobrecoste valorado en el 15% del total. En la Tabla 5 se detalla el coste de contingencia del proyecto. Tipo Coste Contingencia Espacio 1.500 € 225 € Software 775 € 116 € Hardware 323 € 48 € Personal 20.644 € 3.097 € Total 23.242 € 3.486 € TABLA 6: COSTES DE CONTINGENCIA. ELABORACIÓN PROPIA. Imprevistos Aun con los costes de contingencia, en un proyecto suele haber imprevistos. Por ello, para evitar retrasos o graves situaciones se presenta una planificación para prevenir este tipo de casuísticas. Se considerará solo el riesgo y el coste de este en la Tabla 6. Se detallan aquí los posibles sucesos. - Aumento en el tiempo de desarrollo. En el caso en el que fuera preciso ampliar el tiempo de desarrollo, se añadirían un total de 25 horas de desarrollo a la planificación y 10 horas al Testing. El coste de esta adición sube a 560 euros. Dicho riesgo es elevado debido a la tecnología que se trata por lo que se estima la posibilidad de este en un 20%. 47 En lo que se refiere a los riesgos causados por este, estamos realizando un estudio que no pretende ser comercializado y que no será nocivo para ningún usuario que participe en el muestreo. El único riesgo que pudiera sufrir un jugador durante las pruebas esto toparse con un mueble o pared, sin embargo, eso ya se ha contemplado y el supervisor de dicha prueba avisará previamente al sujeto antes de sufrir cualquier daño. Dado que las pruebas son puntuales nada de lo que se realice en el proyecto puede crear conductas adictivas o que debiliten al usuario, fuera de un posible mareo si no tiene la capacidad de orientarse dentro de un espacio virtual con facilidad. 48 8. Identificación y estado inicial Antes de comenzar con la explicación de la solución propuesta y el desarrollo que se ha llevado a cabo, se identifican los componentes que han sido requeridos junto con el estado inicial: - Escenario virtual: El escenario inicial del proyecto se trata de una estación de tren por la que el usuario se puede desplazar libremente, con agentes ya programados para desplazarse por el entorno de forma natural, no se requieren cambios significativos al entorno sobre el que se harán las pruebas. - Inverse Kinematics: Como se ha comentado previamente, se ha usado el algoritmo de Inverse Kinematics para animar correctamente el modelo del jugador. Dado que es un algoritmo usado para hacer que el modelo responda al usuario y su movimiento, el estado inicial del proyecto no incluía ninguna implementación previa. - Modelo 3D: Dado que el estado inicial contiene una gran cantidad de modelos, se ha buscado uno que fuera lo suficientemente familiar como para facilitar que el usuario se identificara con este. - Movimiento del usuario: En el estado inicial del proyecto existe una implementación de Walk-in-place, por lo que se debe adaptar el código a las necesidades del proyecto. - Recopilación de datos: Con el objetivo de facilitar la toma de conclusiones al final del proyecto es necesario desarrollar un script que recopile la información necesaria para realizar un análisis correcto y suficiente. 49 9. Solución Propuesta En primera instancia, es preciso tener en cuenta que el objetivo final del proyecto es concretar si el método estudiado es suficiente para evitar la problemática sobre los posibles accidentes fruto del uso de Walk-in-place, llevando al usuario a rectificar su posición física de forma voluntaria para cuadrar con su modelo. La solución planteada para resolver este peligroso desplazamiento, reside en un estudio que trata con una problemática distinta [5]. Este estudio expresa la necesidad de los usuarios de cuadrar su cuerpo con su visión del avatar virtual. Esta cohesión es una respuesta automática y es por esto que se busca una reacción similar para evitar que el jugador se aleje de la zona de seguridad. Se plantea desde un inicio darle al jugador un avatar o modelo con el que pueda identificarse dentro del espacio virtual de modo que se pueda replicar el fenómeno descrito en el segundo estudio. Para reproducir esto, el avatar debe quedarse siempre en el centro de la zona segura de modo que, en todo momento, si la persona que está inmersa en el entorno se recoloca en el avatar, siempre estará aproximadamente en el centro de la zona segura. En vista a los resultados del otro estudio se estima que podríamos observar una conducta similar usando el modelo de esta forma. Para realizar este experimento se precisa un entorno suficientemente grande en el que el usuario pueda realizar varias tareas dentro de la simulación. De esta forma se busca que el usuario pueda llegar a desplazarse de forma inconsciente la distancia suficiente como para verse fuera de su modelo. El escenario también cuenta con ambientación sonora y visual para hacer del entorno una localización más creíble e inmersiva. 9.1. Limitaciones Aun con todo, existen limitaciones a la hora de solucionar este problema, que vienen dadas por su complejidad al intentar predecir o anticipar el comportamiento o reacción humano ante una discrepancia entre él y el modelo. Estas limitaciones vendrán dadas por: 50 - La visibilidad del usuario: No podemos ver por el usuario dentro del entorno así que resulta complicado hacer que este sea consciente de la separación entre él y su avatar a no ser que él mismo lo busque. A priori, para que el usuario fuera consciente sería preciso entrenarle para que de forma habitual fuera comprobando su cohesión con el modelo, sin embargo, no es factible porque incluso con entrenamiento resulta difícil acordarse de hacer algo de forma constante cuando se está realizando alguna otra actividad durante el proceso. - Animación de las extremidades inferiores: Se ha optado a animar solo las extremidades inferiores, dado que la forma más fácil de apreciar dicha discrepancia vendría por mirar el suelo y no verse a sí mismo. De ahí, nace la idea de usar un algoritmo para animar las piernas con el objetivo de seguir el movimiento de los pies del usuario. - Inverse Kinematics: El algoritmo para animar las articulaciones y extremidades del modelo, es a priori complejo. Esto se da porque resulta difícil comprender su funcionamiento correcto en base a las matrices y por ello se ha usado una alternativa que hace uso de aproximaciones vectoriales, de modo que no solo es más fácil, sino que siempre es ajustable para una mayor o menor precisión con ello cargando más o menos el proceso. Sin embargo, dado que solo se anima el movimiento de los pies, y a raíz de que cuando se anda no se levantan demasiado del suelo, los sensores no tienen una variación significativa para tener un impacto grande en la visibilidad del modelo. 9.2. La Solución Teniendo en cuenta los inconvenientes planteados, estas son las decisiones que se han tomado: 51 - Solo se animarán las extremidades inferiores, dado que la mano debe seguir a la cámara y no sería práctico, y podría causar más problemas al no coincidir con el brazo, como náuseas o mareos. - Se ha decidido añadir una tarea específica para forzar al usuario, cuando sea preciso, a mirar sus pies con la intención de ayudar al jugador. Esto supone que la reacción no será completamente automática, si no parcialmente asistida. - - Se ha mantenido la implementación de Inverse Kinematics, que, articula correctamente las extremidades con aproximaciones, aunque se ha rebajado el umbral buscando la máxima precisión. Una vez contempladas todas las limitaciones iniciales, se ha seguido el siguiente procedimiento: El modelo debe permanecer en el centro de la zona segura y el usuario deberá completar una serie de objetivos dentro del escenario. Si el usuario sobrepasa un umbral predefinido dentro de la zona segura, se activará una tarea que consistirá en recoger una bola de papel del suelo con la intención de hacer que éste vea donde se encuentra su avatar y se recoloque. Es por esto que se ha adoptado un enfoque algo diferente que busca una reacción semiautomática o asistida dado que en el caso de no obtener el resultado buscado siempre se optará por guiar de forma leve al usuario hacia lo que debería ver por sí solo. Una vez concretado el proceso que se ha llevado a cabo en el proyecto, es preciso tener en cuenta la implementación que se ha realizado. Parte importante del resultado depender de la correcta implementación tanto del movimiento como de las tareas a realizar. Se parte de la hipótesis de que el usuario será capaz de rectificar su posición al ver que su cuerpo no corresponde. 52 10. Desarrollo 10.1. Espacio virtual Aunque no se ha modificado en ningún aspecto el entorno virtual, es necesario hacer una breve descripción del escenario para comprender las decisiones que se toman posteriormente en los siguientes apartados. Para empezar, el entorno no cuenta con otros modelos ambientales con la intención de no confundir al jugador ya que debe buscar su modelo y no uno ajeno. Además, solo aquellas zonas con suficiente espacio son accesibles para mantener un entorno que no entorpezca el desplazamiento del jugador. FIGURA 4: ESCENARIO VIRTUAL. ELABORACIÓN PROPIA. Como se puede ver en la imagen, el espacio virtual se compone de una estación de tren muy amplia con diferentes espacios preparados para que el usuario acceda a ellos. Esta estación de tren está limitada por paredes invisibles para evitar sucesos no previstos, de este modo se asegura que todo vaya según lo previsto durante el muestreo. 53 10.2. Walk in place Durante el inicio del proyecto se ha hecho un estudio acerca de cómo funciona Walk-in-place. Esta metodología es una solución al problema que conlleva usar una habitación con espacio físico limitado dado que el escenario virtual suele ocupar un lugar mucho mayor. Esto supone que el usuario no tiene suficiente espacio para desplazarse libremente en la escena, no obstante, este método ofrece una inteligente solución a la limitación que encontramos. Para evitar esta complicación, el método Walk-in-place hace uso de los sensores que los dispositivos llevan integrados en los pies para mover el avatar mientras el usuario camina sobre su mismo sitio. Esto se puede hacer gracias a que dichos sensores se pueden usar para calcular una frecuencia entre paso y paso que determina la velocidad con la que se mueve el avatar virtual. Sin embargo, este método, aunque es lo más parecido a un comportamiento habitual requiere cosas muy diferentes para cada usuario. La codificación que se ha usado ya estaba incorporada en el estado inicial del proyecto y se adaptado en la medida de lo posible para poder cuadrar la animación del modelo con el movimiento particular de cada jugador. Este movimiento se calcula a partir de la siguiente ecuación: 𝑉𝑒𝑙𝐹𝑟𝑎𝑚𝑒 = 𝐴𝑏𝑠(𝑣𝑒𝑙𝑝𝑖𝑒𝐼𝑧𝑞𝑃𝑟𝑒𝑣−𝑣𝑒𝑙𝑝𝑖𝑒𝐼𝑧𝑞𝑁𝑢𝑒𝑣𝑜 )+𝐴𝑏𝑠(𝑣𝑒𝑙𝑝𝑖𝑒𝐷𝑒𝑟𝑃𝑟𝑒𝑣−𝑣𝑒𝑙𝑝𝑖𝑒𝐷𝑒𝑟𝑁𝑢𝑒𝑣𝑜) 𝑡𝑖𝑒𝑚𝑝𝑜𝑓𝑟𝑎𝑚𝑒𝑁𝑢𝑒𝑣𝑜+𝑡𝑖𝑒𝑚𝑝𝑜𝑓𝑟𝑎𝑚𝑒𝐴𝑛𝑡𝑒𝑟𝑖𝑜𝑟 FIGURA 5: SENSORES HTC VIVE. ELABORACIÓN PROPIA 54 Como se puede ver en la formula superior, la velocidad del frame actual es la que se obtiene de la media entre los valores absolutos de la diferencia entre la altura/velocidad de los pies entre frames. Esto calcula la velocidad del jugador dentro de la escena a cada ciclo. Dado que no es un cálculo que dependa de la posición del sensor en el espacio, no resulta difícil de entender que se deben hacer asunciones a la hora de mover al modelo, como es el caso de decidir cuando este empieza o termina su desplazamiento. Es por ello que a veces se produce un pequeño derrape al principio y al final del movimiento. 10.3. Modelo 3D del jugador El proyecto precisa un modelo con el que el jugador pueda identificarse sin que este suponga un problema en ningún momento cuando se realiza la simulación. Es por ello que se han contemplado diversos modelos durante el desarrollo para cumplir con la función deseada. A continuación, se exponen varias de las opciones que se han contemplado para cumplir con las necesidades del estudio: - Y-Bot: En primera instancia, dada la necesidad de tener en cuenta la posición del avatar, se ha propuesto un modelo con un diseño más vistoso o llamativo con el objetivo final de facilitar al usuario el hecho de reconocer si su avatar está fuera de lugar o no. Como se ve a continuación Y-Bot es un modelo con una ambientación más orientada a un personaje ficticio o sobrenatural, cosa que lo hace mucho más llamativo y fácil de distinguir. 55 FIGURA 6: MODELO 3D Y-BOT. ELABORA PROPIA. Sin embargo, aunque el modelo añade una figura humanoide con unos colores y estructuras muy visibles y reconocibles, se ha desestimado esta opción dado que su estructura no es compatible con el motor de Unity3D. Esta incompatibilidad se debe a que el apartado de animación del modelo no va ligado a la carcasa del mismo. Esto se debe a que en los modeladores 3D cuando se construye un modelo humanoide se suele crear un esqueleto interno que facilita la articulación de cada parte del cuerpo. Es por este motivo que al observar que el esqueleto no coincidía con la carcasa se descartó como opción viable. - Space Robot Kyle: Este modelo ha sido el substituto de Y-Bot, que a diferencia del primero si contiene una estructura correctamente diseñada y preparada para usarse con Unity3D. En este caso, la estructura o esqueleto del modelo, no solo es más identificable, sino que es mucho más conexa entre carcasa y estructura. Como se ve a continuación, 56 aunque el color no es especialmente llamativo, definitivamente es fácilmente visible para el usuario. FIGURA 7 : SPACE ROBOT KYLE. UNITY ASSET STORE. [16]. Dado que en este caso el esqueleto corresponde con la carcasa, se ha podido usar este modelo como base para animar las articulaciones mediante el algoritmo de Inverse Kinematics. Sin embargo, una vez realizado el proceso de animación se ha decidido desestimar el modelo dado que no encaja dentro del entorno de la simulación ya que la intención es que el modelo sea el habitual o lo más parecido a un modelo realista. - Rocket Male 1: Finalmente, a petición del tutor, se cambió el modelo por uno sacado de una librería externa llamada RocketBox[17]. De ahí se ha elegido un modelo con forma humanoide que fuera lo más parecido a lo que cualquier usuario podría reconocer por la calle. Estos modelos ya están diseñados con la intención de ser usados en Unity 3D de modo que el proceso de animación es el mismo que el que se usó con el modelo Space Robot Kyle. A continuación, se puede ver el modelo dentro del entorno: 63 - Rotación de los huesos: En el entorno en el que estamos trabajando, sin embargo, se contemplan tres dimensiones y por ello también se contempla la rotación de los miembros. Esto se produce durante los pasos previamente explicados, donde además de realizar el movimiento, se rota el nodo sobre el plano formado entre este y la perpendicular formada por el nodo anterior y posterior, de modo que se forma una circunferencia de posibles posiciones. De todas las posibles se elige la posición más cercana al Pole, que funciona como guía dejando solo una posición de toda la circunferencia creada como solución a dicha rotación. Esto se usa en parte para asegurar que los miembros giran o se doblan hacia las direcciones adecuadas. FIGURA 14: ROTACIÓN DEL HUESO. ELABORACIÓN PROPIA. Como se puede ver en la imagen B’ es el punto más cercano sobre el plano azul a la proyección del Pole sobre el mismo. Si se diera el caso en que Pole estuviera sobre la línea amarilla, esto supondría que el hueso o B se situaría bajo este, pero no supondría una deformación sino un giro en la circunferencia sobre el plano en tres dimensiones. 64 10.5. Tareas de la simulación Como último aspecto de desarrollo, se han diseñado una serie de tareas para incentivar el movimiento del usuario. Esto ayuda a recrear el fenómeno que intentamos corregir. A mayor es el tiempo de juego, mayor es la posibilidad de salirse de la zona segura. A continuación, se explica brevemente cada una de las tareas: - Sacar un billete de tren: Dado que la escena es una estación y tiene listas unas dispensadoras de billetes, se pedirá al jugador moverse hasta una e interactuar con ella para sacar un billete. Para completar la tarea, deberá interactuar con la máquina pulsando el gatillo del mando cuando la apunte con el mismo y luego del mismo modo deberá recoger el billete una vez aparezca. FIGURA 15: MÁQUINA DE BILLETES DE TREN. ELABORACIÓN PROPIA. 65 - Caminar hasta el andén 3: Como sería lógico en un escenario real el usuario compraría su billete y luego localizaría el lugar al que debe ir. En este caso se ha elegido la plataforma 3 para incitar al usuario a recorrer una distancia grande. FIGURA 16: ANDÉN NÚMERO 3. ELABORACIÓN PROPIA. - Sacar un refresco de la máquina: Como objetivo final de la prueba se pide al usuario que de media vuelta y localice una máquina de refrescos. Del mismo modo que en la primera tarea, la interacción con la máquina se realiza mediante el mando, teniendo que interactuar con la máquina y posteriormente con la lata. FIGURA 17: MÁQUINA DE BEBIDAS. ELABORACIÓN PROPIA 66 - Recoger una bola de papel: Este objetivo no es requerido para completar la simulación, pero está diseñado como medida para ayudar al jugador a darse cuenta de su posición. Si el jugador se separa a más de medio metro del centro de la zona segura, esta tarea reemplaza a cualquiera de las otras. Esta tarea quiere forzar al usuario a mirar hacia su avatar y que este se dé cuenta no están alineados. Esto es necesario porque cuando un usuario se encuentra dentro de una simulación no es capaz de darse cuenta inmediatamente del desplazamiento involuntario que le ha hecho desincronizarse del avatar. FIGURA 18: BOLA DE PAPEL. ELABORACIÓN PROPIA. En el momento en el que aparece la tarea, con esta, también aparece una bola de papel que el usuario debe recoger. En la siguiente figura, se puede ver como dentro de la simulación aparece el papel en el suelo y en medio de la pantalla se puede observar como se ha marcado la tarea a realizar. FIGURA 19: TAREA DE RECOLECCIÓN DE PAPEL. ELABORACIÓN PROPIA. 67 11. Análisis de los datos Una vez finalizado el desarrollo se procede a crear el estudio. Para realizar la investigación propuesta ha sido necesario evaluar cómo se comporta el usuario dentro del entorno. Por ello se ha hecho un script que recoge durante el muestreo los datos necesarios para analizar si la solución propuesta realmente satisface la hipótesis inicial. Junto con el tutor de proyecto, se ha estimado que una muestra superior a seis es suficiente como para extraer una conclusión inicial sobre el proyecto, cosa que permitirá decidir si merece la pena proceder con un estudio en profundidad con más tiempo y recursos dedicados o si es preciso desestimarlo. 11.1. Variables Para realizar el estudio, queremos ver el efecto que tiene en el usuario la tarea de recoger un papel, ya que esta aparece cuando su posición empieza a ser peligrosa. Por ello durante el muestreo se han registrado diferentes datos para poder proceder a un análisis del impacto de la tarea en el comportamiento del usuario. - Distancia: Durante el periodo de muestreo se registra la distancia entre el usuario y el centro de la zona segura. Para extraer esta medida se calcula el punto medio entre ambos sensores en los pies sobre la misma altura y posteriormente se calcula la distancia entre el centro de la zona segura y el centro del jugador. Se toma como referencia el punto medio de los pies en altura cero dado que, si no se elimina la altura, se tiene en cuenta una distancia en tres dimensiones en vez de en dos. Si no se calcula en dos dimensiones tenemos en cuenta la altura del pie cuando el usuario realiza Walk-inplace y eso haría que los datos no fueran correctos. 68 - Tiempo: Como es necesario evaluar cuando suceden los fenómenos a corregir y dado que el muestreo requiere registrar distancias que varían con el tiempo, hemos recogido el estado del cronometro interno con cada registro que se ha hecho de la distancia. Para mantener un estudio coherente se han tomado muestras con diferencias de 5 segundos entre ellas, sin embargo, para muestreos posteriores se han ajustado los registros cada menos tiempo dado que no se aprecia en algunos casos cuando suceden los cambios importantes o si se sobrepasa el umbral de medio metro que lanza la tarea especial. 11.2. Fase de entrenamiento Durante el proceso de muestreo se han tenido en cuenta varias cosas que tienen cierta importancia a la hora de hacer el estudio. Durante las pruebas se ha escalado el modelo a la altura del jugador. Esto implica que el jugador es capaz de ver si el modelo corresponde correctamente con su movimiento y puede verlo durante la simulación. Al principio de la prueba se colocan los dispositivos en su sitio antes de empezar el registro de datos. Esto ayuda al usuario a familiarizarse con el entorno. Se le da unos segundos para colocarse en el centro de la zona y por primera vez debe encuadrarse con el modelo. Este tiempo de adaptación sirve como entrenamiento para que luego sea capaz de ver en el caso de separarse como debe situarse para volver al punto de partida. Una vez el jugador se ha situado en la posición de inicio se le insta a mirar al frente y pulsar dos botones en el mando. Dichos botones se encargan de escalar el modelo para cuadrar el movimiento, calibrar el modelo para colocarlo en el suelo y finalmente desactivan el bloqueo al movimiento. Así, durante la fase de familiarización el usuario no tiene que preocuparse de movimientos no intencionados. 69 11.3. Muestreo Una vez se ha realizado el entrenamiento se procede a liberar al usuario. Durante la prueba el usuario se mueve libremente por el espacio con la única indicación de que tiene una barrita azul que muestra cual es la tarea actual. Es entonces cuando se activa el registro de tiempo, distancia y se observa desde el editor si sucede cualquier problema. Durante las pruebas, se han observado varias conductas. Estas no han supuesto un inconveniente pues es necesario controlar ciertos aspectos para asegurar que el jugador no está en peligro, pero suponen un aspecto a tener en cuenta durante la conclusión. Se ha observado repetidas veces la obtención de la tarea de recoger un papel de forma consecutiva dado que el usuario ha recogido el papel sin corregir previamente su posición. Esto no solo incomoda al usuario que no entiende que pasa, sino que le avisa de que algo no va bien. Esta conducta suele ir seguida de una corrección de la posición algo más tarde. En otros casos se ha observado una corrección casi inmediata al obtener la tarea de recolección de papel. Aunque esto no ha causado la interrupción de la conducta más adelante. Esto puede suponer que, aunque es una solución eficaz, recoger el papel puede suponer una tarea muy repetitiva y común que puede acabar agotando al jugador. En muy pocos casos se ha observado como el jugador ha corregido por si solo la posición sin la ayuda de la tarea especial, esto se ha dado principalmente por la necesidad de girarse completamente y ver el cuerpo desplazado. Esto sin embargo, aunque sería la mejor respuesta posible, ha resultado ser la conducta menos frecuente durante el muestreo. 70 11.4. Análisis del muestreo En este apartado se van a contemplar los distintos gráficos que se han extraído del muestreo para ver que con qué frecuencia sucede el fenómeno a solucionar y si la metodología usada obtiene un resultado adecuado. A continuación, se exponen diferentes gráficos en los que se puede ver los datos registrados: - Tres pruebas de un solo usuario: Como se puede se puede ver en la figura 13, tal y como se esperaba del proceso de Walk-in-place, el usuario se ha desviado bastante y a menudo del centro de la zona de seguridad. En la imagen se puede ver una recta de color amarillo que marca el umbral destinado a cambiar la tarea a recoger un papel. Este límite se sitúa a medio metro de distancia para asegurar al jugador. En este caso se pueden observar leves correcciones que no han 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 020 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 Distancia en metros Tiempo en Segundos Series1 Series2 Series3 FIGURA 20: TRES MUESTRAS DE UN SOLO USUARIO. ELABORACIÓN PROPIA. 71 requerido asistencia, pero han acabado por no ser suficientes para mantenerse por debajo del límite. Además, se puede observar como en algunos casos la tarea de recolección no ha sido suficiente para incentivar al usuario a corregir su posición, aunque cuando si es eficaz se observa una caída en la distancia muy pronunciada que mantiene al usuario en un entorno seguro. - Muestras de usuarios diferentes: Como se puede apreciar en la imagen el movimiento de cada usuario es muy distinto a lo largo de la muestra. El hecho de darles completa libertad para explorar el entorno y solo unos objetivos a completar, supone que no todas las muestras terminan en el mismo punto. 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 020 40 60 80 100 120 140 160 180 200 220 240 260 280 300 320 340 360 380 Distancia en metros Tiempo en segundos FIGURA 21: MUESTRAS DE 3 USUARIOS DISTINTOS. ELABORACIÓN PROPIA. 72 En el gráfico anterior se puede apreciar como uno de los participantes se mantiene durante toda la muestra por debajo del umbral haciendo pequeñas correcciones mientras que los otros dos tienen una mayor tendencia a desviarse del centro. Aún con eso, los dos casos que sobrepasan el borde reculan hacia el centro cuando obtienen la tarea especial. Esto, aunque corrige su posición cuando se exceden no supone una medida absoluta que previene futuras desviaciones, de modo que, si no existe una variedad de tareas especiales, puede caerse en una desagradable repetitividad. - Estudio de las muestras: Una vez tomadas todas las muestras se han evaluado los datos para ver si los resultados son prometedores. De cada muestra, se ha hecho la media y extraído la varianza de la distancia. Registros Media Varianza Muestra A 46 0.2207765 0.015004789 Muestra B 27 Muestra C 0. Muestra D 50 Muestra E 63 Muestra F 68 Muestra G 50 Muestra H 50 Muestra I 76 Muestra J 58 Muestra K Muestra L Muestra M Muestra N Muestra O Muestra P 49 0.116939254 0.011119499 Medias Totales - 0,24099083 0,01357576 TABLA 9: ESTADÍSTICAS DE LAS MUESTRAS. ELABORACIÓN PROPIA. 79 [10] U. Technologies, «Plataforma de desarrollo en tiempo real de Unity | Motor de VR y AR en 3D y 2D». https://unity.com/es (accedido oct. 11, 2021). [11] «RStudio | Open source & professional software for data science teams». https://rstudio.com/ (accedido oct. 11, 2021). [12] «GitHub: Where the world builds software», GitHub. https://github.com/ (accedido oct. 04, 2021). [13] «Emmagatzematge en núvol per a casa i la feina: Google Drive». https://www.google.com/intl/ca/drive/ (accedido oct. 04, 2021). [14] «Selección de perfiles cualificados | Hays Recruiting Experts Worldwide». https://www.hays.es/ (accedido oct. 09, 2021). [15] «Precios coworking Barcelona», Coworkidea. https://coworkidea.com/tarifas/ (accedido oct. 11, 2021). [16] «Space Robot Kyle | 3D Robots | Unity Asset Store». https://assetstore.unity.com/packages/3d/characters/robots/space-robotkyle-4696 (accedido dic. 29, 2021). [17] M. Gonzalez-Franco et al., «The Rocketbox Library and the Utility of Freely Available Rigged Avatars», Front. Virtual Real., vol. 1, 2020, Accedido: 14 de enero de 2022. [En línea]. Disponible en: https://www.frontiersin.org/article/10.3389/frvir.2020.561558 [18] A. Owen-Hill, «Inverse Kinematics in Robotics: What You Need to Know», RoboDK blog, 14 de junio de 2021. https://robodk.com/blog/inversekinematics-in-robotics-what-you-need-to-know/ (accedido dic. 30, 2021). [19] EgoMoose, FABRIK (Inverse kinematics), (2 de junio de 2016). Accedido: 30 de diciembre de 2021. [En línea Video]. Disponible en: https://www.youtube.com/watch?v=UNoX65PRehA 80 15. Anexo FIGURA 22: GRÁFICO DE LA MUESTRA A. ELABORACIÓN PROPIA. FIGURA 23: GRÁFICO DE LA MUESTRA B. ELABORACIÓN PROPIA. 81 FIGURA 24: GRÁFICO DE LA MUESTRA C. ELABORACIÓN PROPIA. FIGURA 25: GRÁFICO DE LA MUESTRA D. ELABORACIÓN PROPIA. 82 FIGURA 26: GRÁFICO DE LA MUESTRA E. ELABORACIÓN PROPIA. FIGURA 27: GRÁFICO DE LA MUESTRA F. ELABORACIÓN PROPIA. 83 FIGURA 28: GRÁFICO DE LA MUESTRA G. ELABORACIÓN PROPIA. FIGURA 29: GRÁFICO DE LA MUESTRA H. ELABORACIÓN PROPIA. 84 FIGURA 30: GRÁFICO DE LA MUESTRA I. ELABORACIÓN PROPIA. FIGURA 31: GRÁFICO DE LA MUESTRA J. ELABORACIÓN PROPIA. 85 FIGURA 32: GRÁFICO DE LA MUESTRA K. ELABORACIÓN PROPIA. FIGURA 33: GRÁFICO DE LA MUESTRA L. ELABORACIÓN PROPIA. 86 FIGURA 34: GRÁFICO DE LA MUESTRA M. ELABORACIÓN PROPIA. FIGURA 35: GRÁFICO DE LA MUESTRA N. ELABORACIÓN PROPIA. 87 FIGURA 36: GRÁFICO DE LA MUESTRA O. ELABORACIÓN PROPIA. FIGURA 37: GRÁFICO DE LA MUESTRA P. ELABORACIÓN PROPIA. 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 010 20 30 40 50 60 70 80 90 100 110 120 Distancia en metros Tiempo en segundos Gráfico_P