IMT375 UCB Template Copy

UNIVERSIDAD CATÓLICA BOLIVIANA “SAN PABLO”
UNIDAD ACADÉMICA REGIONAL LA PAZ

FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA MECATRÓNICA
LABORATORIO DE REALIDAD VIRTUAL EDUCATIVO

PARA NEUMÁTICA E HIDRÁULICA (IMT-241)
Proyecto de grado presentado para la obtención del Grado de

Licenciatura en Ingenierı́a Mecatrónica
Por: Amilkar Jhonny Massy Fernandez
Tutor: Ing. Diego César Calderón Iturricha
Relator: Ing. Freddy Fernando Ferrufino Gutierrez
Celular: 70104301
Correo: amilkar.massy@ucb.edu.bo
La Paz - Bolivia
Agosto, 2020
DEDICATORIA
Con todo mi corazón a mi papá Jhonny, mi

mamá Susana, mi hermana Neva y mi hermano
Erick. Por su amor y su apoyo incondicional.
Gracias por ser parte de mi vida.

AGRADECIMIENTOS
A Dios por su guı́a a lo largo de mi formación profesional.
A mi profesor tutor, M. Sc. Diego César Calderón Iturricha por su calidad humana y apoyo
constante a lo largo de este trabajo. A mi profesor relator, Ing. Freddy Fernando Ferrufino
Gutierrez por su guı́a y apoyo en la toma de decisiones del proyecto.
Al M. Sc. Rodrigo Botelho, M. Sc. Elizabeth Pommier, M. Sc. Fabio Diaz, Ing. Jhon Ordoñez
e Ing. Guillermo Sahonero por su tutela y apoyo en los respectivos momentos a lo largo de
mi carrera.
A mis amigos Mateo Barriga, Andres Guaman, Ramiro Valdez, Néstor Chura, Pablo Omonte,
Fernanda Campos, Andres Mejı́a, Marcos La Serna y Olber Guzmán por los ánimos y por
compartir esta etapa de mi vida.
iv
Resumen
El COVID-19 ha cambiado de forma global e instantánea la forma en la que se imparte

la educación, ya que tanto escuelas como universidades han tenido que migrar el sistema
educativo a un espacio virtual con técnicas de e-learning, la Universidad Católica Boliviana
“San Pablo” no fue la excepción y se ha visto en la obligación de cerrar sus laboratorios y
talleres por lo que el objetivo del presente proyecto fue implementar un laboratorio orientado
al entrenamiento con realidad virtual para la materia de NEUMÁTICA E HIDRÁULICA
(IMT-241), que permita a los estudiantes obtener conocimiento practico y teórico de un
laboratorio real. El proyecto se ha enfocado en el análisis y simulación de componentes
neumáticos de la serie MICRO existentes en el laboratorio de la UCB, con los que se reali-
zan las primeras prácticas de laboratorio en la asignatura y ha sido validado por el docente
experto en la materia. El prototipo se ha implementado basado en teorı́a de grafos con el
SDK de GoogleVR y el motor de desarrollo Unity 3D para la plataforma Android que es
común entre los estudiantes de ingenierı́a mecatrónica y que permite realizar una correcta
inmersión de realidad virtual junto a un HMD de tipo Slide-on.
Palabras clave: Realidad virtual, Unity 3D, Android, Grafos, Kit de desarrollo de
software (SDK) y Reconstrucción virtual.
Lı́nea de investigación: E-learning – Entrenamiento con realidad virtual.

v
Abstract
The COVID-19 has globally and instantaneously changed the way in which education is delivered,
since both schools and universities have had to migrate the educational system to a virtual space
with e-learning techniques, the Bolivian Catholic University “San Pablo” was not the exception and
it has been forced to close its laboratories and workshops, so the objective of this project was to
implement a laboratory oriented to training with virtual reality for the subject of PNEUMATICS
AND HYDRAULICS (IMT-241), which allow students to gain practical and theoretical knowled-
ge from a real laboratory. The project has focused on the analysis and simulation of pneumatic
components of the MICRO series existing in the UCB laboratory, with which the first laboratory
practices in the subject are carried out and has been validated by the expert teacher in the area. The
prototype has been implemented based on graph theory with the GoogleVR SDK and the Unity
3D development engine for the Android platform that is common among mechatronics engineering
students and that allows a correct virtual reality immersion together with an HMD of Slide-on type.
Keywords: Virtual reality, Unity 3D, Android, Graphs, Software Development Kit
(SDK) and Virtual Reconstruction.
Research area: E-learning - Virtual reality training.

Índice
1. Marco Referencial 1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Lı́mites y Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.1. Lı́mites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5.2. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Marco Teórico 6
2.1. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Cascos de realidad virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3. Motor de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4. Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. Fundamentos Teóricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1. Entrenamiento y capacitación con realidad virtual . . . . . . . . . . . . . . . 20
2.2.2. Fundamentos del HDM slide-on . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3. Grafos y resolución de algoritmos de grafos . . . . . . . . . . . . . . . . . . . 29
2.2.4. Metodo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.5. Scripting, métodos y fundamentos: Unity . . . . . . . . . . . . . . . . . . . . 34
2.2.6. Modelado para realidad virtual . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3. Marco Práctico 41
3.1. Esquema general del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2. Planeación y requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.1. Detección de elementos para el desarrollo . . . . . . . . . . . . . . . . . . . . 42
3.2.2. Analisis de Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.3. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.2.4. Requerimientos funcionales y no funcionales . . . . . . . . . . . . . . . . . . . 44
ÍNDICE vii
3.3. Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1. Modelos en NURBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.2. Modelos poligonales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4. Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.1. Control general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.2. Bases de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.3. Fı́sicas del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.4. Primera etapa de interacciones . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.5. Segunda etapa de interacciones . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.6. Tercera etapa de interacciones . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5. Validación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.1. Retroalimentación Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.2. Actualizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.7. Costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.1. Costo investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.2. Costo de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.7.3. Gastos e insumos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.8. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.8.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4. Marco Conclusivo 79
4.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.3. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Bibliografı́a 82
A. Anexo: Scripts 87
A.1. Lógica de locomoción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A.2. Integral de Verlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A.3. Logica de Interpolación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.4. Lógica del Grafo y Retı́cula de selección . . . . . . . . . . . . . . . . . . . . . . . . . 95
Índice de figuras
2-1. Paso a seguir en el proceso de fotolitografı́a . . . . . . . . . . . . . . . . . . . . . . . 7

2-2. Avatar Albert Einstein, profesor del laboratorio virtual . . . . . . . . . . . . . . . . . 8
2-3. Entorno de aprendizaje, componentes de la lavadora . . . . . . . . . . . . . . . . . . 8
2-4. Muestra de variables fı́sicas para el calculo . . . . . . . . . . . . . . . . . . . . . . . . 9
2-5. Entorno para el mantenimiento de un tablero eléctrico . . . . . . . . . . . . . . . . . 10
2-6. Simulación mantenimiento bajo un automovil. . . . . . . . . . . . . . . . . . . . . . . 10
2-7. Técnica Raycasting, para interacción con los objetos. . . . . . . . . . . . . . . . . . . 11
2-8. Menú de interacciones con reconocimiento kinect. . . . . . . . . . . . . . . . . . . . . 12
2-9. Técnica Raycasting, para interacción con los objetos . . . . . . . . . . . . . . . . . . 12
2-10.Primer escenario puzzle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2-11.Modelo y simulación de los controles del aeroplano ”Tucano”. . . . . . . . . . . . . . 14
2-12.Casco de realidad virtual, VR Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2-13.Casco de realidad virtual, HTC Vive. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2-14.Casco de realidad virtual, Microsoft HoloLens . . . . . . . . . . . . . . . . . . . . . . 17
2-15.Entorno Unreal Engine 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2-16.Entorno Unity3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2-17.Link Trainer, simulador de vuelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2-18.Simulación manejo de una grúa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2-19.Tamaño real de los sensores inerciales en un teléfono móvil. . . . . . . . . . . . . . . 26
2-20.Eje de coordenadas respecto a un teléfono móvil. . . . . . . . . . . . . . . . . . . . . 30
2-21.Representación grafica de un grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2-22.Representación de un grafo por listas. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2-23.Diagrama de método de desarrollo cascada. . . . . . . . . . . . . . . . . . . . . . . . 34
2-24.Modelado en NURBS, geometrı́a automatizada. . . . . . . . . . . . . . . . . . . . . . 39
2-25.Modelado poligonal, la topologı́a del modelo se ve reducida a medida que bajan sus
polı́gonos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3-1. Esquema general del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3-2. Analisis de componentes de la serie MICRO con el docente experto en la materia. . . 43
3-3. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3-4. Modelos que se utilizaron en el circuito de evaluación. . . . . . . . . . . . . . . . . . 47
3-5. Código identificador de un regulador de caudal. . . . . . . . . . . . . . . . . . . . . . 48
3-6. Contorno del plano del laboratorio de la UCB. . . . . . . . . . . . . . . . . . . . . . 50
ÍNDICE DE FIGURAS ix
3-7. Modelo del laboratorio de la UCB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3-8. Cilindro doble efecto, retocado y nomales bien orientadas. . . . . . . . . . . . . . . . 51
3-9. Diagrama de clases del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3-10.Botones de reinicio y de salida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3-11.Informe de depuración para requerimiento RF03 y RF04. . . . . . . . . . . . . . . . 54
3-12.Requerimiento RF03 implementado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3-14.Informe de depuración requisito RF05. . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3-15.Requisito RF05 y RF06 implementado. . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3-16.Retı́cula de selección y su configuración. . . . . . . . . . . . . . . . . . . . . . . . . . 56
3-18.Informe de depuración requerimiento RF08 y transformación del usuario. . . . . . . 57
3-20.Cuerpo articulado de manguera neumática . . . . . . . . . . . . . . . . . . . . . . . . 59
3-21.Fisica de mangueras implementada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3-25.Control de un cilindro doble efecto, circuito de pruebas. . . . . . . . . . . . . . . . . 63
3-26.Colisionadores implementados en los conectores. . . . . . . . . . . . . . . . . . . . . 64
3-27.Nomenclatura para guardar el extremo de la manguera. . . . . . . . . . . . . . . . . 64
3-28.Representación grafica del grafo, circuito de prueba. . . . . . . . . . . . . . . . . . . 65
3-29.Nomenclatura para el reconocimiento de instrumentos neumáticos. . . . . . . . . . . 66
3-30.Requerimiento RF14 y RF15 implementados. . . . . . . . . . . . . . . . . . . . . . . 66
3-31.Proceso de verificación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3-34.Instrumentos neumáticos rotulados según normas de realidad virtual. . . . . . . . . . 70
3-35.Mapeo del control Bluetooth, hallado vı́a código. . . . . . . . . . . . . . . . . . . . . 71
3-36.Hardware que integra el proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3-37.Software que integra el proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3-38.Laboratorio en la realidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3-39.Prueba final, prototipo con los requerimientos implementados. . . . . . . . . . . . . . 77
3-40.Laboratorio en la realidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3-41.Matriz ingresada a través de la interfaz de usuario. . . . . . . . . . . . . . . . . . . . 78
Índice de tablas
1-1. Clasificación de los entornos experimentales . . . . . . . . . . . . . . . . . . . . . . . 1
2-1. Signo lectura esperada del giroscopio . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2-2. Lectura esperada del acelerómetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2-3. Posiciones, rotaciones y cuaternión esperado del teléfono móvil . . . . . . . . . . . . 27
2-4. Representación del grafo de la figura 2-21 en arreglos. . . . . . . . . . . . . . . . . . 32
3-1. Elementos principales del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3-2. Requisitos funcionales generales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3-3. Requisitos básicos de la UI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3-4. Requisitos de las cuatro etapas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 46
3-5. Requisitos no funcionales generales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3-6. Requisitos para generar las tres ilusiones. . . . . . . . . . . . . . . . . . . . . . . . . 47
3-7. Ensambles comunes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3-8. Ensamble de instrumentos principales. . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3-9. Modelos poligonales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3-10.Antes y después de la reducción de polı́gonos. . . . . . . . . . . . . . . . . . . . . . . 51
3-11.Requisitos funcionales y no funcionales actualizados . . . . . . . . . . . . . . . . . . 69
3-12.Costo de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3-13.Costo de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3-14.Costo de ejecución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3-15.Costo de insumos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3-16.Gasto en electricidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3-17.Gasto en internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
CAPÍTULO 1
Marco Referencial
1.1. Introducción
El desarrollo de la capacidad de análisis crı́tico y de aplicación del conocimiento es de fundamen-
tal importancia en la formación del estudiante de ingenierı́a, por lo cual las metodologı́as de la
educación han evolucionado y se han adaptado a los entornos tecnológicos del presente siglo. Esta
noción, fundamentada bajo el término e-learning o educación electrónica, es un concepto sujeto
a varias definiciones. Josep M. Boneu [1] lo define como: “El último paso en la evolución de la
educación a distancia y como una herramienta que proporciona la oportunidad de crear ambientes
de aprendizaje que se caracterizan por ser interactivos, eficientes y de fácil acceso”.
Paralelamente tenemos el concepto de laboratorio virtual (VL), elemento esencial que posee el e-
learning, que desde su creación se ha definido por expertos [2] como: “ un espacio electrónico de
trabajo concebido para la colaboración y la experimentación a distancia con objeto de investigar o
realizar otras actividades creativas, y elaborar y difundir resultados mediante tecnologı́as difundidas
de información y comunicación” (UNESCO, 2000). Desde esta perspectiva, es evidente la relación
existente entre el concepto de laboratorio virtual y e-learning, que como resultado al dı́a de hoy se
han patentado cuatro diferentes entornos de prácticas experimentales (Tabla 1-1).
Tabla 1-1: Clasificación de los entornos experimentales 1 .

Laboratorio Real Virtual
Laboratorios precenciales con Laboratorios presenciales con
Local
plantas reales plantas simuladas
Tele-operación de una planta Laboratorio remoto con plan-
Remoto
real tas simuladas
1 Fuente: “Laboratorios remotos y virtuales en enseñanzas técnicas y cientı́ficas”[3].
Las experiencias de laboratorio son crı́ticas para el proceso de aprendizaje en todos los dominios
de ingenierı́a. El e-learning nos presenta dos tipos de laboratorios; el laboratorio real remoto, que
permite interactuar con los instrumentos del laboratorio a través de internet y el laboratorio remoto
1.2 Planteamiento del Problema 2
virtual, que permite realizar prácticas de laboratorio a través de una simulación o inmersión 3D
mediante la realidad virtual (VR). En 2019 un estudio hecho por Hernández, Vallejo y Morales [4]
en universidades alrededor del mundo, determino que los laboratorios remotos virtuales frente a los
laboratorios remotos reales son la mejor opción viable demostrando ser semejantes a los laborato-
rios prácticos tradicionales y con muchas ventajas de por medio, principalmente su baja inversión,
bajos costos de mantenimiento y facilidad de replicación para satisfacer la demanda de los usuarios.
Es entonces que se presenta la realidad virtual (VR) como una plataforma abierta de aprendizaje
y componente necesario del e-learning. La realidad virtual es una interfaz y aplicación informáti-
ca para la creación de entornos virtuales y fantásticos que pueden tratarse con efectos visuales,
sonoros y táctiles, llegando a ser una herramienta tecnológica emergente que se ha aplicado en
sistemas educativos a nivel global. De forma que laboratorios virtuales que permiten una inmersión
3D proporcionan al usuario experiencias, vivenciales emocionales, y es precisamente el carácter
emocional de la investigación en neurociencia que considera la emoción como una de las principales
claves del aprendizaje, y la realidad virtual tiene todo el potencial para trabajar con los estudiantes
y sus emociones, como estrategia educativa, su aporte es de inestimable valor para los profesores [5].
En los últimos años, se han hecho estudios que evidencian que la inmersión 3D puede favorecer el
proceso enseñanza aprendizaje. En 2014 un estudio de Loureiro, Ana & Bettencourt y Teresa [6],
demostró que los alumnos tienden a sentirse más abiertos, seguros, creativos y comprensivos en un
entorno 3D mejorando el progreso de aprendizaje. Otro estudio [7], confirmo que la realidad au-
mentada fue un método eficaz de aprendizaje y no solo para estudiantes regulares, sino que también
se desarrolló la prueba con estudiantes con discapacidades intelectuales y autismo lo que resulto de
la prueba fue que antes de la inmersión 3D el estudiante con autismo tenı́a un 30 % de respuestas
correctas para un tema en cuestión, en cambio después de usar la realidad virtual obtuvo un 80 %
de respuestas correctas (McMahon DD, Cihak DF, Wrigth RE y Bell SM, 2016). Esto sugiere que
la realidad virtual en la educación también podrı́a llegar a ser un gran avance en la inclusión de las
personas con discapacidad dentro del sistema educativo.
Actualmente el desarrollo de laboratorios virtuales cimentados en la realidad virtual continua [8],

alcanzado campos de todo nivel de complejidad como la medicina, ingenierı́a, bellas artes, historia,
etc. A razón de la anterior premisa el objeto del presente documento plantea la implementación de
un laboratorio virtual remoto para la carrera de Ingenierı́a Mecatrónica en la Universidad Católica
Boliviana “San Pablo”, inicialmente con la asignatura IMT-241, materia fundamental para en
el área de la automatización e industria donde se precisa conocimiento operacional practico de
diferentes dispositivos de neumática e hidráulica.
1.2. Planteamiento del Problema

El e-learning ha ganado relevancia en los últimos años siendo una herramienta con muchas ventajas
para el proceso enseñanza-aprendizaje llegando a ser un modelo educativo en tendencia, que con la
presente situación internacional; crisis de alama sanitaria (Pandemia COVID-19); se considera más
1.3 Objetivos 3
bien una necesidad, puesto que según reportes de la UNESCO al 14 de Abril del 2020 fue necesario
migrar el modelo de aprendizaje a plataformas virtuales [9], afectando al 94,1 % de la población
estudiantil con el cierre de escuelas y universidades a nivel mundial incluyendo Bolivia, que sus-
pendió sus actividades pedagógicas de forma presencial el 12 de marzo de 2020, siendo incierta la
fecha del retorno al ciclo educativo ordinario.
El área de interés que se quiere tratar con la propuesta de este proyecto es la necesidad de labora-
torios virtuales remotos en la Universidad Católica Boliviana “San Pablo” ante la crisis sanitaria
tomando en cuenta el impacto actual de este tipo de tecnologı́a en campos del e-learning, de forma
que puede llegar a ser un instrumento de gran utilidad para los estudiantes de Ingenierı́a Mecatróni-
ca y una forma de aprovechar la gran inversión de infraestructura por parte de la carrera en las
últimas gestiones, replicando los instrumentos del laboratorio en un entorno virtual para cerrar la
brecha entre el desempeño profesional y los conocimientos impartidos en la carrera.
Actualmente la universidad cuenta con plataformas como UCBx que podrı́an verse beneficiadas con
una herramienta de esta categorı́a como un aporte a futuro empezando con Ingenierı́a Mecatrónica
como un método de integrar los sistemas de gestión de aprendizaje en lı́nea (LMS) que se están
usando en los últimos dı́as coadyuvando a estudiantes a complementar y desarrollar una educación
continua con beneficios extra que son factores delimitantes laboratorios convencionales como la
duración de la práctica y horarios de uso, por ejemplo.
1.2.1. Definición del problema

La primordial necesidad de un laboratorio virtual remoto para practicas educativas por parte del
alumnado de Ingenierı́a Mecatrónica de la Universidad Católica Boliviana “San Pablo” como he-
rramienta del proceso enseñanza-aprendizaje por restricciones y limitantes existentes consecuencia
de la crisis actual (Pandemia: COVID-19).
1.3. Objetivos
1.3.1. Objetivo General
Implementar un laboratorio virtual de Neumática e Hidráulica (IMT-241) para la carrera de inge-
nierı́a mecatrónica en la Universidad Católica Boliviana “San Pablo” que brinde a los estudiantes
conocimiento practico y teórico que se obtiene de una experiencia de laboratorio real.
1.3.2. Objetivos especı́ficos

• Analizar equipos e instrumentos utilizados en la asignatura IMT-241 existentes en los labo-
ratorios de Neumática e Hidráulica de la UCB.
• Diseñar el laboratorio virtual cimentado en los requerimientos y contenidos impartidos por

el docente de la asignatura IMT-241.
1.4 Justificación 4
• Prototipar los componentes previamente analizados en el laboratorio de la UCB de forma

virtual a través del diseño asistido por computadora (CAD).
• Programar el entorno virtual en un motor grafico capaz de integrarse a múltiples plataformas

de inmersión 3D (Unity, Godot, OpenGL).
• Validar las habilidades y conocimientos adquiridos por parte del público objetivo (Estudiantes
de IMT), mediante prácticas en el laboratorio virtual.
1.4. Justificación
El presente proyecto se enfocará en desarrollar un laboratorio virtual remoto para la asignatura
IMT-241 de la carrera de Ingenierı́a Mecatrónica, debido a la reciente crisis de alarma sanitaria
(Pandemia: COVID-19), por la cual las actividades pedagógicas de forma presencial se han suspen-
dido en Bolivia pasando a un modelo educativo basado en el e-learning. Ası́, el presente proyecto
será el primer paso que permita a los estudiantes complementar y desarrollar una educación con-
tinua como era antes de la crisis obteniendo una adecuada capacitación para posterior desempeño
profesional, además de ofrecer un evolución al actual modelo educativo basado en e-learning, con las
ventajas que traen los laboratorios virtuales tanto para estudiantes como para la universidad (bajos
costos de mantenimiento y facilidad de replicación para satisfacer la demanda de los usuarios).
1.5. Lı́mites y Alcances

1.5.1. Lı́mites
• El laboratorio virtual solo abarcara contenidos de la asignatura Neumática e Hidráulica
(IMT-241).
• Las interacciones del laboratorio virtual se limitarán según requerimientos de los docentes a
cargo del presente proyecto y del docente experto de la materia.
• El entorno se limitará a un laboratorio virtual con animaciones y modelado 3D.
• Se implementará el laboratorio para la plataforma Android que permite una inmersión 3D y

es común entre el público objetivo (Estudiantes de IMT)
• El laboratorio virtual estará dirigido a los estudiantes y docentes de Ingenierı́a Mecatrónica

de la Universidad Católica Boliviana “San Pablo”.
1.5.2. Alcances
• Las sesiones de aprendizaje se basarán en prácticas realizadas en laboratorios de mecatrónica
en la Universidad Católica Boliviana “San Pablo”.
1.5 Lı́mites y Alcances 5
• Estudiantes de IMT tendrán la oportunidad de una previa interacción con algunos compo-
nentes del laboratorio antes de una práctica real.
• El laboratorio virtual tendrá una interfaz amigable y fácil de comprender por los estudiantes
destinatarios.
• El laboratorio virtual será de fácil acceso y estará disponible todo momento por los usuarios
al ser una aplicación offline para celulares.
• Tras la validación positiva del laboratorio virtual, se podrán desarrollar semejantes para
distintas áreas dentro de la UCB.
CAPÍTULO 2
Marco Teórico
2.1. Estado del Arte

La siguiente investigación de estado del arte tiene el fin de conocer los diferentes dispositivos,
enfoques, consideraciones y procedimientos que se toman en cuenta en el diseño e implementación
de un laboratorio de realidad virtual e indagando con prioridad a proyectos afines al área de interés,
los entrenamientos educativos a través de la realidad virtual para posteriormente tomar decisiones
y seleccionar un método adecuado para realizar un proyecto de calidad.
2.1.1. Generalidades
El propósito de este enfoque es conocer las caracterı́sticas de un software de entrenamiento educativo
basado en Realidad Virtual de manera que este trabajo pueda cimentarse en proyectos similares y
ası́ reconocer caracterı́sticas a desarrollar como el impacto del proyecto en su culminación.
A) Towards an Immersive Guided Virtual Reality Microfabrication Laboratory

Training System
Se trata de un proyecto publicado en marzo de 2020, que expone un laboratorio en realidad virtual
gamificado para simular operaciones de un laboratorio de micro fabricación, el proceso principal
que se realiza en este laboratorio virtual es la fotolitografı́a, el software integra un sistema de pistas
inteligente que ayuda al usuario a completar seis procesos distintos a seguir para cumplir la misión,
posteriormente el software retroalimenta al participante con un informe de desempeño basado en
puntos que se obtiene del tiempo y los errores cometidos durante la práctica [10]. Este software se
desarrolló con Unity3D y Adobe Maya para Oculus Rift que es un dispositivo capaz de rastrear los
movimientos del usuario en seis grados de libertad.
El objetivo del proyecto era verificar si el laboratorio virtual podı́a mejorar el aprendizaje de una
cantidad reducida de voluntarios en base a repetidas pruebas en el entorno virtual. Los resultados
fueron favorables concluyendo en que los participantes del proyecto mejoraron su desempeño en el
laboratorio virtual después de cada prueba, el estudio del equipo de ingenieros y estudiantes en
2.1 Estado del Arte 7
Figura 2-1: Paso a seguir en el proceso de fotolitografı́a
ciencias de la computación de la Universidad de Missouri continua y en el presente trabajan en

otros entronos virtuales.
B) Utilizing virtual reality to assist students in learning physics

Se trata de un entorno educativo de realidad virtual publicado en 2017 implementado en Open-
Simulator que es una plataforma open source que a la fecha se ha probado en realidad virtual en
plataformas como google cardboard y oculus rift. El aprendizaje en este laboratorio virtual de fı́sica
que abarca temas de mecánica y fuerza, electricidad y magnetismo y estructura de la materia [11].
Algo importante del proyecto es la existencia de guı́as en el entorno virtual con avatares basados en
cientı́ficos, con los que el usuario podı́a interactuar para descubrir el funcionamiento de los modelos
animados, es un aspecto que le da más realismo a esta escena.
Después de visualizar los fenómenos fı́sicos y simular el comportamiento de los modelos anima-
dos del entorno, pasaron a hacer pruebas donde obtuvieron resultados en base a encuestas que
fueron favorables en todos los aspectos, excepto en la curva de aprendizaje ya que el laboratorio
no contiene mecanismos de análisis de aprendizaje por lo que no se puede registrar las acciones de
los estudiantes, pero es algo que dejaron como trabajo futuro junto a la gamificación de los procesos.
Figura 2-2: Avatar Albert Einstein, profesor del laboratorio virtual
C) Virtual reality as a tool in mechatronics education

Es un proyecto publicado para la plataforma HTC VIVE que se desarrolló en el motor de juegos
Unity 3D con un modelado en 3DS Max. La escena se enfocaba en la lavadora y sus componentes
para lo cual el usuario primero debı́a aprender cómo usar los controles y navegar a través del en-
torno virtual, posteriormente el usuario podı́a seleccionar un componente a analizar, resaltando y
seleccionando el mismo y finalmente el usuario podrı́a conocer la actividad de dicho componente
en el dispositivo [12].
El proyecto también cuenta con un estudio por lo que el software se puso a prueba con ayuda
de un grupo pequeño de estudiantes, que después de la experiencia eran entrevistados. El estudio
termino con datos recopilados que demuestran que la realidad virtual en mecatrónica puede ayudar
a mejorar el proceso de comprensión y memorización, algo a tomar en cuenta sobre este proyecto
fue que el equipo dejo como trabajo futuro realizar este tipo de aplicaciones en dispositivos más
portátiles y accesibles para el público objetivo.
Figura 2-3: Entorno de aprendizaje, componentes de la lavadora

D) Parabolix: Educational Simulation Game on Classical Mechanics Based on

Virtual Reality and Perlin Noise Algorithm
Un proyecto educativo de 2019 sobre simulación de mecánica clásica lanzado para la plataforma
Google cardboard, que se utiliza junto a un control bluetooth donde el usuario recibe formulas
fı́sicas para lanzar una pelota a un punto establecido en un terreno generado aleatoriamente, para
lo cual debe calcular las soluciones de dichas formulas [13].
El proyecto se ha desarrollado en el motor de juego unity3D con el lenguaje de programación C#,

para la creación de modelos 3D se usaron primitivos del motor de juego y un algoritmo de ruido
llamado Perlin que sirvió para crear terrenos aleatorios y ası́ poder cambiar la escena entre los
usuarios, es de resaltar que este proyecto también presenta un estudio sobre la interfaz del usuario
del software con algunos testimonios negativos por un porcentaje de los participantes que pensaban
que el sistema era muy difı́cil de usar por lo que se concluye que el desarrollo de una interfaz de
usuario amigable es de suma importancia en el proyecto.
Figura 2-4: Muestra de variables fı́sicas para el calculo
E) Siemens VR Training
Siemens junto a Vision Three crearon este software con el objetivo de reducir costos y esfuerzos en
capacitación de productos, de forma que puedan entrenar a operarios de sus productos en realidad
virtual, el primer proyecto presentado por esta rama de Siemens fue una simulación del mante-
nimiento de tableros eléctricos. Se trata de un software que simula el proceso paso a paso que
debe seguir un operario para tratar con el equipo, de esta forma el usuario es guiado para poder
completar la tarea, por lo que se concluye que cuenta con autómata finito, posteriormente muestra
una animación del paso a seguir, finalmente permite al usuario intentar la acción y se repite este
proceso en todos los pasos hasta completar la tarea [14].
Para ejecutar este software se requiere de un dispositivo de realidad virtual que conste de un casco
y controles con un seguimiento en 6 grados de libertad de manera que se pueda hacer el seguimiento
Figura 2-5: Entorno para el mantenimiento de un tablero eléctrico
de la posición y rotación de la cabeza y manos del usuario. Este software se desarrolló en más de dos
años y se publicó en 2019, desde entonces ayudo a reducir accidentes en planta, mejoro el trabajo
operario en cuanto a tiempo, eficiencia y costos en capacitación de operarios ya que con la guı́a que
se integra en el software ya no se precisa los servicios de un entrenador especializado.
F) STRIVR: Caso BMW

STRIVR es una empresa dedicada al desarrollo de software para capacitación en realidad virtual,
el proyecto en especı́fico con BMW se enfoca en un entrenamiento de seguridad dirigido a los
operarios de la industria antes de que puedan tener acceso a la fábrica real. La simulación en el
software se trata de una tarea peligrosa en la fábrica y se basa en una máquina de estados finitos
para determinar si el operario ha tomado las decisiones correctas, finalmente el software genera un
informe de desempeño del usuario. El software puede ejecutarse en dispositivos que cuentan con
un seguimiento en 3 grados de libertad, es decir que siguen la rotación de la cabeza del usuario.
Este software se publicó a finales del año 2016 y desde entonces ha ayudado a concienciar a los
empleados de BMW sobre tareas de alto riesgo en la fábrica [15].
Figura 2-6: Simulación mantenimiento bajo un automovil.

G) Virtual Reality as good practice for teamwork with engineering students

Es un programa educativo diseñado con principios de gamificación, su objetivo principal es enseñar
el trabajo en equipo a estudiantes de ingenierı́a donde sus acciones determinan la reconstrucción
del modelo de un barco que consta de dieciséis partes, los estudiantes saben antes de empezar la
prueba la importancia de la colaboración por lo que seleccionan roles reconociendo las fortalezas
de cada miembro del equipo [16].
Figura 2-7: Técnica Raycasting, para interacción con los objetos.
Los roles a desempeñar son desplazar las piezas, armado del barco, responsable y control del tiempo,
todos los participantes solo pueden comunicarse vı́a voz para ejecutar las estrategias de un plan
que designaron como estrategia a seguir antes de empezar, al terminar el armado del barco pueden
comparar las acciones que realizaron con la estrategia que decidieron seguir. El programa fue
desarrollado en el motor de juegos Unity en los lenguajes de programación Java y C#, el método
de interacción principal es la técnica de “rayacasting”.
H) Uso didáctico de la realidad virtual inmersiva con interacción natural de

usuario enfocada a la inspección de aerogeneradores
Es un proyecto publicado en la Universidad de Guadalajara presentada por doctores e ingenieros
del área electrónica que desarrollaron un programa de realidad virtual que funcionaba en base
a reconocimiento de gestos con fines didácticos para entrenar a los alumnos en la inspección de
aerogeneradores [17]. El software se desarrolló en el motor de videojuegos Unity para el casco de
realidad virtual Oculus Rift, el reconocimiento de gestos se hacı́a a través de un dispositivo Kinect.
El costo del proyecto fue de aproximadamente de 4000 dólares en los equipos y para el desarrollo
del software utilizaron la metodologı́a de sistemas de desarrollo en ciclos ¨Pressman¨. La lógica del
programa seguı́a un modelo de maquinas de estados finitos, adicionalmente para la validación del
proyecto se hicieron encuestas a los participantes que utilizaron el programa concluyendo al terminar
el estudio en que esta técnica puede emplearse para asignaturas similares y en que la realidad virtual
Figura 2-8: Menú de interacciones con reconocimiento kinect.
como estrategia didáctica de entrenamiento permite a los alumnos realizar practicas en situaciones
de riesgo y les permite conocer los equipo en campo antes de practicar con ellos.
I) Desarrollo de una herramienta de apoyo para el estudio de la naturaleza de

la luz usando realidad virtual inmersiva
Es una aplicación de realidad virtual que consta de siete escenarios educativos sobre el estudio de
las fı́sicas de la luz, el programa se desarrolló en Unity para plataformas móviles Android en len-
guaje C#, el programa contiene modelos de diferentes programas basados en modelado poligonal
[18]. Las mecánicas de interacción de este software se hacen a través de la técnica de ¨Raycasting¨
con una retı́cula que sirve para hacer acciones especı́ficas, todas diferentes según la escena, el tipo
de desarrollo utilizado para este programa fue la metodologı́a de Scrum y el proyecto cuenta con
guiones para cada escena entonces cuenta con una máquina de estados finitos lineal.
Figura 2-9: Técnica Raycasting, para interacción con los objetos

J) Creación de una aplicación interactiva utilizando realidad virtual para plata-

forma Android
Es un programa hecho en Unity con el lenguaje de programación C#, consiste en la resolución de
tres acertijos de diferentes dificultades, cada uno más difı́cil que la anterior, tanto las interacciones
como las acciones del usuario se hacen a través de una retı́cula con un control que se conecta
con dispositivos móviles a través de bluetooth [19]. El modelado y la animación de los objetos
Figura 2-10: Primer escenario puzzle.
del entorno virtual se hizo en Blender que es un software gratuito de modelado poligonal, pos-
teriormente se desarrollaron las mecánicas del programa en base retroalimentación de numerosas
pruebas en voluntarios para mejorar el sistema hasta la finalización del proyecto lo que se conoce
como metodologı́a de desarrollo en cascada, se usa generalmente cuando se desarrolla un proyecto
en solitario.
K) Desarrollo de una aplicación para simular un vuelo con Realidad Virtual

por el entorno ecuatoriano con el avión de combate de las Fuerzas Armadas del
Ecuador “Tucano”, para plataformas Android utilizando Unity y Google VR
Es un programa desarrollado para realizar entrenamientos de vuelo en realidad virtual para pla-
taformas Android, el proyecto se hizo en Unity con el lenguaje de programación C#. Para el
modelado del avión, del entorno y los objetos del mismo se utilizo Cinema 4D, Adobe Maya y
Subtance Painter, es decir softawares basados en modelado por polı́gonos [20]. El programa se ha
implementado con un dispositivo de entrada adicional que se trata de un control bluetooth para el
control del avión “Tucano”, la validación del proyecto se hizo en base a pruebas por lo que se usó una
metodologı́a de desarrollo incremental o tambien llamada iterativa hasta obtener la aplicación final.
Figura 2-11: Modelo y simulación de los controles del aeroplano ”Tucano”.
2.1.2. Cascos de realidad virtual

Este enfoque tiene como propósito seleccionar un hardware adecuado para el proyecto, se tomó
en cuenta la investigación del enfoque previo para elegir dispositivos verificados que conceden una
correcta inmersión 3D, ya que es de vital importancia en los entrenamientos con realidad virtual
y marcan una gran diferencia cuando se trata de obtener experiencias realistas siendo un aspecto
relevante en la validación del proyecto.
A) Slide-on HMD
El Slide-on HMD [21] que también se conoce como una configuración de RV basada en dispositivos
móviles se caracteriza por tener soportes para fijar un teléfono inteligente dentro del visor que se
pueden configurar a la posición de los ojos del usuario posibilitando que la pantalla del celular se
divida en dos imágenes diferentes actuando como las dos lentes estereoscópicas de un visor de reali-
dad virtual convencional, esto permite una correcta inmersión virtual en cuanto aspectos visuales
en espacios virtuales. Esta demás decir que la resolución para este tipo de visores se limita a la
resolución del teléfono inteligente ajustado en el soporte.
Paralelamente se aprovecha la posición del celular en el soporte para conseguir datos como el se-
guimiento de la rotación de la cabeza del usuario y la latencia de seguimiento todo esto a través
del giroscopio y acelerómetro del dispositivo móvil, otro aspecto a tomar en cuenta es el peso la
gran mayorı́a de estos visores se encuentran entre los 250 gr a 350 gr es de resaltar que hay que
sumar el peso del teléfono inteligente para saber el peso con el que se va a cargar en la cabeza.
Otros datos técnicos como el procesamiento y la actualización de los cuadros por segundo o FPS,
serán caracterı́sticas técnicas del celular que insertemos en el visor. Una ventaja importante de usar
un teléfono inteligente es la posibilidad de conectar dispositivos externos para interacción como un
mouse, controles y teclados.
Finalmente, la mayor ventaja que tiene esta forma de visualización en realidad virtual es sin duda
el costo, pues actualmente es la forma más barata y accesible de realizar una inmersión a la realidad
virtual obviando que el usuario es portador de un teléfono inteligente [22].
Los ejemplares con mayor popularidad que cumplen con los datos técnicos narrados en este docu-
mento a la fecha son:
• Samsung Gear VR.
• Google Daydream.
• VR Box , similares.
Figura 2-12: Casco de realidad virtual, VR Box.
B) Discrete HMD
Discrete HMD [23] que también se conoce como la configuración de VR conectada a una computado-
ra, es un dispositivo que contiene todo lo necesario para experimentar la realidad virtual inmersiva,
pues se compone de lentes-pantallas estereoscópicas y tienen su propia unidad de medición iner-
cial, lo único que le falta a este visor es procesamiento externo que por lo general se hace en un
computador, es decir la ventaja en cuanto a los demás visores es que si el procesamiento externo
se hace en un equipo de alta gama soportarı́a programas más sofisticados.
Este tipo de HMD es menos móvil que sus dos contrapartes ya que se conecta a la computadora
a través de cables lo que impide que el dispositivo sea completamente móvil. Una ventaja es que
muchos de los ejemplares de este tipo de visor incluyen controles para las manos del usuario que
contienen sensores de posición y rotación y dan acceso a una interacción parecida a la realidad en
cuanto a recolección y manipulación de objetos en entornos virtuales aumentando la barrera del
realismo.
Algunos de estos cascos de realidad virtual también usan sensores externos que se tratan de dis-
positivos que arrojan rayos infrarrojos, cámaras, o estaciones de base que ayudan a detectar la
posición del usuario de forma que brinda una mejor experiencia de inmersión virtual, sin embargo,
esta puede llegar a ser su mayor desventaja, pues al tener sensores externos y sumado a el costo de
una computadora es la forma más costosa de realizar una inmersión 3D actualmente [24].
Los ejemplares con mayor popularidad existentes en esta rama de HMDs son:
• HTC VIVE.
• Sony PlayStation VR.
• Oculus Rift.
Figura 2-13: Casco de realidad virtual, HTC Vive.
C) Integrated HMD
El integrated HMD [25] es el visor móvil con mejores caracterı́sticas para hacer una óptima inmer-
sión a la realidad virtual, la razón es que es un dispositivo completamente autónomo a comparación
de sus 2 contrapartes por lo que no necesita procesamiento externo de un computador o un teléfono
inteligente, aunque existe la posibilidad de conectarlo a una computadora dando como resultado
algo parecido a un Discrete HMD con la misma capacidad de arrancar programas que requieren de
mucho procesamiento.
Al igual que el anterior visor el dispositivo cuenta con controles con seguimiento de rotación y po-
sición, pero sin duda la mayor ventaja de este tipo de visor es que al ser tecnologı́a de vanguardia
los más recientes ejemplares vienen con cámaras capaces de detectar la posición de los dedos del
usuario con una precisión muy alta por lo que son dispositivos con los que podemos interactuar en
el mundo virtual de la misma forma que se hace en la realidad rompiendo por completo la barrera
del realismo.
En cuanto a resolución, actualización de cuadros por segundo, precio y peso existen variaciones
para diferentes visores autónomos, llegando a costar entre los 600$ hasta los 3 000$ como fueron
los Microsoft HoloLens [26] en su salida al mercado, algunos ejemplares son:
• Microsoft HoloLens
• Google Glass
• Oculus Quest
Figura 2-14: Casco de realidad virtual, Microsoft HoloLens
2.1.3. Motor de desarrollo

Este enfoque tiene como propósito seleccionar un entorno de desarrollo de software que integre fun-
cionalidades en programación orientada a objetos, importación de modelos 3D, capacidades graficas
para exportación a distintas plataformas, etc. El motor de desarrollo a seleccionar debe tener la
capacidad de renderizar una escena con iluminación, fı́sicas, colisiones y animaciones necesarias
para la creación de un entorno de realidad virtual.
A) Unreal Engine VR
Unreal Engine es un motor de desarrollo publicado en 1998 programado en C++, actualmente
conciliable con mas de 15 plataformas que incluyen desarrollo de programas en realidad virtual,
este software a comparación de su contraparte se ha centrado en la calidad de gráficos y rende-
rizado. Sobre infraestructura en su tienda de activos mantiene componentes que se orientan mas
a producciones de programas terminados es la razón de que los activos 3D de esta plataforma se
orientan mas en mejoras visuales o objetos prefabricados que se usan en muchos programas de muy
alta categorı́a (AAA), atribuida a desarrolladoras importantes, esta plataforma también se integra
con documentación especı́fica para el apartado de realidad virtual y realidad aumentada [27].
La comunidad de desarrolladores se amplio a partir de 2015, que es la fecha en la que lanzaron la

herramienta como software de desarrollo gratuito para proyectos que no sean juegos, de otra forma
Figura 2-15: Entorno Unreal Engine 4
los usuarios de esta plataforma deben pagar una tarifa del 5 % en regalı́as. Actualmente en el fo-
ro de Unreal existen más de 12 000 hilos sobre programación, con temas que incluyen realidad mixta.
Unreal cuenta con un lenguaje de programación propio al que le han llamado Blueprint que genera
automáticamente partes del código contando con un sistema de scripting visual y se integra junto
a C++ para la resolución de algoritmos sin nodos complejos por lo que podemos concluir que para
la generación de un script en esta plataforma se requiere de dos archivos, uno de declaración y otro
de definición [28].
B) Unity Engine VR
Unity es un motor de desarrollo publicado en 2005 que en los últimos años a llegado a ser la pla-
taforma de desarrollo más popular entre el público desarrollador en general, tanto para la creación
de software 3D como 2D. Una de las principales ventajas de este motor es que admite una gran
variedad plataformas en las que se incluyen las de realidad virtual [29].
En 2019 se publicó en su página web estadı́sticas que se relacionan con el contenido que crea la
comunidad de desarrolladores y en cuanto a realidad virtual se hallaron cifras resultantes que in-
dican que el 60 % de los programas orientados a la realidad mixta se crean con Unity, el motivo es
que actualmente es un software compatible con todas las plataformas de realidad virtual existentes.
En cuanto a infraestructura cuenta con una tienda de activos extensa con más de 40 000 produc-
tos en 3D a la fecha, sobre la documentación cuenta con material exclusivo para el desarrollo de
programas en realidad virtual y cuenta con una comunidad de desarrolladores muy activa, su foro
sostiene más de 135 000 hilos sobre secuencias de comandos que puede ser información útil para el
desarrollo del proyecto.
Figura 2-16: Entorno Unity3D
Unity3D se puede utilizar en varios lenguajes de programación, aunque el lenguaje principal usado
por la comunidad es C#, que en el presente es el lenguaje más utilizado por empresas que desarro-
llan realidad virtual, que se puede interpretar como una base de información y soluciones probadas
por la comunidad desarrolladora [30].
Es un software gratuito para estudiantes inscritos en instituciones educativas acreditadas como lo

es la Universidad Católica Boliviana ¨San Pablo¨ y el contenido que se desarrolla en el motor es
propiedad del desarrollador siempre y cuando los ingresos del programa desarrollado sean inferiores
a los 100 000 dólares en el plazo de un año. Sobre gráficos, se considera que con técnicas de
iluminación, sombreado y creación de materiales se pueden obtener resultados parecidos a los de
grandes producciones.
2.1.4. Discusión
Ya definido el estado del arte, lo que se planeó lograr con el proyecto fue crear un software educativo
de realidad virtual enfocado en la materia IMT-241 (Neumática e Hidráulica), para lo cual en este
apartado de definió las caracterı́sticas principales para la implementación del proyecto y también
se obtuvo una noción aproximada de la selección de herramientas para posterior desarrollo del
programa. En este sentido la siguiente discusión fue determinante en el desarrollo del proyecto
planteado en el Capitulo 1 del presente documento.
A) Generalidades
Con el análisis de este enfoque no solo se contempló la posibilidad de realizar algún curso de desarro-
llo orientado a aplicaciones de realidad virtual, sino que se transformó en una necesidad fundamental
para continuar el desarrollo del proyecto. Aspectos importantes y caracterı́sticas principales con las
que cuentan los proyectos estudiados en este enfoque fueron:
• Metodologı́a de desarrollo de software.

2.2 Fundamentos Teóricos 20
• Métodos de desarrollo para Realidad Virtual.
• Aplicabilidad de lógica para resolucion de algoritmos.
• Programación orientada a objetos.
• Tecnicas de modelado 3D.
B) Cascos de realidad virtual

La investigación de este enfoque ha reafirmado la idea principal de desarrollar el software para una
configuración de realidad virtual basada en teléfonos móviles ya que se han analizado las carac-
terı́sticas de los tres tipos de cascos de realidad virtual donde se hallaron ventajas relevantes en
cuanto a sus dos contrapartes, las principales que son plataformas poco comunes entre el público
objetivo, que actualmente no son asequibles por el público en general y con los problemas económi-
cos que genero la pandemia mucho menos.
Por otro lado, se consideró la posibilidad de usar un dispositivo de entrada adicional en el desarrollo
del proyecto ya que, en muchos casos como se demuestra en el primer enfoque de vez en cuando el
uso de controles externos y un mayor número de interacciones resultan contraproducentes hacia el
programa desarrollado sumando dificultad de aprendizaje en el manejo de la interfaz de usuario.
C) Motor de videojuegos
El motor elegido fue Unity porque es un programa con la capacidad de generar entornos virtuales
de calidad, además es el software que más se usa para el desarrollo de este tipo de aplicaciones
como pudimos ver en el primer enfoque. Es el mejor software para exportar el proyecto a diferentes
plataformas y cuenta con la ventaja de ser un software gratuito. Los factores importantes en su
infraestructura son las tienda de activos, la documentación y la ayuda por parte de la comunidad.
2.2. Fundamentos Teóricos

2.2.1. Entrenamiento y capacitación con realidad virtual
El entrenamiento en realidad virtual es una práctica que se ha utilizado en los últimos años en
industrias, medicina, logı́stica y servicio al cliente esto se debe en gran medida a las experiencias que
se pueden obtener de este método de capacitación porque estimulan en gran medida las facultades de
memoria y cognitivas del usuario a través de sus sentidos con imágenes, sonidos, vibraciones, olores,
etc. [31]. Adicionalmente con realidad virtual se pueden simular escenarios costosos, peligrosos y
familiares al usuario, es entonces que esta práctica se define como la simulación digital de escenarios
realistas para trabajos especı́ficos con fines de preparación y capacitación para el desarrollo de
habilidades.
A) Historia
Si bien la realidad virtual tiene una historia muy larga la investigación en este documento solo
considera una lı́nea de tiempo que abarca a aplicaciones de la realidad virtual en cuanto a entre-
namiento ya que en general gran parte de las aplicaciones a lo largo de su historia no se tratan de
experiencias en realidad virtual interactivas.
Figura 2-17: Link Trainer, simulador de vuelo.
Para empezar, tenemos a Edward Link que en 1929 creo un simulador de vuelo electromecánico
llamado ¨Link Trainer¨ [32] utilizado para entrenar al ejército estadunidense durante la Segunda
guerra mundial, este dispositivo ayudo a entrenar a más de 500 000 pilotos, decadas después Morton
Heilig un director de fotografı́a desarrollo “Sensorama” [33], era una máquina que integraba una
pantalla estereoscópica, ventiladores, generadores de olores y una silla vibradora para sumergir al
usuario en sus pelı́culas, la maquina fue patentada el año 1962.
En 1989 la NASA entra en la realidad virtual, con la ayuda de Crystal River Engineering, crea el
proyecto “VIEW”, un simulador para entrenar astronautas ese sistema cuenta con un sistema de
interacción táctil, décadas después Google mejora su servicio de mapas con imágenes de 360º y en
2010 Palmer Lucky crea un kit de gafas de realidad virtual [34] que cualquiera puede hacer y que
se utiliza para navegar en el servicio de mapas de Google.
Entre los años 2014 hasta el presente [35], se comercializan visores de realidad virtual y evolucionan
rápidamente por sus grandes aplicaciones en diferentes medios por cientos de corporaciones no solo
de entretenimiento ya que se usa en ensamblajes y diseño asistido por computador por empresas
automovilı́sticas, en medicina educativa con simulación de operaciones o atención de pacientes,
tratamiento de fobias (acrofobia, claustrofobia, vértigo ansiedad, entomofobia, etc.) y en entrena-
mientos a militares, policı́as, astronautas con simulaciones de disparos, navegación, vuelos, etc. En
cuanto a educación se ha usado en diversas áreas cientı́ficas como sociales y lo que se propone con
este proyecto es emplear la realidad virtual en el área de la neumática e hidráulica.
B) Las tres ilusiones

Se llama tres ilusiones a aspectos caracterı́sticos que debe contener un programa de entrenamiento
o capacitación en realidad virtual y son propiedades de suma importancia en el desarrollo de este
proyecto. Las tres ilusiones son:
• La ilusión de lugar
También conocida como PI (del inglés place illusion) se refiere a la sensación de estar en un
lugar. Se dice que esta ilusión es un qualia, eso significa que no hay forma de medirlo, sin
embargo, se pueden utilizar evaluaciones basadas en cuestionarios, memorias y conductas,
respuestas que se habrı́an esperado en experiencias reales. La PI es un suceso que pasa cuando
los participantes sondean los lı́mites de un entorno virtual, por lo que cuanto más investigan
el espacio digital, es mucho más probable la ruptura de esta ilusión y esto se evita con la
ilusión que viene a continuación [36].
• La ilusión de plausibilidad
También conocida como PSI (del inglés plausibility illusion) se basa en lo que se percibe de
un entorno virtual. Es la ilusión que hace creer al usuario que lo que aparentemente está
pasando realmente está pasando, aunque el usuario sepa de manera inconsciente que no está
pasando, entonces en un entorno virtual esta ilusión engloba a todos los elementos de los que
el usuario no tiene control directo por lo que esta ilusión no requiere de realismo fı́sico [36].
Esta ilusión se encarga de hacer que entorno virtual provoque una respuesta en el usuario en
base a sonidos o animaciones de otros objetos, como el ruido del ambiente o por ejemplo si
el escenario fuera en la calle se verı́an personas y autos pasar, entonces se concluye en que la
PSI genera en el usuario cambios fisiológicos y sensaciones que permiten al usuario percibir
un entorno virtual con más realismo.
• La ilusión de encarnamiento
Finalmente tenemos la ilusión de encarnamiento que se define como la experiencia de sentir
que el propio cuerpo le pertenece a uno mismo, y se refiere a la ilusión de existir en el entorno
virtual, entonces esta ilusión se encarga de hacer creer al usuario que está en un espacio digital
porque puede moverse e interactuar con los objetos del mismo [37].
Esta ilusión se ha ido perfeccionando en los últimos años utilizando diversos métodos de
locomoción e interacción para los HMDs, con entradas de dispositivos muy precisos que
tienen la capacidad de detectar la posición del usuario por completo o el movimiento de
partes especı́ficas del cuerpo como los dedos, el movimiento de los pies y las manos, etc.
Figura 2-18: Simulación manejo de una grúa.
C) Términos de Realidad Virtual

El termino más conocido en el área de la VR es la visión estereoscópica que consiste en generar un
tipo visión tridimensional basado en la visión binocular común a través información que se envı́a
mediante dos imágenes diferentes para cada ojo, las que presentan ligeras diferencias de manera que
el cerebro las interprete con una profundidad simulando un espacio en tres dimensiones y generando
el fenómeno conocido como estereopsis que es la habilidad del ser humano de percibir el mundo
real de forma visual[38].
Otro termino de renombre es el campo de visión o FOV (del inglés Field of View) es la propiedad
de las imágenes enviadas a los ojos de abarcar en su totalidad o no la visión periférica del usuario
[39]. Por otro lado, existen términos más técnicos como la resolución de pantalla, el refresco de
pantalla o FPS (del inglés Frames per second), el seguimiento de rotación o posición del usuario y
finalmente la latencia de seguimiento, cada uno dependientes del HMD a utilizar.
D) Interfaz de usuario y Locomoción

La interfaz de usuario debe seguir las normas de las tres ilusiones y debe tener un método de
locomoción, la buena implementación de estos conceptos en el desarrollo de aplicaciones orientados
a la realidad virtual son los aspectos que hacen la diferencia en cuanto aplicabilidad. En cuanto a
la mecánica de locomoción, existen 3 ramas principales que son:
• Desplazamiento
Es el desplazamiento común que se realiza de manera natural, la desventaja es que se necesitan
algoritmos muy potentes para su desarrollo o un espacio muy amplio para evitar choques.
No es recomendable implementarlo en visores con tres grados de libertad (3DoF).
• Teletransportación
Es uno de los métodos con más éxito en el mercado ya que su aplicabilidad también sirve
para reducir mareos por movimiento, sobre estimulación visual y desorientación en el espacio.
Se puede implementar en cualquier tipo de visor.
• Roller Coaster
Es un método común en aplicaciones y videos en 360º por lo general no se implementa en
aplicaciones en las que se necesitan muchas interacciones. De vez en cuando puede generar
sentimiento de encerramiento y claustrofobia.
2.2.2. Fundamentos del HDM slide-on

En la sección de estado del arte se ha evaluado las diferentes configuraciones para realizar una
inmersión en realidad virtual, la opción por la que se optó fue el HDM basado en teléfonos móviles,
siendo la forma más asequible y común para el público objetivo, en este apartado se evaluara el
funcionamiento de este HMD tomando en cuenta sus sensores, caracterı́sticas técnicas y funciona-
miento a profundidad.
A) Sensores inerciales
Los sensores inerciales también conocidos como IMU (del inglés Inertial Measuring Unit) [40], se
usan para el análisis de movimientos ya que tienen la capacidad de traducir fuerzas y medidas
fı́sicas de forma digital. Este es el requisito principal para poder transformar un teléfono móvil en
un HDM [41], esta conversión se hace a través de los sensores que se muestran a continuación:
• Giroscopio
En dispositivos móviles es un sensor desarrollado con tecnologı́a MEMS (del inglés Micro-
electromechanical Systems) que quiere decir que funciona con componentes electrónicos y
mecánicos miniaturizados, este dispositivo permite conocer la variación de un ángulo en el
tiempo, que se traduce como la obtención de la velocidad angular [42].
Por lo general en celulares se encuentran giroscopios que pueden medir velocidades angulares
en tres grados de libertad o más [43], con señales eléctricas que se traduce del movimiento de
una masa micrométrica de resonancia que se encuentra en el sensor y activa cuando recibe
cambios en la rotación, una peculiaridad de las señales que se envı́an de la masa es que deben
ser amplificadas para la lectura de un microcontrolador.
Tabla 2-1: Signo lectura esperada del giroscopio 2 .

Movimiento X Y Z
Sin movimiento 0 0 0
Teléfono móvil en la mesa, girando en sentido horario. 0 - 0
Teléfono móvil en la mesa, girando en sentido antihorario. 0 + 0
Usuario con HDM, moviendo la nariz hacia arriba. + 0 0
Usuario con HDM, moviendo la nariz hacia abajo. - 0 0
Usuario con HDM, girando la cabeza a la derecha. 0 0 +
Usuario con HDM, girando la cabeza a la izquierda. 0 0 -
2 Fuente: Google VR NDK Controller, gyroscope reading [44]
• Acelerómetro
Este dispositivo permite hacer una lectura de la aceleración en los ejes de coordenadas,
siempre sumada a la aceleración existente por la gravedad acorde a la orientación del celular
y se obtiene por el giroscopio, en muchos casos ambos sensores se encuentran en el mismo

chip por eso es un sensor de la categorı́a de MEMS [45].
El sensor consta de una placa metálica fija y otra móvil que se integran de un material
dieléctrico y un condensador, cenado se efectúa un cambio se detecta la variación en el
equilibrio del dispositivo, entonces la placa móvil se transforma hacia la posición de la placa
fija enviando una pequeña carga de voltaje se amplifica para su lectura y procesamiento como
aceleración en los ejes.
Tabla 2-2: Lectura esperada del acelerómetro 3 .

Posición del teléfono móvil [m/s2 ] X Y Z
Con la pantalla al techo. 0 9.8 0
Con la pantalla sobre la mesa. 0 -9.8 0
Apuntando hacia arriba. 0 0 -9.8
Apuntando hacia abajo. 0 0 9.8
90 grados a la izquierda. 9.8 0 0
90 grados a la derecha. -9.8 0 0
3 Fuente: Google VR NDK Controller, accelerometer reading [44].
La velocidad angular en lecturas de los sensores inerciales se puede representar matemáticamente

en lo que se conoce como “Ángulos de Euler” [46], que consiste en tres matrices de rotación:
 
1 0 0
ωx (φ) = 0 cos(φ) −sin(φ) (2-1)
 
0 sin(φ) cos(φ)
Esta matriz representa la rotación en el eje X, se conoce como Roll (φ) o ángulo de balanceo.
 
cos(θ) 0 sin(θ)
ωy (θ) =  0 1 0  (2-2)
 
−sin(θ) 0 cos(θ)
Esta matriz representa la rotación en el eje Y, se conoce como Pitch (θ) o ángulo de cabeceo.
 
cos(ψ) −sin(ψ) 0
ωz (ψ) = sin(ψ) cos(ψ) 0 (2-3)
 
0 0 1
Figura 2-19: Tamaño real de los sensores inerciales en un teléfono móvil.
Esta matriz representa la rotación en el eje Z, se conoce como Yaw (ψ) o ángulo de derrape. Las
derivadas de los ángulos pueden expresarse en la siguiente matriz resultante:
    
φ sin(ψ)/sin(θ) cos(ψ)/sin(θ) 0 p
θ =  cos(ψ) −sin(ψ) 0  q  (2-4)
    
ψ −cos(θ)sin(ψ)/sin(θ) −cos(θ)cos(θ)/sin(θ) 1 r
Finalmente, ωB es el vector de velocidad angular expresado en una terna de cuerpo con rotaciones.
ωB = pe1 + qe2 + re3 (2-5)
Esta ultima formula describe la actitud rotacional del celular en grados o radianes que se pueden
expresar como momentos de inercia.
B) Espacio de inicio y espacio del controlador

A partir del sistema operativo de Android KitKat 4.4 las variables del acelerómetro y giroscopio
están estandarizadas en todos los teléfonos móviles, lo que quiere decir que el espacio de coordenadas
es el mismo. La orientación del controlador y las lecturas de los sensores inerciales se inicializan
e informan en lo que se denomina espacio de inicio. La orientación del teléfono móvil como HMD
se representa como un cuaternión que cambia en lo que se denomina espacio del controlador [44],
en la siguiente tabla se muestran algunos ejemplos de valores que puede adquirir el cuaternión del
teléfono móvil que usa este HMD como cuerpo rı́gido.
Tabla 2-3: Posiciones, rotaciones y cuaternión esperado del teléfono móvil 4 .

Posición Rotación resultante X Y Z W
Postura inicial Identidad 0 0 0 1
Plano sobre la mesa, girando
90 grados sobre el eje Y 0 0.7071 0 0.7071
90 grados a la izquierda.
-90 grados sobre el eje Y 0 -0.7071 0 0.7071
90 grados a la derecha.
180 grados (opuesto a la pose 180 grados soble el eje Y 0 1 0 0
inicial)
Apuntando hacia arriba 90 grados sobre el eje X 0.7071 0 0 0.7071
Apuntando hacia abajo -90 grados sobre el eje X -0.7071 0 0 0.7071
Girando a la izquierda en el
90 grados sobre el eje Z 0 0 0.7071 0.7071
eje Z
Girando a la derecha en el eje
-90 grados sobre el eje Z 0 0 -0.7071 0.7071
Z
4 Fuente: Google VR NDK Controller, Expected quaternion [44].
Para traducir las rotaciones del Telefono móvil a un motor de desarrollo es necesario expresar sus
tranformaciones rotacionales de forma matemática.
• Cuaterniones y rotaciones
Los cuaterniones son números hipercomplejos que permiten representar las rotaciones de un
objeto rı́gido en espacios tridimensionales. Un cuaternión se compone de una parte escalar y
una parte vectorial, su representación tı́pica se puede ver en la ecuacion 2-6 [47]:
q = s + xi + yi + zk (2-6)
Donde:
q es el cuaternión.
s es un valor escalar.
x es el vector unitario del eje X.
y es el vector unitario del eje Y.
z es el vector unitario del eje Z.
La ecuación 2-6 tambien se puede representar como:
q = [s, v] (2-7)
Todos los componentes de un cuaternión pertenecen a los números reales.

Para realizar el calculo de las rotaciones utilizando cuaterniones, se usa la ecuación 2-8 [46]:
R = qpq −1 (2-8)
Donde:
R es la matriz de rotación estándar.
q es un cuaternión (q0 , q1 , q2 , q3 ) que cumple con |q| = 1.
p es el cuaternión con las coordenadas del teléfono móvil (0,X,Y,Z).
Entonces, la matriz de rotación estándar se muestra en la ecuación 2-9 :
 
1 − 2(q2 )2 − 2(q3 )2 2((q1 )(q2 ) + (q0 )(q3 )) 2((q0 )(q2 ) + (q1 )(q3 ))
R = 2((q0 )(q3 ) + (q1 )(q2 )) 1 − 2(q1 )2 − 2(q3 )2 2((q2 )(q3 ) + (q0 )(q1 )) (2-9)
 
2((q1 )(q3 ) + (q0 )(q2 )) 2((q0 )(q1 ) + (q2 )(q3 )) 1 − 2(q1 )2 − 2(q2 )2
De donde se obtienen la ecuación 2-10, 2-11, 2-12 y 2-13, útiles para hallar los componentes de un
cuaternión posición:
r
T r(R) + 1 (2-10)
q0 =
4
r
R11 1 − T r(R) (2-11)
q1 = +
2 4
r
R22 1 − T r(R) (2-12)
q2 = +
2 4
r
R33 1 − T r(R) (2-13)
q3 = +
2 4
Donde:
Rii son los componentes de la diagonal principal en la matriz de rotación estándar.
qi son los componentes escalares y vectoriales de un cuaternión.
T r(R) es la sumatoria de la traza de matriz que corresponde a un eje de rotaciones.
A partir de las matrices de rotación descritas como “Ángulos de Euler” en las ecuaciones 2-1, 2-2 y
2-3 es posible deducir el cuaternión de la posición que adquiere el teléfono móvil con cada transfor-
mación. Los componentes del cuaternión de rotación se obtienen de las ecuaciones 2-10, 2-11, 2-12
y 2-13 [46].
De la traza de las matrices Rx (φ), Ry (θ) y Rz (ψ) se obtiene el valor de Tr(R), donde α representa
los tres ejes de las matrices rotación:
T r(R) = 1 + 2cos(α) (2-14)
Finalmente se obtienen las fórmulas 2-15, 2-16 y 2-17 para modificar las rotaciones de un teléfono
móvil en un motor de desarrollo como Unity.
φ φ
qφ = cos( ) + i sin( ) (2-15)
2 2
θ θ
qθ = cos( ) + j sin( ) (2-16)
2 2
ψ ψ
qψ = cos( ) + k sin( ) (2-17)
2 2
C) SDK Google VR
Una vez se ha definido como es que un teléfono móvil puede tomar los ángulos y rotaciones de
la cabeza del usuario, en este apartado se presenta una de las herramientas mas utilizadas para
el desarrollo de programas orientados a la realidad virtual, que a la fecha es un software de códi-
go abierto [48]. Se trata del kit de desarrollo de software Google Cardboard, que permite a los
desarrolladores generar aplicaciones para transformar dispositivos Android e iOS en pantallas de
realidad virtual y es la herramienta por excelencia tanto para realizar un correcto seguimiento a las
rotaciones de la cabeza del usuario como para implementar visión estereoscópica en un proyecto.
2.2.3. Grafos y resolución de algoritmos de grafos

Para resolución de problemas mediante algoritmos hay una serie de pasos a seguir, lo primero serı́a
plantearnos el problema en un lenguaje natural, después hay que especificar el problema mediante
un lenguaje preciso como las matemáticas, ya que es la mejor forma de evitar caer en pleonas-
mos e ideas incompletas de forma que podemos clasificar la información que realmente importa,
luego hay que diseñar y analizar una solución algorı́tmica al problema planteado y finalmente po-
demos refinar el algoritmo de manera que podamos expresarlo en un lenguaje de programación [49].
Figura 2-20: Eje de coordenadas respecto a un teléfono móvil.
Entonces los grafos son solo abstracciones matemáticas que pueden trascender problemas matemáti-
cos como sociales y son útiles en la práctica porque nos ayudan a resolver numerosos problemas y
algoritmos importantes [50]. Un grafo G es una terna (V, E, θ), donde V es un conjunto finito de
elementos llamados vértices o nodos del grafo, E es un conjunto finito de elementos llamados lados
y θ es una función que asigna a cada elemento de E un par de elementos de V ası́ es, de acuerdo
con Mesa y Ortega [49].
Se dice que un grafo G = (V, E) se representa matemáticamente como la ecuación 2-18 :
X
|E| = ( x∈V d(x))/2 (2-18)
A) Representación gráfica de un grafo

En muchos casos si no es siempre, los grafos se asocian a figuras o representaciones graficas de forma
que se pueda analizar las propiedades del problema a resolver, por lo general los nodos o vértices
se representan con cı́rculos y los arcos o aristas se representan mediante flechas direccionales que
unen a los nodos [49].
B) Representación matricial de un grafo
Las matrices de adyacencia se caracterizan por tener una longitud de n x n, eso quiere decir que el
número de aristas en filas también define el número de aristas en columnas de ahı́ su peculiaridad
simétrica en grafos orientados, otra de sus caracterı́sticas es que su diagonal principal es nula por lo
que una matriz de adyacencia de un grafo G [51], denotada por A(G), es una matriz que se define
Figura 2-21: Representación grafica de un grafo .
como:
(
1 si (i, j) ∈ A
aij = (2-19)
0 si (i, j) ∈
/A
Para representar a un grafo en una matriz de adyacencia primero se debe organizar los nodos o
vértices de forma simétrica en los extremos izquierdo como en el superior, posteriormente se debe
llenar la matriz con las aristas donde las conexiones entre nodos se representan con algún sı́mbolo,
lo más convencional es que una conexión se represente con “1” y los demás espacios se llenan de “0”.
Por ejemplo, el grafo de la figura 2-21 puede representarse como una matriz de adyacencia de la
siguiente forma:
 
0 1 1 0 0 0 0 0
0 0 0 1 0 0 0 0
 
1 0 0 0 0 0 0 0
 
 
1 0 0 0 1 1 0 0
A(G) = 
0 0
 (2-20)
 0 0 0 1 0 0

0 0 0 0 0 0 0 0
 
 
0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 0
Una forma de determinar si un grafo es orientado o no, puede hacerse a través de su matriz de
adyacencia, sumando las aristas que integra cada uno de los vértices tanto en filas g + (i) como en
columnas g − (i) [52], si las sumas resultantes para las filas son simétricas a las sumas resultantes de
las columnas se concluye que se está tratando con un grafo orientado de otra forma el grafo no es
orientado.

g + (i) = 2 1 1 3 1 0 1 0 (2-21)

g − (i) = 2 1 1 1 1 2 0 1 (2-22)
De la ecuación 2-21 y 2-22 se deduce que el grafo perteneciente a la matriz 2-20 no es orientado.
C) Representación en el computador
Las estructuras de datos presentadas en las anteriores subsecciones son esenciales para la resolución
de algoritmos con operaciones en una computadora [49]. Existen diversos métodos para resolver un
problema según sus peculiaridades, los factores que se toman en cuenta son el número de vértices
o aristas, si es un grafo muy denso, si es un grafo dirigido o no, etc. Por lo general las primeras
resoluciones de algoritmos se implementan con arreglos o listas, sus ventajas y desventajas son:
• Representación en arreglos
Consiste en declarar el grafo como su matriz de adyacencia o en generar un “arreglo de
aristas” si se esta tratando con un grafo dirigido, de forma que solo se tengan dos filas con
los extremos de cada arista.
Tabla 2-4: Representación del grafo de la figura

2-21 5 en arreglos.
V 1 2 3 4 5 0 7 8
1 0 1 1 0 0 0 0 0
2 0 0 0 1 0 0 0 0
3 1 0 0 0 0 0 0 0
4 1 0 0 0 1 1 0 0
5 0 0 0 0 0 1 0 0
6 0 0 0 0 0 0 0 0
7 0 0 0 0 0 0 0 1
8 0 0 0 0 0 0 0 0
5 Vertices y aristas del grafo representado graficamente.
• Representación por listas

Consiste en crear estructuras dinámicas de datos para optimizar la memoria en el programa,
permite quitar y agregar vértices o aristas al grafo de forma flexible en cuanto a organización y
estética. Las desventajas son que el programa cuenta con una cantidad reducida de memorias
al tener la misma cantidad de aristas para almacenar y manejar datos, lo que hace difı́cil
manejar la información sobre los nodos. Esta estructura se usa más para resolución de grafos
no dirigidos [49].
2.2.4. Metodo de desarrollo

Existen diversos métodos para el desarrollo y diseño de software, son útiles para agilizar la resolución
de algoritmos e incluso mejorar la calidad de un proyecto siendo un plan con un inicio y un fin. Lo
fundamental para escoger un método de desarrollo es reconocer los principios generales del software
Figura 2-22: Representación de un grafo por listas.
a desarrollar, con los requerimientos será posible reconocer los problemas y a qué escala se van a
diseñar las estructuras del sistema para un desarrollo ágil [53].
A) Elementos de desarrollo
La metodologı́a de desarrollo a elegir dependerá de los elementos principales [54], que son parte del
proyecto los cuales son:
• El cliente
Se identifica más como el problema ya que en base a sus observaciones y limitaciones el
proyecto podrá tener un final y estructuras especificas definidas.
• El usuario
Es el publico que utilizara el software como solución, de acuerdo a sus requerimientos se
implementa la interfaz de usuario.
• El tiempo
El proyecto debe tener un inicio y un final, en caso de cumplir con los requerimientos del
cliente se da por acabado el proyecto, entonces se pueden desarrollar nuevas versiones.
• Escalabilidad
El tiempo determina la escalabilidad del proyecto, y se refiere a la propiedad de aumentar
las capacidades de un programa sin arriesgar el funcionamiento del mismo.
• Jefe de proyecto.
Es el encargado de dirigir al equipo creando roles y responsabilidades, también define las
fases que van a componer el proyecto como los métodos de resolución de algoritmos.
B) Modelo de la cascada
Este método de desarrollo se utiliza cuando los requerimientos del problema son claros y razonables
de manera que el proyecto puede fluir de forma lineal. En muchos casos el modelo en cascada se
encuentra en proyectos donde se deben implementar actualizaciones o adaptar herramientas a un

software. Sin embargo, también se utiliza en proyectos sin referencias y con los requerimientos bien
comprendidos [55]. Este modelo también es conocido como “ciclo de vida clásico” porque recomien-
da un sistema secuencial de resolución que consisten en:
Figura 2-23: Diagrama de método de desarrollo cascada.
Primero se analizan los requerimientos del proyecto para posteriormente identificar los requerimien-
tos funcionales que son aquellos algoritmos programables y los no funcionales que caracterizan al
software con apariencia, sensaciones y operabilidad. Las desventajas de usar este método son:
• Puede causar confusión en el equipo al ser un modelo secuencial, ya que los errores en el
programa no se descubren hasta el final.
• Si no se tiene un requerimiento fundamental en un inicio el proyecto puede fracasar.
• Si un miembro del equipo se retrasa todo el equipo lo hace por su forma secuencial.
• El cliente debe tener paciencia ya que no existirá una versión funcional del proyecto hasta
que esté muy avanzado.
Las ventajas son:
• Es el mejor método de trabajo cuando se realiza el proyecto en solitario, siendo un modelo

que se considera como el paradigma más antiguo en la ingenierı́a de software.
• Después de desarrollar los requerimientos iniciales y desplegar la primera versión del progra-
ma, es más sencillo asistir el proyecto con retroalimentaciones.
• La calidad del producto que se obtiene es alta.
2.2.5. Scripting, métodos y fundamentos: Unity

Unity es un motor de desarrollo que funciona en base a scripts ya que todos los programas por
mas simples que sean requieren de entradas y ejecución de eventos, los scripts se utilizan para
generar lógica entre objetos o entidades, en una escena se encuentran en modelos, efectos gráficos,
comportamientos fı́sicos e incluso inteligencias artificiales.
A)Programación orientada a objetos

Es un paradigma de la programación, se caracteriza principalmente por manejar a objetos como
entidades que se integran de datos y funciones, similar al concepto de los scripts que permiten
modelar cualquier cuestión del mundo real. Entonces POO se encarga de generar relaciones entre
objetos y clases que a su vez integran variables y métodos a través de invocaciones en el sistema
que pueden o no replicarse en uno o mas objetos a la vez, otros conceptos principales que abarca
la POO son la Herencia y el Dispatch dinámico [56].
La herencia en su momento fue el enfoque mas vanguardista de POO ya que es útil para retrans-
mitir diferentes efectos en diferentes objetos dentro de un mismo sistema [57], tal es el caso que
describiendo similitudes en un Script podemos retransmitir comportamientos a diferentes objetos
que lo contienen. Por otro lado, el Dispatch dinámico se encarga de administrar las interfaces im-
plementadas en nuestro sistema de manera que se puedan invocar comportamientos por parte de
los objetos.
B) Fı́sicas
Unity tiene la capacidad de simular fı́sicas del mundo real en un entorno virtual, las principales
son las aceleraciones y las colisiones [58]. Las fı́sicas son útiles generando comportamientos pasivos
en los objetos de una escena y el motor de desarrollo Unity cuenta con dos motores de fı́sicas
incorporados, para desarrollo de una aplicación en realidad virtual lo más recomendable es usar el
motor Nvidia PhysX.
El motor de fı́sicas para objetos 3D de Unity se integra de:
• Cuerpos rı́gidos
Los cuerpos rı́gidos también conocido en inglés como “RigidBodies”, permiten a los objetos
de una escena en realidad virtual recibir fuerzas o torciones de forma independiente y es un
componente que se puede cambiar a través de scripts, la desventaja de usar un cuerpo rı́gido
es el impedimento de poder hacer cambios en las transformaciones de un objeto de manera
directa afectando también jerárquicamente a los objetos hijos de otro que tenga un cuerpo
rı́gido.
Es un componente que hace a un objeto actuar según los cálculos del motor de fı́sica y puede
afectar a los objetos en sus propiedades de transformación de posición y rotación sin requerir
de sus valores. Existen casos en los que los desarrolladores requieren de un cuerpo rı́gido sin
que las transformaciones del mismo se vean afectadas por los cálculos del programa, esto se
puede hacer a través de la función “IsKinematic” que permite el control de un cuerpo rı́gido
a través de scripts.
• Colisionadores
Este componente se usa para efectos de detección fı́sica entre objetos, se caracterizan por ser
invisibles por lo que no necesariamente deben tener la forma en cuanto a malla del objeto que
lo contiene. Para optimizar el manejo de objetos en el procesador frecuentemente se recurre
a colisionadores conocidos como “primitivos” que se generan en base a modelos básicos como
cubos, esferas, cilindros o capsulas.
En realidad virtual los colisionadores son fundamentales porque permiten interactuar con
los objetos del entorno y generar cambios en la transformación de los mismos en cuanto a
posición y rotación, manteniendo una carga muy leve en los procesadores. Si en una escena
existen dos o más objetos con este componente pueden interactuar entre ellos como objetos
del mundo real, esta acción mejora la experiencia del usuario. Un objeto puede contar con
más de un colisionador y puede ser modificado a través de scripts.
• Articulaciones
Las articulaciones son componentes que sirven para relacionar a dos o más objetos en cuanto a
las fuerzas que se le aplican, el cálculo en la posición de cada componente como las rotaciones
se ejecutan junto al programa en tres grados de libertad, aunque el control que integra el
motor de fı́sicas en Unity suele ser inestable y es la razón por la que grandes compañı́as
desarrollan esta propiedad en base a scripts. Cada uno de los objetos que componen una
articulación pueden trabajar con cuaterniones para sus rotaciones, por lo que las formulas
tal y tal son aplicables de igual forma para este apartado.
C) Control de entidades en realidad virtual

En base a Scripting y los componentes nombrados en las anteriores subsecciones, se puede manifestar
que Unity es una plataforma en la que se pueden crear diversos métodos para el desarrollo de
mecánicas o acciones que debe realizar el usuario o alguna entidad del entorno [58], cuando se
trabaja con realidad virtual las técnicas para generar interacciones son variantes y se definen con
los requerimientos del proyecto, los fundamentos de las fı́sicas y técnicas utilizadas en el presente
proyecto son:
• Técnica Ray casting

Se trata de generar un rayo saliente de un punto en un objeto [59], que matemáticamente
se trata de una lı́nea formada por varios puntos con una sola dirección en un sistema de
coordenadas que contiene una entidad, la distancia que recorre este rayo es variante y se usa
para poder detectar colisionadores en una dirección o para indagar sobre el objeto que está
enfrente. En VR es una operación que usualmente se encuentra implementada en el punto
medio de la cámara, para que el usuario pueda interactuar con el entorno virtual encontrando
objetos con colisionadores.
• Interpolación lineal
Es un procedimiento numérico basado en la interpolación polinómica de Newton que comúnmen-
te se usa en programación para representación digital de funciones en base a dos puntos en
un mismo plano, con los valores de inicio y final [60]. En realidad virtual es útil para trazar la
distancia más corta aproximada entre objetos y utilizar el camino para manipular los objetos
utilizando un polinomio de interpolación de grado 1 que se define como:
f (x2 ) − f (x1 )
f (x|x1 ; x2 ) = f (x1 ) + (x − x1 ) (2-23)
x2 − x1
Donde:
f (x) es la distancia mas corta entre dos puntos.
x1 representan las coordenadas de un punto x1 en el espacio
x2 representan las coordenadas de un punto x2 en el espacio
• Integral de Verlet
Las integraciones numéricas en Unity se usan para calcular la posición de un objeto o para el
cálculo de trayectorias en función al tiempo cuando se están ejerciendo fuerzas en dicho objeto,
si esta función se ejecuta constantemente (un cuadro por segundo es lo habitual) también
se puede predecir sus futuras posiciones. La principal virtud de la integración de Verlet se
demuestra en el cálculo de trayectorias donde la velocidad no se maneja explı́citamente como
en otros métodos de integración, Euler por ejemplo, ademas esta integral permite realizar un
seguimiento de las posiciones actuales y anteriores de un punto respecto a un fotograma de
manera que sus aplicaciones son diversas.
La función principal de esta integración en Unity es hallar trayectorias solución, trabajando
sin velocidades y es la razón por la que en una simulación esta integración es más estable
en comparación con otras integrales más explicitas, el único inconveniente de Verlet es que
si se requiere manejar las colisiones en una trayectoria el problema puede llegar a ser más
complejo por lo que se recomienda tomar en cuenta la velocidad u optar por otro método
para hallar trayectorias.
Esta integración se obtiene truncando la serie de Taylor de las ecuaciones 2-24 y 2-25, a partir
de los terminos de cuarto orden para una pocisión variable en los instantes t + dt y t − dt
[61]:
~a(t)dt2 ~b(t)dt3 (2-24)

~r(t + dt) = ~r(t) + ~v (t)dt + + + ...
2 6
~a(t)dt2 ~b(t)dt3 (2-25)

~r(t − dt) = ~r(t) − ~v (t)dt + − + ...
2 6
Donde:
~r es la pocisión de una entidad respecto a un instante t.
~v representa la velocidad.
~a representa la aceleración.
~b representa la sobreaceleración.
De la sumatoria de la ecuación 2-24 y 2-25 se obtiene la ecuación 2-26, un integrador de

cuarto grado que es la base de la aplicación de la integral de verlet:
~r(t + dt) = 2~x(t) − ~r(t − dt) + ~a(t)dt2 (2-26)
Como se puede observar en la ecuación 2-26, la integración de verlet es un integrador que

puede facilitar una trayectoria sin tomar en cuenta la velocidad y tiene un error despreciable
al ser de cuarto orden.
2.2.6. Modelado para realidad virtual

Cuando se desarrolla una aplicación de realidad virtual para teléfonos móviles algo que se debe
tomar en cuenta es que la unidad de procesamiento en celulares es muy diferente a la de un
computador ya sea por el tipo de gráficos que pueden leer según su sistema operativo o simplemente
a la velocidad en que procesan la información, este puede ser uno de los errores más comunes de
los desarrolladores cuando se realiza un proyecto en un motor de desarrollo como Unity.
A) Técnicas de modelado
Las técnicas de modelado y prototipado más reconocidas para la virtualización de objetos reales
son:
• Modelado poligonal
Tratándose de realidad virtual para teléfonos móviles, esta es la técnica utilizada por excelen-
cia ya que permite crear modelos con una cantidad muy reducida de polı́gonos. La creación
de modelos con esta técnica permite virtualizar objetos en base a formas prediseñadas como
cubos, esferas y planos, modificando su topologı́a. Errores comunes que existen al usar esta
técnica de modelado son orientar mal las caras normales del objeto virtualizado y realizar un
tratamiento incorrecto de la topologı́a del modelo.
• Modelado NURBS
Es un tipo de modelado que generalmente se utiliza cuando se requieren modelos de precisión,
no es recomendable usar este tipo de modelos en aplicaciones de realidad virtual para teléfonos
móviles ya que podrı́a afectar en gran medida el tiempo de refresco en el renderizado y la
latencia de los fotogramas dentro de la aplicación. Los softwares que se caracterizan por
utilizar este tipo de modelado se basan en geometrı́a de contornos en la categorı́a de diseño
asistido por computadora (CAD), lo habitual antes utilizar los modelos que se generan con
esta técnica en un entorno como Unity es realizar una reducción en la cantidad de polı́gonos.
B) Técnicas de reducción de polı́gonos

Tomando en cuenta que los instrumentos del laboratorio de la materia en cuestión son piezas
mecanizadas, se optó por realizar una investigación sobre técnicas de reducción de polı́gonos más
importantes y se obtuvo la siguiente lista:
Figura 2-24: Modelado en NURBS, geometrı́a automatizada.
• Reducción por Cuadrangulación

Es el proceso de convertir dos polı́gonos consecutivos triangulares en uno solo cuadrado,
reduce a la mitad los polı́gonos sin deformar el modelo. La desventaja es que solo se puede
aplicar una vez.
Figura 2-25: Modelado poligonal, la topologı́a del modelo se ve reducida a medida que bajan
sus polı́gonos.
• Reducción por Conteo

Es el proceso automático de unir polı́gonos adyacentes, es útil cuando se requiere un modelo
que contenga una cantidad finita de polı́gonos o cuando se tiene un modelo con muchas caras
y muchos planos, no se recomienda aplicar este tipo de reducción muchas veces en un modelo
ya que podrı́a deformar su malla.
• Retopologı́a
La retopologı́a no es una reducción de polı́gonos, mas bien se enfoca en redibujar el modelo
en una malla. Es la manera mas efectiva de reducir los polı́gonos en un modelo, la desventaja
que trae es que consume mucho tiempo y para realizar una correcta retolopologı́a se requieren
de conocimientos amplios en el área de modelado poligonal.
Algo que se debe tener muy en cuenta, es que los dos primeros métodos de reducción se pueden
utilizar juntos para obtener resultados parecidos a una retodologı́a.
CAPÍTULO 3
Marco Práctico
3.1. Esquema general del proyecto

La figura 3-1 presenta el esquema del proyecto, LABORATORIO DE REALIDAD VIRTUAL EDU-
CATIVO PARA NEUMÁTICA E HIDRÁULICA (IMT-241). En el esquema se pueden apreciar el
funcionamiento del prototipo funcional basado en conceptos y metodologı́as descritas en el capitulo
anterior.
Figura 3-1: Esquema general del proyecto.

3.2 Planeación y requerimientos 42
3.2. Planeación y requerimientos

3.2.1. Detección de elementos para el desarrollo
En esta etapa el software aun es ideal, la prioridad fue analizar restricciones y requerimientos
principales del software detectando los elementos del proyecto.
Tabla 3-1: Elementos principales del proyecto.

Tomando en cuenta que el docente experto en la materia con
cargo de Tutor y el docente Relator son los encargados de
la revisión continua del presente proyecto, se los identifico
El cliente
como el cliente del proyecto. Se estimó que la primera fase
de retroalimentación se llevarı́a a cabo con sus observaciones
en el Workshop de taller de grado 2-2020.
Los estudiantes de ingenierı́a mecatrónica en la UCB se iden-
tifican como los usuarios destinatarios, de manera que se es-
El usuario timó que las pruebas se realizarian despues de fase de retro-
alimentación para la culminación y presentación del proyecto
final.
Para estimar el tiempo de desarrollo útil se tomo en cuenta
que el proyecto paso por una fase de investigación, planea-
El tiempo ción y capacitación en diversas áreas que integran el proyecto
por lo que el tiempo aproximado de desarrollo util fue de tres
meses hasta su finalización.
Como se pudo observar en el estado del arte del presente
proyecto la escalabilidad de los proyectos orientados a VR
por lo general no son escalables y siguen un patrón de pasos
a seguir con autómatas finitos, por otro lado, el desarrollo
Escalabilidad
de un simulador toma mucho tiempo y tomando en cuenta
que tiempo útil de desarrollo estimado es de tres meses se
determino que era razonable desarrollar un software con una
escala a nivel circuito.
En base a la tabla 3-1 se detectaron algunas restricciones y requerimientos del software que se
utilizaron para el posterior diseño de distintas mecánicas e interacciones, interfaces, modelos y
como punto más importante se estableció la escalabilidad del presente proyecto.
3.2.2. Analisis de Requerimientos

En este apartado se han definido las capacidades y posibles condiciones del proyecto, para lo cual
se visitó las instalaciones de la universidad católica boliviana donde se analizaron principalmente
los componentes la materia de NEUMÁTICA E HIDRÁULICA (IMT-241) y en especı́fico los com-

ponentes neumáticos de la serie MICRO, que son instrumentos conocidos con los que se pueden
analizar mas a fondo los requerimientos especı́ficos y fundamentales que debe tener el software. En
relación al proyecto también se deben considerar las tres ilusiones que hacen posible el correcto
desarrollo de un programa para entrenamiento en realidad virtual, esta cuestión cambio de sobre-
manera los requerimientos y las propuestas en el desarrollo del software.
Figura 3-2: Analisis de componentes de la serie MICRO con el docente experto en la materia.
Con respecto a los requerimientos del área de modelado se tomaron en cuenta los instrumentos de
la serie MICRO previamente analizados como se muestra en la figura 3-2, puesto que naturalmente
las primeras prácticas de laboratorio en la materia se desarrollan con estos equipos. En ese sentido
se optó por modelar las piezas con una herramienta de modelado basado en NURBS ya que al
tratarse de piezas mecanizadas se requiere de mayor precisión, en esta etapa también se empezó
con la búsqueda de planos y catálogos pertenecientes a los instrumentos que se tienen en laboratorio.
Cabe considerar que existen otros requerimientos para el área de modelado ya que al tratarse de
un proyecto orientado a realidad virtual se estableció el diseño de un entorno virtual con el objeto
de conseguir por parte de los usuarios el fenómeno conocido como “Place illusion”, el plan para el
desarrollo del entorno virtual fue tomar las medidas del laboratorio real y de los objetos o muebles
mas llamativos de la habitación donde se desarrollan las prácticas de laboratorio.
En cuanto a requerimientos de programación y desarrollo de algoritmos se tomaron en cuenta

caracterı́sticas de la serie MICRO, que aunque se integra solamente de componentes neumáticos
es material suficiente para identificar las acciones fundamentales que debe tener el software para
concretar las prácticas de laboratorio, ya que para el armado de cualquier circuito de la materia
se debe seguir la misma secuencia de pasos que son ordenar, conectar, verificar y accionar. Un
indicador que demuestra que el desarrollo estaba bien encaminado fue que en todos los softwares
de simulación de neumática e hidráulica también se siguen los mismos pasos.
3.2.3. Casos de uso
Figura 3-3: Diagrama de casos de uso.
Los casos de uso por lo general representan la forma en la que funciona un sistema que se va a
desarrollar, en él se incluyen la forma en la que los actores interactúan con el entorno. El programa
cuenta con un único actor que representa el usuario como se puede ver en la figura tal, al tratarse
del diseño de una aplicación de realidad virtual se desarrolló el diagrama basado en las acciones
naturales que se llevan a cabo al realizar el armado de un circuito en un laboratorio real.
3.2.4. Requerimientos funcionales y no funcionales

A) Requerimientos funcionales
Los requerimientos generales que se detectaron del anterior analisis y del diagama de casos de uso,
se refieren a comandos que afectan por completo a la escena y se desglosan en la tabla 3-2.
Tabla 3-2: Requisitos funcionales generales.

Identificador Titulo Descripción
RF01 Boton de salida Un boton en el entorno virtual para salir de la aplicación.
RF02 Botón de reinicio Un botón para reiniciar la escena preparada.
Los requerimientos funcionales por parte de la interfaz del usuario se desglosan en la tabla 3-3.
Tabla 3-3: Requisitos básicos de la UI.

Permite al teléfono móvil generar dos
imágenes diferentes para cada ojo, par-
RF03 Visión estereoscópica
tiendo a la mitad la pantalla del
teléfono móvil.
El software debe obtener los datos de
los IMU del teléfono móvil para realizar
RF04 Giro de la cámara
un seguimiento en las rotaciones de la
cabeza del usuario.
El rayo permite al usuario detectar
cualquier objeto que tenga el compo-
RF05 Rayo detector nente Collider de manera que sea capaz
de detectar los instrumentos, mangue-
ras, cables, elementos de la UI, etc.
A través de la retı́cula el usuario es ca-
paz de detectar visualmente si esta in-
RF06 Retı́cula principal
teractuando con un objeto con colisio-
nador.
La retı́cula de selección permite al
usuario evitar confusiones en la selec-
RF07 Retı́cula de selección ción directa con los objetos, permite al
usuario realizar una confirmación de se-
lección pasado un tiempo.
Es el método de locomoción del usuario
RF08 Locomoción
a través del entorno virtual.
Para establecer los requerimientos funcionales de las acciones principales del usuario se separaron
las funcionalidades en cuatro etapas que se realizan comúnmente en simuladores de neumática e
hidráulica y en la preparación del laboratorio real. La primera etapa se trata de la manipulación
de instrumentos de laboratorio, en la segunda etapa el usuario se encarga de hacer conexiones,
la tercera etapa es una revisión de la conexión del usuario para la etapa final que se trata de
experimentar y utilizar el circuito prestando atención a los actuadores.
Todas la etapas nombradas se desglosan en la tabla 3-4.
Tabla 3-4: Requisitos de las cuatro etapas de desarrollo

El usuario es capaz de agarrar los objetos que detecta, se
RF09 Tomar Objeto
puede de tratar de instrumentos, mangueras, cables, etc.
Si el usuario ha tomado un objeto puede dejarlo en una
RF10 Dejar Objeto
superficie determinada.
Permite al usuario ordenar el componente que ha tomado en
RF11 Ordenar Objeto
una superficie como el desee.
El usuario debe portar el objeto que tiene en sus manos, aun
RF12 Cargar Objeto
si se mueve por el entorno.
Permite al usuario manipular las mangueras para conexión
RF13 Tomar extremo
de circuitos.
Si el usuario ha tomado un extremo de una manguera puede
RF14 Conectar extremo realizar una conexión en un instrumento previamente aco-
modado.
El software debe poder detectar si la conexión del usuario
RF15 Verificar conexión
es correcta.
Permite al usuario interactuar con objetos accionables como
RF16 Accionar Objeto
botones, palancas, etc.
A causa del accionamiento de algún componente los cilindros
RF17 Actuadores
actuadores pueden actuar o no.
B) Requerimientos no funcionales
Los requerimientos no funcionales generales se desglosan en la tabla 3-5.
Tabla 3-5: Requisitos no funcionales generales.

El teléfono movil de pruebas y de los usuarios deber tener
RNF01 Versión de Android
instalada al menos la versión de Android KitKat 4.4.
La aplicación puede manejarse en cualquier momento sin
RNF02 Disponibilidad
necesidad de internet siempre y cuando se tenga un HMD.
El software funciona continuamente y responde a las accio-
RNF03 Tiempo real
nes del usuario en todo momento desde su acceso.
Por otro lado, los demás requerimientos no funcionales se enfocan en cumplir con las tres ilusiones
que debe contener un programa orientado al entrenamiento en realidad virtual.
3.3 Modelado 47
Tabla 3-6: Requisitos para generar las tres ilusiones.

el modelado del laboratorio virtual debe tener caracterı́sticas
RNF04 Ilusión de lugar
similares al del laboratorio real.
se deben modelar los instrumentos del laboratorio en base
Ilusión de plausibi-
RNF05 a componentes que existen en la UCB, también se planeó
lidad
agregar una animación a algún componente del laboratorio.
Todas las posibles interacciones del usuario con el entorno
Ilusión de encarna-
RNF06 virtual se deben basar en las acciones de una práctica de
miento
laboratorio convencional.
3.3. Modelado
En el capitulo anterior se describe porque la realidad virtual debe cuidar la cantidad de polı́gonos
de sus modelos más que otro tipo de software, de manera que el objetivo principal de esta etapa fue
reducir al mı́nimo la cantidad de polı́gonos en los modelos tanto de instrumentos como de objetos
que forman parte del entorno. La reducción de polı́gonos será útil para optimizar el rendimiento
y evitar problemas en cuanto a procesamiento mejorando el tiempo de refresco de las imágenes
renderizadas para dispositivos de baja gama.
Figura 3-4: Modelos que se utilizaron en el circuito de evaluación.
Un punto muy importante para el desarrollo de esta etapa fue que la plataforma Unity solo puede
procesar y renderizar modelos en formato FBX, por lo que para decidir las herramientas de mode-
3.3 Modelado 48
lado se tuvo cautela y como se puede ver en la figura 3-4, se utilizo modelado en NURBS al igual
que el modelado poligonal.
3.3.1. Modelos en NURBS

Como se mencionó en el apartado requerimientos funcionales y no funcionales los instrumentos de
laboratorio en especifico eran piezas que requerı́an modelado de precisión, por lo que se utilizo como
herramienta el software SolidWorks. El diseño de los instrumentos esta basando en catálogos de las
piezas, que se pueden encontrar con un código identificador grabado en pegatinas junto a todas las
piezas de la serie MICRO.
Figura 3-5: Código identificador de un regulador de caudal.
En el proceso de modelado no se han incluido tornillos y en algunos casos se han quitado re-
dondeos y chaflanes en las piezas, el motivo de esta decisión fue evitar un crecimiento elevado en
la cantidad de polı́gonos de cada modelo al exportar la pieza a un software de tratamiento poligonal.
El software integra ensambles de instrumentos neumáticos que forman parte del primer laboratorio
de la materia, entre los cuales existen algunos ensambles como los conectores rápidos y los soportes
que son piezas comunes en el ensamble de instrumentos principales.
Tabla 3-7: Ensambles comunes.
Ensamble Nro. de piezas
Conector rápido 4 piezas
Conector orientable 90º 6 piezas
Soporte 6 piezas
3.3 Modelado 49
Los ensambles principales se encuentran en el proyecto de Unity como componentes prefabricados,

que cuentan con 200 piezas de las cuales 66 son piezas completamente únicas y el resto son ensambles
de la tabla 3-7. El desglose de los ocho ensambles principales se puede observar en la tabla 3-8 al
igual que la descripción de cada componente.
Tabla 3-8: Ensamble de instrumentos principales.

Identificador Descripcion del instrumento Nro. de piezas
Válvula reguladora de presión
VRPM 13 piezas y 1 conector rápido.
con manómetro
1 pieza, 5 conectores rápidos, 4
BD Bloque distribuidor conectores orientables 90º y 1 so-
porte.
Válvula 5/2, accionamiento 1 pieza, 5 conectores orientables
V5/2
neumático en ambos sentidos 90º y 1 soporte.
Válvula 3/2 accionamiento por
V3/2P 3 piezas y 1 soporte.
palanca retorno por muelle
Válvula 3/2 accionamiento por 5 piezas, 2 conectores orientables
V3/2R
rodillo, retorno por muelle. 90º y 1 soporte.
5 piezas, 2 conectores orientables
RC Regulador de caudal
90º y 1 soporte
CD Cilindro simple efecto 13 piezas y 1 soporte.
CS Cilindro doble efecto 15 piezas y 1 soporte
3.3.2. Modelos poligonales

Primero se empezó con el modelado del entorno virtual, para lo cual se visitó el laboratorio de
la UCB y junto a una aplicación CamToPlan se obtuvo un plano aproximado del perı́metro de la
habitación donde se desarrollan las prácticas de laboratorio que se puede observar en la figura 3-6
y tambien una unidad de medida para Unity.
Con el plano se comenzó con modelado de la habitación para lo cual se exporto la figura en una
imagen dentro de la escena de Unity y se agregó como shader en un objeto plano donde se hizo
la estimación de la unidad de medida de la figura y se desarrolló el modelo con la herramienta
ProBuilder, como resultado se obtuvo el modelo de la figura 3-7.
En la visita también se midieron las mesas y los tableros neumáticos que son los objetos principales
donde se desarrollan las prácticas de laboratorio de la materia en cuestión, los modelos para esta
parte se hicieron en Blender cuidando que los modelos tengan una cantidad mı́nima de polı́gonos y
para el resto se utilizaron modelos primitivos de Unity. La cantidad de polı́gonos de cada modelo
se encuentran en la tabla 3-9.
3.3 Modelado 50
Figura 3-6: Contorno del plano del laboratorio de la UCB.
Figura 3-7: Modelo del laboratorio de la UCB.
Finalmente se modeló el botón de reinicio y salida, cumpliendo ası́ la norma de realidad virtual,
los botones están dentro del mundo virtual y no ası́ en un canvas. También se aprovechó para
modelar gafas protectoras para que los usuarios puedan aprender sobre los hábitos de seguridad
que se utilizan al momento de realizar una práctica de laboratorio de neumática.
Tabla 3-9: Modelos poligonales.

Modelo Nro. de partes Nro. de caras
Mesa 3 32
Tablero neumático 4 182
Botón 5 216
Lentes de seguridad 3 70
Por otro lado, se realizó un retoque en la topologı́a de los modelos en NURBS para exportarlos
a Unity, este proceso fue la etapa más larga y compleja de la sección ya que algunos modelos
3.3 Modelado 51
contenı́an muchas caras, esto se debı́a en gran medida a los chaflanes y redondeos que aparecen en
las curvas de los modelos. Finalmente se procedió a hacer la reducción de polı́gonos en dos tiempos,
primero por conteo tratando de no deformar la pieza y después por cuadrangulación, es ası́ que se
obtienen los resultados de la tabla 3-10.
Tabla 3-10: Antes y después de la reducción de polı́gonos.

Nro. de caras Nro. de caras
Identificador
antes después
VRPM 5425 2212
BD 1624 420
V5/2 3340 1526
V3/2P 12351 3452
V3/2R 14328 3423
RC 2234 1532
CD 18450 3225
CS 10032 2823
El ultimo paso antes de exportar los modelos de Blender a Unity fue corregir las normales de los
modelos importados de NURBS, para que dentro de la escena todas las caras de los instrumentos
sean visibles. La exportación y renderización de los modelos en Unity resulto exitosa por lo que se
dio esta etapa como finalizada.
Figura 3-8: Cilindro doble efecto, retocado y nomales bien orientadas.

3.4 Programación 52
3.4. Programación
El objetivo principal de esta etapa fue desarrollar los requerimientos funcionales detallados en las
tablas 3-2, 3-3 y 3-4 tomando en cuenta los requerimientos no funcionales de la tabla 3-5 y 3-6,
para empezar con un desarrollo en paralelo con la etapa anterior se desarrollaron scripts e hicieron
pruebas continuas con modelos primitivos de Unity. El diagrama de clases de la figura 3-9, contiene
los algoritmos nesarios para realizar un entrenamiento orientado a la materia de NEUMÁTICA E
HIDRÁULICA (IMT-241).
Figura 3-9: Diagrama de clases del proyecto.

3.4.1. Control general

La meta de este apartado fue desarrollar una solución para los requerimientos funcionales RF01
y RF02 de la tabla 3-2 siguiendo las normas de realidad virtual que se encuentran entre los re-
querimiento no funcionales de la tabla 3-5, la razon de su desarrollo simultaneo fue que tienen
caracterı́sticas similares y su comportamiento en el entorno visualmente es el mismo hasta después
de ejecutar un comando, en otras palabras se creo un guion para reiniciar la escena y otro para
salir de la escena ambos atachados en objetos diferentes, pero con ensambles de mallas iguales.
Figura 3-10: Botones de reinicio y de salida.
Tras cumplir con el requisito RF05 y RF06 se agregaron colisionadores en los botones y un activador
de eventos que genera un rotulo con el nombre de cada función de acuerdo a la posición del rayo
detector, es decir el texto aparece cuando la retı́cula principal detecta el botón. El diseño se hizo
de esta forma pensando en posteriores retroalimentaciones donde se requiera de un botón con
un comando diferente, finalmente se creó una animación para verificar el funcionamiento de los
comandos en sus respectivos guiones obteniendo el resultado de la figura 3-10.
3.4.2. Bases de la interfaz de usuario

La realidad virtual requiere de un tratamiento especial para desarrollar su interfaz de usuario ya que
en su culminación el usuario debe ser capaz de comprender su funcionamiento de forma intuitiva
y se deben considerar los requisitos no funcionales de la tabla tal, en este apartado se muestra el
desarrollo de la interfaz del usuario según los requerimientos funcionales de la tabla tal en orden.
Un punto importante es que todas las pruebas se realizaron en un teléfono móvil de la marca Xiomi,
de modelo Redmi note 8 pro.
A) Visión estereoscópica - RF03 y Giro de la cámara - RF04

Para el desarrollo de este requerimiento se agregó una cámara en la escena de Unity que representa
al usuario y es el objeto donde se renderizan las imágenes para los ojos del usuario. El desarrollo del
requerimiento RF03 utiliza herramientas del SDK de Android que al exportar la aplicación genera
un renderizado para realidad virtual, los resultados de la prueba se muestran en la figura 3-11, que
se trata de un informe de depuración realizado vı́a USB.
Figura 3-11: Informe de depuración para requerimiento RF03 y RF04.
En el informe muestra la inicialización del estado de realidad virtual, para activar este estado el
programa toma los valores del ancho y alto de la pantalla del dispositivo, luego divide la pantalla en
dos y renderiza imágenes estereoscópicas como dos cámaras principales diferentes, que se ajustan
a los ojos del usuario. El campo de visión y la separación se puede editar por código, el resultado
tras implementar el requerimiento RF03 se muestra en la figura 3-12.
Figura 3-12: Requerimiento RF03 implementado.
En la figura 3-11 se puede observar el funcionamiento del requerimiento RF04, que también utiliza
herramientas del SDK de Android, primero para detectar los sensores del dispositivo y luego para
obtener en tiempo real sus ángulos de rotación ya que en el proyecto estos valores representan la
rotación de la cabeza del usuario. Posteriormente se utilizaron herramientas del SDK de Google-
Cardboard que inicializan las matrices de rotación Pitch, Roll y Yaw en las fórmulas 2-15, 2-16 y
2-17 respectivamente, para obtener un cuaternión que además de hacer seguimiento a la cabeza
del usuario, enlaza los valores de rotación obtenidos con cámara principal en la escena de Unity, el
resultado se puede observar en la figura 3-13.
B) Rayo detector – RF05 y Retı́cula principal – RF06

Para implementar el rayo detector primero se identifica el ancho y alto el alto de la pantalla del
dispositivo donde se ha exportado la aplicación, luego se divide estos valores en dos para obtener el
punto medio de la pantalla, finalmente se crea un rayo de longitud infinita que salga de este punto
y sea completamente perpendicular a la orientación de la pantalla del teléfono móvil. El informe
de depuración de la figura 3-14 muestra que el rayo ya es capaz de detectar objetos en el entorno.
Figura 3-14: Informe de depuración requisito RF05.
La retı́cula principal es una herramienta que utiliza guiones del SDK de GoogleCardboard que va
en conjunto con el requerimiento RF05, se trata de una figura sobrepuesta a la cámara principal del
usuario en forma de punto que cuando detecta un colisionador se amplı́a, demostrando al usuario
que está tratando con un objeto interactuable, la implementación en conjunto del requerimiento
RF05 y RF06 se puede observar en la figura 3-15.
Figura 3-15: Requisito RF05 y RF06 implementado.
C) Retı́cula de selección – RF07

Con la retı́cula principal funcionando ya se podı́a interactuar con cualquier objeto que tenga un
colisionador en el entorno virtual, el problema que surgió en este punto era que el usuario todavı́a
no tenia control de selección por lo que no era capaz de hacer las acciones principales deseables
como levantar, dejar o seleccionar objetos del entorno. Para solucionar este problema se creó una
retı́cula adicional que se superpone a la retı́cula con el rayo, esta se dibujó en Paint 3D y consiste
en un cı́rculo blanco que se superpone en el centro de la cámara principal del usuario en Unity.
Para configurar esta retı́cula en el programa se cambió el tipo de imagen por defecto a un sprite
de lleno, como se muestra en la figura 3-16 y se le asigno a un canvas en la cámara principal.
Figura 3-16: Retı́cula de selección y su configuración.
La programación de su script consiste en tres funciones principales, la primera cumple una función
de animador en la imagen de la retı́cula de selección y la varia adquiriendo el tiempo de ejecución
que se va actualizando en cada fotograma, a su vez también contiene una variable que funciona
como memoria en la que se suma el tiempo ejecución cada vez que se detecta una colisión, llenando
o no la imagen de la retı́cula de selección de forma radial.
Las otras dos funciones sirven para detectar si el rayo de la retı́cula principal esta colisionando
con algún objeto, si es ası́ la primera función guarda en una variable el tiempo de ejecución com-
parándose en cada frame con un valor preestablecido en Unity, esto quiere decir que si el tiempo y
la animacion se completan, la acción se ejecuta; caso contrario la variable se reinicia en 0 al igual
que la animación de llenado en la primera función. La preuba de la retı́cula de selección fue exitosa
y se muestra en la figura 3-17
D) Locomoción – RF08
Con la retı́cula de selección implementada el siguiente problema a solucionar fue hallar un método
de locomoción a través del espacio 3D, para resolver este problema se optó por usar el método de
teletransportación antes visto en el capı́tulo 2. La idea principal fue usar un objeto primitivo de
Unity como referencia de transformación de posiciones, de manera que el usuario detecte el objeto
a través del requisito funcional RF05, para lo cual se creó un tag nombrado “teleports”.
Figura 3-18: Informe de depuración requerimiento RF08 y transformación del usuario.
Las transformaciones de posiciones en Unity se trabajan con variables de tipo Vector3, por lo que
la programación del script consiste en solicitar el Vector3 de la posición perteneciente al objeto

destino. Cuando se detecta un punto de teletransportación se ejecuta la animación del requeri-
miento RF06 y posteriormente se le asignan los valores al Vector3 del usuario junto a la cámara
principal, el único problema para esta parte fue que al transformar la posición del usuario a la del
cubo también adquirı́a su posición en eje Y, modificando el rango de visión del usuario como se
muestra en la figura 3-18.
Para solucionar este problema se creó una variable donde se guarda la coordenada en Y del usuario
al iniciar el programa y luego sumarlo a la posición del objeto destino, permitiendo al usuario
teletransportarse sin cambiar su perspectiva o campo de visión. Finalmente se agregó una animación
de desvanecimiento a la cámara principal para evitar mareos en el usuario y se cambió el aspecto
del punto teletransportación por una malla similar a un cilindro, que conserva el colisionador del
cubo de pruebas, como se puede ver en la figura 3-19, que posteriormente se transformó en un
objeto prefabricado para crear diferentes puntos de destino.
3.4.3. Fı́sicas del laboratorio

Una vez creada la interfaz de usuario se empezó con el desarrollo de las fı́sicas que se iban a
presentar en el entorno analizadas en la primera etapa del proyecto. El objetivo de esta etapa en
la programación fue crear un objeto prefabricado con las fı́sicas de una manguera o cable, con las
que el usuario pueda interactuar.
A) Cinemática inversa y Articulaciones

Para este apartado la idea fue crear un cuerpo articulado en base a capsulas para simular las fı́sicas
de una manguera o cable, se utilizó la herramienta Character Joint de Unity, que sirve para anclar
un objeto a otro, solo restaba crear un script con la capacidad de crear una cantidad de segmentos
finitos con este componente a través de código el resultado se muestra en la figura 3-20.
Figura 3-20: Cuerpo articulado de manguera neumática
La manguera creada se instanciaba por código al igual que su longitud, cada capsula representa un
segmento de la manguera generada y todos los segmentos compartı́an la detección de colisiones, el
problema que surgió de este intento fue que la rotación de los ángulos de cada segmento era muy
inestable ya que la multiplicación de cuaterniones debı́a ser optimizada. Indagando más sobre la
solución se descubrió que al dı́a de hoy, la creación de una articulación con n segmentos, es uno de
los grandes problemas para los desarrolladores de video juegos, por lo que se desechó la idea y se
buscaron opciones alternativas.
B) Integración de Verlet
Para traducir esta integración numérica en un algoritmo programable se utilizó la ecuación 3-1
que simplifica en gran medida la ecuación 2-26, hallando los valores iniciales a través del método
implı́cito de Euler.
r(t + dt) = r(t) + dt v(t) (3-1)
Donde:
r es la posición del objeto en el espacio, en un instante t
dt es el incremento de tiempo por cada fotograma mientras el programa se ejecuta.

v es la velocidad en el momento t.
Para implementar el algoritmo funcional de la figura 3-21, se siguieron los siguientes pasos:
• Se creo visualmente una manguera con ayuda del componente Line Render, que a través de
código genera una cantidad finita de partı́culas que representan los segmentos de la manguera.
• El algoritmo vincula dos objetos que son la relación automática del inicio y final de la
manguera.
• La manguera se debe renderizar en cada fotograma desde la ejecución del programa.
• Se agrego la ecuación 3-1 en un bucle que sirve para calcular la posición actual y la posición
anterior de cada segmento de la manguera en tiempo real.
• De la diferencia de las dos posiciones se obtiene una velocidad, a la que se le puede sumar
fuerzas. En el proyecto esta variable es una gravedad negativa y es el factor que permite al
usuario ver las conexiones del circuito.
• Para mantener todas las partı́culas del Line Renderer unidas se calcula una restricción de
distancia entre segmentos y se agrega un factor de elasticidad, mejorando el aspecto estético
de la manguera.
Figura 3-21: Fisica de mangueras implementada.
3.4.4. Primera etapa de interacciones

En esta etapa se desarrollaron los requisitos funcionales RF09, RF10 y RF11 de la tabla 3-4, ya
que la acción principal que relaciona a estos requisitos es la manipulación de objetos del usuario
por lo que primero se programó el movimiento de un objeto de un punto A a un punto B utilizando

la interpolación lineal, de manera que ese objeto primitivo se pueda mover de formas diferentes
según el requerimiento del usuario.
A) Tomar Objeto - RF09

Para este requerimiento era necesario que el usuario pueda detectar con que objeto estaba tratando
por lo que se creó un tag llamado “tools”, para los modelos de los instrumentos de laboratorio
que se encuentran en la tabla 3-8, a los que también se les agregaron colisionadores de forma
que el usuario pueda reconocer el objeto a través del requisito funcional RF05, posteriormente se
identificaron los puntos de trayectoria por los que se debı́a interpolar el objeto detectado. El punto
inicial es el vector posición del objeto detectado y el punto final es un objeto que simula ser las
manos del usuario, el informe de depuración de este requerimiento se puede observar en la figura
3-22.
B) Dejar Objeto - RF10

En este requerimiento se identificaron como punto inicial las manos del usuario y como punto final
la intersección del rayo de la retı́cula y un punto en el colisionador de una mesa, donde se realizarı́a
el armado del circuito. La trayectoria se obtuvo a través de código y la interpolación se ejecuta
cuando el usuario posa la retı́cula en algún lugar de la mesa, de manera que el usuario tiene la
oportunidad de dejar el instrumento de laboratorio en un área cercana a la deseada.
Posteriormente se creó un tag al que se le llamo destino, que se asignó en la mesa donde se realizarı́a
el armado del circuito y finalmente se agregó el componente de colisionador, el informe de depuración
se puede observar en la figura 3-23.
C) Ordenar Objeto - RF11

Para ordenar los objetos se desarrolló un script que cuenta el número de instrumentos existentes
en la escena, de tal manera que el usuario solo pueda ordenar una cantidad especifica de objetos y
el avance de etapas sea automático, con la única restricción que el ultimo instrumento que se deja
en la mesa no se puede ordenar. La trayectoria que se obtiene en este requerimiento toma como
punto inicial la posición del objeto que se dejo en la mesa y como punto final la colisión del rayo de
la retı́cula con cualquier punto del colisionador de la mesa utilizando funciones de requisito RF10,
el informe de depuración se muestra en la figura 3-24.

3.4.5. Segunda etapa de interacciones

Esta etapa de interacciones engloba todos los requerimientos relacionados con las conexiones que se
realizan en un circuito de laboratorio tomando en cuenta la tabla 3-4 y en especı́fico los requisitos
RF13, RF14 y RF15 de manera que él programa sea aplicable a otros circuitos del laboratorio. Para
lo cual se evaluaron los algoritmos desarrollados en un circuito de ejemplo, que se trata del control de
un actuador doble efecto, la razón de su elección es que es un circuito reconocido por sus múltiples
iteraciones en grandes circuitos de neumática, ası́ como en metodologı́as de resolución como es el
caso del método de cascada, además es un ejercicio correspondiente al segundo laboratorio de la
materia.
Figura 3-25: Control de un cilindro doble efecto, circuito de pruebas.
Para la construcción del circuito que se muestra en la figura 3-25, se tomaron en cuenta los
componentes modelados de la tabla 3-8.
A) Tomar extremo - RF13

Para empezar el desarrollo del requerimiento RF13 se utilizó nuevamente la interpolación lineal,
donde el punto inicial de la trayectoria es la posición del extremo de la manguera y las manos del
usuario son el punto destino, el script utiliza funciones del requerimiento RF09, la diferencia con este
requerimiento es que los extremos de la manguera tienen un nombre asignado en Unity que se debe
almacenar en una memoria cuando el usuario toma un extremo de la manguera, por lo que se creo
un tag al que se le nombro “Hose”. Para este requerimiento se agregaron dos colisionadores en los
extremos de una manguera que pasó a ser un objeto prefabricado como se muestra en la figura 3-26.
Figura 3-26: Colisionadores implementados en los conectores.
Para guardar el nombre de los extremos de mangueras en matrices de adyacencia o listas, se creó
una nomenclatura que permite extraer los datos de objetos prefabricados para asignar el dato
guardado en otras variables. La nomenclatura de la figura 3-27 divide dos tipos de datos con el
sı́mbolo “ ”, el primer dato que se puede extraer es si se esta tratando con una manguera o un
cable y que numero de objeto se está reconociendo, el segundo dato permite detectar si el usuario
a tomado el inicio o el final de la manguera.
Figura 3-27: Nomenclatura para guardar el extremo de la manguera.

B) Conectar extremo – RF14

Por otro lado, para empezar con el desarrollo del requerimiento RF14 se representó el circuito de
la figura 3-28 en un grafo como se ve en la figura tal, para posteriormente hallar un algoritmo con
la capacidad de guardar n datos en una lista o una matriz de adyacencia. Como se puede observar
en el grafo, en el circuito de pruebas existen 24 destinos posibles para conectar los extremos de las
mangueras lo que quiere decir que las posibles conexiones entre componentes en el circuito son de
6.204484e+23 y representan el universo de conexiones para el circuito de ejemplo.
Figura 3-28: Representación grafica del grafo, circuito de prueba.
Para detectar todos los conectores existentes en la escena de Unity se utilizaron los identificadores
de la tabla de instrumentos 3-8, de forma que el usuario obtenga propiedades como el nombre y
la posición del conector donde ha posado el rayo de la retı́cula. Los nombres de los conectores en
la escena de Unity se guardaron en objetos prefabricados, con la nomenclatura que se muestra en
la figura 3-29 donde el nombre de la pieza se representa por su identificador de la tabla 3-10,
el número de pieza se utiliza en caso de existir mas de una pieza del mismo tipo en una escena
armada, el pseudónimo se encarga de clasificar el tipo de entrada que puede tratarse del extremo
de una manguera o cable que se utilizan en botoneras o electro válvulas, finalmente se indica el
conector especifico de la pieza al que se esta conectando la manguera o cable.
Figura 3-29: Nomenclatura para el reconocimiento de instrumentos neumáticos.
El algoritmo que se desarrolló para el control de las n conexiones utiliza matrices de adyacencia,
primero se encarga de generar automáticamente un vector donde todos los nombres de conectores
en la escena se ordenan y almacenan alfabéticamente para identificar los vértices del grafo. Luego
crea una matriz nxn según la longitud del vector donde se guardan las conexiones en base a la
nomenclatura del requerimiento RF13 que contiene los nombres de los extremos de las mangueras
como se muestra en la figura 3-30.
Figura 3-30: Requerimiento RF14 y RF15 implementados.

C) Verificar conexión – RF15

Este requerimiento cumple dos funciones principales, la primera es verificar si un cable se a co-
nectado completamente utilizando un algoritmo de búsqueda capaz de verificar si los dos extremos
de una misma manguera se encontraban en la matriz de adyacencia y utilizando la traza de la
matriz como una memoria, de forma que si la conexión de dos instrumentos resultaba exitosa se
enviaba a través del informe de depuración como muestra la figura 3-31. La segunda función de
este requerimiento se creó para verificar si todas las conexiones hechas por el usuario eran correctas,
comparando la matriz ingresada por el usuario con las matrices que forman parte de un espacio de
soluciones.
Figura 3-31: Proceso de verificación.
3.4.6. Tercera etapa de interacciones

En esta etapa se hizo el tratamiento de variables y animaciones para manejar el circuito en cuestión
que es, hasta donde llega el escalamiento del software, es decir que el requerimiento RF16 y RF17
son variables de acuerdo al circuito, aunque no es un problema mayor ya que por lo general cuando
se trata con circuitos neumáticos lineales se utilizan variables booleanas que recaen en la activación
de cilindros neumáticos o ventosas. Hay que tomar en cuenta que por lo general los programas
orientados a relidad virtual no son escalables.
A) Accionar objeto – RF16

Este requerimiento se activa si y solo si la matriz ingresada por el usuario resulta ser parte del
espacio de soluciones del circuito, de modo que los colisionadores de los objetos que se contengan el
tag de ¨interactuable¨ se activen para que el usuario pueda realizar interacciones. Las interacciones
funcionan al terminarse la animación del requerimiento RF05 en base a animaciones con variables
3.5 Validación 68
booleanas, cuando se activan solo envı́an un cambio de variable como se puede observar en el
diagrama animador de la figura 3-32.
B) Actuadores – RF17
Similar al requisito RF16, el requisito RF17 funciona en base a animaciones solo que no son interac-
tuarles porque actúan de acuerdo a las variables que se envı́an por el requisito RF16. En el circuito
de prueba solo existe un actuador, su diagrama de animación se puede ver en la figura 3-33.
3.5. Validación
3.5.1. Retroalimentación Final
Como se planeó en la primera etapa del proyecto la retroalimentación del docente experto en la
materia y el docente Relator validaron la aplicación para proceder a hacer pruebas con los usuarios.
3.5 Validación 69
Esta etapa de retroalimentación se desarrolló en las semanas posteriores al WorkShop del taller de
grado de la carrera donde se obtuvo el visto bueno por los docentes, con las siguientes observaciones:
• La retı́cula de selección no es fácil de utilizar aun teniendo el temporizador, restringe la

correcta interacción con el entorno al ordenar o tomar los extremos de las mangueras y los
instrumentos.
• La verificación del circuito deberı́a representarse visual y continuamente, ya que en la versión

actual el usuario solo sabe que su conexión a sido exitosa al final y podrı́a ser frustrante para
los alumnos.
• El software no cuenta con herramientas didácticas o de guı́a en el entorno, el sistema deberı́a

ayudar un poco al estudiante en el armado del circuito.
3.5.2. Actualizaciones
En base a las observaciones del anterior apartado se hicieron actualizaciones a dos requisitos fun-
cionales y se creó un requisito no funcional para las herramientas didácticas del entorno como se
muestra en la tabla tal.
Tabla 3-11: Requisitos funcionales y no funcionales actualizados

Identificador Requisito Operación Descripción
Requiere de una segunda confirma-
Retı́cula de selec-
RF07 Actualizar ción para mejorar la interacción del
ción
usuario con los objetos.
El usuario debe poder ver su pro-
greso en todo momento, para conti-
RF15 Verificar conexión Actualizar
nuar o volver a empezar el armado
del circuito.
Se deben crear rótulos, y ayudas vi-
Herramientas
RNF07 Implementar suales para ayudar al usuario con el
didácticas
armado del circuito.
A) Herramientas didácticas – RFN07

Las herramientas didácticas implementadas para ayudar al usuario con el armado del circuito
fueron:
• Audio de instrucciones que guı́an por etapas al usuario.
• Diagrama del circuito dentro del entorno virtual.
• Se crearon rótulos con imágenes que contienen el sı́mbolo de todos los instrumentos de la
tabla 3-8.
3.5 Validación 70
• En la fase de conexión se remarca el conector en el que se posa el rayo de la retı́cula para

evitar confusiones en la selección del usuario.
Figura 3-34: Instrumentos neumáticos rotulados según normas de realidad virtual.
B) Actualización, retı́cula de selección - RF07

Su actualización consistió en crear un segundo método de confirmación para mejorar la interacción
del usuario con el entorno, la idea era agregar un botón para confirmar la acción a ejecutar pasado
el tiempo de la retı́cula, para lo cual se utilizó un control bluetooth antes visto en el estado del arte,
al cual se utiliza en base al mapeo de la figura 3-35, de manera que un botón del control simule
un clic o un toque en la pantalla. En su actualización también se cambió la imagen de retı́cula de
selección ya que se detectó que era invasiva en el campo de visión del usuario.
C) Actualización, Verificar conexión - RF15

Su actualización consistió en agregar en la escena un asset parecido a un semáforo que solo tiene
dos luces, la luz verde se mantiene en encendida en el proceso de conexión solo si las conexiones
están correctas de otra forma la luz roja se enciende y significa que el usuario cometió un error
por lo que debe empezar el armado del circuito desde el inicio reiniciando la escena. Aprovechando
los auriculares del HMD, el mapeo del control bluetooth y las nuevas variables de este requisito, se
agregó audio en este requerimiento que responde a decisiones del usuario al realizar las conexiones
en tiempo real, esto mejora la ilusión de plausibilidad de la aplicación en general.
3.6 Herramientas 71
Figura 3-35: Mapeo del control Bluetooth, hallado vı́a código.
3.6. Herramientas
3.6.1. Hardware
Las herramientas de hardware que se utilizaron a lo largo del desarrollo del proyecto para realizar
pruebas hasta validación del proyecto se muestran en la figura tal y son:
• Dream vision pro

Es un casco de realidad virtual de tipo Slide-on de la marca tzumi, con la capacidad de
sujetar teléfonos móviles de hasta 7 pulgadas y cuenta con audı́fonos retractiles.
• Control bluetooth
Es un control programable con el que se puede operar el teléfono móvil aun si se encuentra
dentro del HMD, se conecta a través de bluetooth y funciona con pilas AAA.
• Xiaomi Redmi Note 8 Pro

Es el teléfono donde se realizaron todas las pruebas locales, no representa restricción alguna en
cuanto a hardware ya que su pantalla mide 6.53 pulgadas, cuenta con bluetooth y sensores
inerciales como acelerómetro y giroscopio. Tampoco representa restricción en la parte de
software y se maneja con el sistema operativo Android 10.
3.6.2. Software
Los softwares que se utilizaron se muestran en la figura tal, la siguiente lista muestra el orden de
las herramientas de software según la utilidad y tiempo de uso:
• Unity
Es el motor de desarrollo elegido en el estado del arte, se puede decir que fue la herramienta
3.6 Herramientas 72
Figura 3-36: Hardware que integra el proyecto.
con la que se enlazo todo el contenido generado a lo largo del proyecto con el resto de
herramientas.
• Microsoft Visual Studio

Es el IDE donde se desarrolló la lógica de los algoritmos para generar todos los requerimientos
de la escena en Unity, todos los scripts desarrollados en esta plataforma están escritos en el
lenguaje de programación C#.
• Blender
Es un software de diseño 3D que se utilizó para modelar los objetos y entorno virtual en
general. Por otro lado, también se utilizó sus herramientas para el retoque de los modelos
en NURBS importados de SolidWorks lo que quiere decir que todos los modelos que forman
parte del proyecto pasaron por este software.
• SolidWorks
Es el software CAD que se utilizó para el modelado en NURBS de los instrumentos neumáticos
que aparecen en la escena de Unity.
• SDK GoogleCardboard
Es un kit de desarrollo que permitió desarrollar de manera ágil cuatro de los requerimientos
en la etapa de programación.
• Android Studio
El proyecto utiliza el SDK y NDK de Android principalmente para exportar el programa de la
computadora al teléfono móvil y evita problemas de compatibilidad con diferentes versiones
del sistema operativo Android.
3.7 Costos 73
• FluidSim
Es un simulador de neumática que se utilizó de referencia para la creación de herramientas
didácticas en la escena de Unity.
• JDK
Es una herramienta demandada por Android Studio ya que en esencia el sistema operativo
de Android se basa en el lenguaje de programación Java.
Figura 3-37: Software que integra el proyecto.
3.7. Costos
El cálculo del costo total del proyecto se muestra en la tabla tal, posteriormente se detalla el costo
por categorı́as en las subsecciones de este apartado.
Tabla 3-12: Costo de investigación

Categorı́a Costo (Bs)
Costo investigación 22500
Costo de ejecución 1950
Gastos e insumos 10924.3
Total 35374.3
3.7.1. Costo investigación

En la tabla tal se muestra el costo de la investigación general que incluye el diseño de soluciones
algorı́tmicas, programación, modelado poligonal, modelado en NURBS, retoque 3D y la documen-
tación. Los cálculos se basaron en el salario promedio de un ingeniero Junior y el tiempo invertido
en el proyecto.
3.7 Costos 74
Tabla 3-13: Costo de investigación

Salario promedio ingeniero junior (Bs) 4500
Tiempo de desarrollo (meses) 5
Total (Bs) 22500
3.7.2. Costo de ejecución

En la tabla tal se muestra el cálculo individual y total de los requisitos para ejecutar el proyecto, se
debe tomar en cuenta que el precio puede variar entre los usuarios de acuerdo a la marca y modelo
de celular que posea.
Tabla 3-14: Costo de ejecución

Elemento Costo [Bs]
HMD Slide-On Dream Vision Pro 75
Control bluetooth 25
Smartphone Xiaomi Redmi Note 8 Pro 1850
Total 1950
3.7.3. Gastos e insumos

En la tabla tal se desglosa de forma individual y total el precio de los insumos materialespara el
desarrollo del proyecto al momento de su compra.
Tabla 3-15: Costo de insumos

Elemento Costo [Bs]
Laptop 7656
Monitor 19” 1540
Accesorios 600
Total 9796
Para hallar el consumo de energı́a total del tiempo de desarrollo, se consideró que la energı́a utilizada
en el proyecto fue aproximadamente de seis dı́as a la semana, entre 6 a 7 horas por dı́a. Por tanto,
los cálculos del gasto en energı́a de la tabla tal, se basan en el tiempo de trabajo que son cinco
meses o 855 horas de trabajo y la tarifa por KWh de consumo de energı́a que en la ciudad de La
Paz es de 0.77Bs.
3.8 Resultados 75
Tabla 3-16: Gasto en electricidad

Consumo Tiempo de uso Costo
Elemento KWh
(Watts) (hr) (Bs)
Carga de Laptop 350 855 (100 %) 299.25 255.9
Carga del celular 8.5 171 (20 %) 1.45 1.1
Monitor 40 855 (100 %) 34.2 26.3
Total 283.3
Por otro lado el gasto en el servicio de internet se detalla en la tabla tal.
Tabla 3-17: Gasto en internet

Tarifa mensual axs (Bs) 169
Tiempo de desarrollo (meses) 5
Total (Bs) 845
3.8. Resultados
En este punto el proyecto es funcional y se han implementado todos los requerimientos planteados
en la etapa de planeación y retroalimentación.
3.8.1. Resultados
A) Definición de la solución
El proyecto que se desarrolló se puede definir como un entorno de realidad virtual que se puede
exportar a teléfonos móviles para realizar prácticas de la materia neumática e hidráulica (IMT-
241), con modelos virtuales basados en instrumentos neumáticos existentes en el laboratorio de la
UCB y en especı́fico con componentes de la serie MICRO.
B) Validación final
La validación de habilidades y conocimientos por parte del público objetivo se realizó a través del
docente experto en la materia de forma presencial como se muestra en la figura 3-38, el motivo
fue evitar contagios y proteger la salud del alumnado siguiendo las normas de distanciamiento social.
Primero se envió la aplicación final a través de bluetooth para verificar la compatibilidad de la

aplicación con otros dispositivos Android, obteniendo una respuesta favorable ya que después de la
instalación en su teléfono móvil, la aplicación funciono con normalidad. Posteriormente el docente
introdujo su dispositivo móvil en el visor Dream visión Pro y procedió a utilizar la aplicación con
normalidad.
3.8 Resultados 76
Figura 3-38: Laboratorio en la realidad.
Finalmente, tras la experiencia se obtuvo el visto bueno del docente que encontró la interfaz del
usuario intuitiva y finalizando las pruebas, pidió un cambio en el requerimiento RF07, ya que vio
conveniente agregar una segunda confirmación para mejorar la comodidad del usuario y otro cambio
en el requerimiento RF15 para que el usuario pueda ver su progreso en todo momento. Las correc-
ciones y actualizaciones de los requerimientos observados del entorno se realizaron en el apartado
de validación como se muestra en la tabla 3-11.
El prototipo funcional final con las actualizaciones implementadas se muestra en la figura 3-39,
donde se puede observar que todos los requisitos son completamente funcionales y que se puede
llegar hasta la última etapa de interacciones en la plataforma Android. Las conexiones realizadas
en el circuito de la imagen funcionan a través de la matriz de adyacencia que se muestra en la figura
3-41, donde se puede apreciar una simetrı́a que demuestra en base a informes de depuración que
el algoritmo de las n conexiones funciona de la manera esperada.
El diseño del entorno de realidad virtual se basó en conceptos de un programa especializado en

realidad virtual que ofrece la Universidad de Londres, por lo que el proyecto incluye detalles es-
pecı́ficos en esta área, como el modelado del laboratorio y modelos basados en las medidas reales
para generar la ilusión de lugar en el usuario. En cuanto a la ilusión de plausibilidad y encarna-
miento son caracterı́sticas que se pueden observar a lo largo de una sesión de aprendizaje, con
3.8 Resultados 77
Figura 3-39: Prueba final, prototipo con los requerimientos implementados.
sonidos y respuestas automáticas por parte del entorno. Finalmente una de las mejores formas de
evaluar los resultados puede ser basándose en la apariencia, una práctica de laboratorio con los
mismo componentes se muestra en la figura 3-40.
Figura 3-40: Laboratorio en la realidad.

3.8 Resultados 78
Figura 3-41: Matriz ingresada a través de la interfaz de usuario.

CAPÍTULO 4
Marco Conclusivo
4.1. Conclusiones
Terminado el desarrollo y documentación del proyecto se puede concretizar que:
• La premisa que plantea el objetivo general del proyecto se ha cumplido, ya que el software
desarrollado cuenta con algoritmos idóneos para que los alumnos de la carrera de ingenierı́a
mecatrónica experimenten y se familiaricen con los contenidos teóricos y prácticos de la
materia de NEUMÁTICA E HIDRÁULICA (IMT-241) a través de la realidad virtual.
• Si bien el trabajo cuenta con un análisis más profundo y enfocado a los instrumentos neumáti-
cos de la serie MICRO, no significa que los algoritmos desarrollados no se puedan aplicar a
otro tipo de circuitos y componentes que son parte de la materia, ya que las conexiones están
presentes en todo tipo de circuitos y en diferentes asignaturas a lo largo de la carrera, donde
las fı́sicas de manipulación de objetos e inclusive la de cables y mangueras es totalmente
aplicable y útil.
• Los modelos y prototipos tanto de los instrumentos, como del ambiente de laboratorio im-
plementados en el proyecto pueden generar en el usuario las tres ilusiones que distinguen a
la realidad virtual de otro tipo de simuladores, produciendo potencial para reducir el uso
indebido de los instrumentos del laboratorio y evitar los accidentes ocasionados por error de
principiante por parte del alumnado, ya que el entorno de realidad virtual implementado se
puede dotar a los estudiantes destinatarios previo a la realización de una práctica generando
en su memoria, conocimiento teórico y practico del área.
• El proyecto no solo es una solución a la problemática planteada, la razón es que viene con
múltiples beneficios que podrı́an ayudar a crecer aún más a la carrera, simulando laboratorios
de otras asignaturas que puedan utilizar la interfaz de usuario, los algoritmos y los modelos
que se ha implementado en el proyecto. El beneficio para la universidad seria la reducción en
gasto de recursos y mantenimiento de equipos.
• El laboratorio en realidad virtual desarrollado tiene la capacidad de romper con problemas

convencionales que tienen los laboratorios tradicionales, ya que con el proyecto las prácticas
4.2 Recomendaciones 80
de laboratorio se pueden llevar a cabo en cualquier momento y sin horarios. Claro está que
también cuenta con deficiencias y limitaciones que cualquier aplicación de realidad virtual,
la diferencia radica en que estas se pueden solventar en próximas versiones.
• El prototipo permite difundir aprendizaje con un método constructivista ya que las practicas
son individuales, debido a esto los alumnos podrı́an mejorar su capacidad de análisis y mejorar
su toma de decisiones en prácticas reales.
4.2. Recomendaciones
Los programas desarrollados para realidad virtual no son aptos para epilépticos, ya que se corren
altos riesgos de sufrir un ataque. Tampoco es recomendable el uso en niños menores a los 7 años, la
razón es que aun a esa edad el ser humano no ha desarrollado por completo la visión estereoscópica
y eso podrı́a generar problemas a la larga.
Antes de empezar con el desarrollo de un proyecto similar, es recomendable tener buenas prácticas
en programación orientada a objetos y saber sobre resolución de algoritmos, ya que en muchos
casos se deberá generar algoritmos muy especı́ficos o existirán una cantidad reducida de soluciones,
la razón es que el interés en realidad virtual recién ha brotado en los últimos años.
Es recomendable evaluar la aplicación en varios dispositivos para evitar fallas e incompatibilidades

ya sea por gráficos, código o error en los sensores. Para evitar este tipo de problemas se recomienda
el uso de kit de desarrollo de software (SDK) especı́fico para el área.
Tomando en cuenta que la realidad virtual es una tecnologı́a emergente no existen formas predefini-
das para aplicabilidad e ingenierı́a de software, es recomendable hacer una investigación exhaustiva
en metodologı́as que se ajusten a los requerimientos del proyecto.
4.3. Trabajo Futuro

Tras analizar los resultados del proyecto y hallar conclusiones se han pensado en las siguientes ideas
a futuro:
• La segunda versión del proyecto podrı́a incluir un modo en multiusuario a través de internet,
para que las prácticas de laboratorio se realicen de forma grupal o con supervisión del docente
a larga distancia.
• A partir de los modelos y algoritmos generados en el proyecto se puede implementar labora-

torios para otras asignaturas.
• Se podrı́a realizar la virtualización de maquinaria y equipos que no tenemos en los laboratorios

de la UCB para capacitación.
4.3 Trabajo Futuro 81
• La realidad virtual avanza muy rápido, quizá lo mejor para trabajos futuros sea cambiar de
plataforma a algún visor de la empresa Oculus, ya que es la única empresa que a empezado
a bajar el precio de sus visores y pronto podrı́an ser dispositivo accesibles para el público en
general.
Bibliografı́a
[1] J. M. Boneu, “Plataformas abiertas de e-learning para el soporte de contenidos educativos

abiertos,” RUSC. Universities and Knowledge Society Journal, vol. 4, no. 1, pp. 36–47, 2007.
[2] J. Vary, “Informe de la reunión de expertos sobre laboratorios virtuales,” Instituto Interna-
cional de Fı́sica Teórica y Aplicada (IITAP), Ames, Iowa–UNESCO, Parı́s, 2000.
[3] I. Calvo, E. Zulueta, U. Gangoiti, J. M. López, H. Cartwright, and K. Valentine, Laboratorios

remotos y virtuales en enseñanzas técnicas y cientı́ficas. Ikastorratza, 2009, vol. 3, no. 3.
[4] M. Hernández-de Menéndez, A. V. Guevara, J. C. T. Martı́nez, D. H. Alcántara, and

R. Morales-Menendez, “Active learning in engineering education. a review of fundamentals,
best practices and experiences,” International Journal on Interactive Design and Manufactu-
ring (IJIDeM), vol. 13, no. 3, pp. 909–922, 2019.
[5] B. C. Moyano, M. M. Morató, and J. Santos, “La gamificación en la educación superior.

aspectos a considerar para una buena aplicación,” Pedagogı́as Emergentes En La Sociedad
DIgita, vol. 21, 2019.
[6] A. Loureiro and T. Bettencourt, “The use of virtual environments as an extended classroom–a
case study with adult learners in tertiary education,” Procedia Technology, vol. 13, pp. 97–106,
2014.
[7] D. D. McMahon, D. F. Cihak, R. E. Wright, and S. M. Bell, “Augmented reality for teaching
science vocabulary to postsecondary education students with intellectual disabilities and au-
tism,” Journal of Research on Technology in Education, vol. 48, no. 1, pp. 38–56, 2016.
[8] R. Estriegana, J.-A. Medina-Merodio, and R. Barchino, “Student acceptance of virtual labo-
ratory and practical work: An extension of the technology acceptance model,” Computers &
Education, vol. 135, pp. 1–14, 2019.
[9] N. Unidas, “Informe de polı́ticas: La educación durante la covid-19 y después de

ella,” Aug 2020. [Online]. Available: https://www.un.org/sites/un2.un.org/files/policy brief
- education during covid-19 and beyond spanish.pdf
[10] F. Wang, X. Xu, W. Feng, J. B. Vesga, Z. Liang, and S. Murrell, “Towards an immersive
guided virtual reality microfabrication laboratory training system,” in 2020 IEEE Conference
on Virtual Reality and 3D User Interfaces Abstracts and Workshops (VRW), 2020, pp. 796–
797.
BIBLIOGRAFÍA 83
[11] F. Grivokostopoulou, I. Perikos, K. Kovas, M. Paraskevas, and I. Hatzilygeroudis, “Utilizing

virtual reality to assist students in learning physics,” in 2017 IEEE 6th International Confe-
rence on Teaching, Assessment, and Learning for Engineering (TALE), 2017, pp. 486–489.
[12] D. Kamińska, T. Sapiński, N. Aitken, A. Della Rocca, M. Barańska, and R. Wietsma, “Vir-
tual reality as a tool in mechatronics education,” in 2017 18th International Symposium on
Electromagnetic Fields in Mechatronics, Electrical and Electronic Engineering (ISEF) Book of
Abstracts, 2017, pp. 1–2.
[13] E. Handoko and D. Gunawan, “Parabolix: Educational simulation game on classical mechanics
based on virtual reality and perlin noise algorithm,” in 2019 5th International Conference on
New Media Studies (CONMEDIA), 2019, pp. 165–170.
[14] V3CORE. (2019-08-28) Siemens vr training, virtual reality maintenan-

ce training. [Online]. Available: https://www.visionthree.com/insight/2019/8/27/
siemens-setting-the-bar-supporting-customers-with-virtual-reality-training-zwlkp
[15] STRIVR. (2016-12-14) Safety on the floor: How bmw uses virtual reality for safety awareness.
[Online]. Available: https://www.strivr.com/resources/customers/bmw/
[16] G. P. Gasca-Hurtado, A. Peña, M. C. Gómez-Álvarez, Ó. A. Plascencia-Osuna, and J. A.

Calvo-Manzano, “Virtual reality as good practice for teamwork with engineering students,”
RISTI-Revista Ibérica de Sistemas e Tecnologias de Informação, pp. 76–91, 2015.
[17] D. Cantón Enrı́quez, J. J. Arellano Pimentel, M. Á. Hernández López, and O. S. Nieva Garcı́a,
“Uso didáctico de la realidad virtual inmersiva con interacción natural de usuario enfocada a
la inspección de aerogeneradores,” Apertura (Guadalajara, Jal.), vol. 9, no. 2, pp. 8–23, 2017.
[18] D. A. Garcı́a Fernández and D. L. Patiño Aguilar, “Desarrollo de una herramienta de apoyo
para el estudio de la naturaleza de la luz usando realidad virtual inmersiva,” 2017.
[19] F. E. Correa Falcón, “Creación de una aplicación interactiva utilizando realidad virtual para
plataforma android,” B.S. thesis, Quito: UCE, 2018.
[20] P. A. López Encalada, “Desarrollo de una aplicación para simular un vuelo con realidad vir-
tual por el entorno ecuatoriano con el avión de combate de las fuerzas armadas del ecuador
“tucano”, para plataformas android utilizando unity y google vr,” B.S. thesis, Quito: UCE,
2019.
[21] XinReality. (2016-02-04) Slide-on hmd. [Online]. Available: https://xinreality.com/wiki/

Slide-on HMD
[22] N. M. Papachristos, I. Vrellis, and T. A. Mikropoulos, “A comparison between oculus rift and
a low-cost smartphone vr headset: immersive user experience and learning,” in 2017 IEEE
17th International Conference on Advanced Learning Technologies (ICALT). IEEE, 2017,
pp. 477–481.
BIBLIOGRAFÍA 84
[23] XinReality. (2016-02-04) Discrete hmd. [Online]. Available: https://xinreality.com/wiki/

Discrete HMD
[24] A. Borrego, J. Latorre, M. Alcaniz, and R. Llorens, “Comparison of oculus rift and htc vive:
feasibility for virtual reality-based exploration, navigation, exergaming, and rehabilitation,”
Games for health journal, vol. 7, no. 3, pp. 151–156, 2018.
[25] XinReality. (2016-02-04) Integrated hmd. [Online]. Available: https://xinreality.com/wiki/

Integrated HMD
[26] M. Sánchez, “Microsoft hololens,” 2016.
[27] M. A. Festini Wendorff and C. M. Torres Ferreyros, “Desarrollo de un videojuego con unreal
engine,” 2017.
[28] R. Boyd, “Implementing reinforcement learning in unreal engine 4 with blueprint,” Ph.D.
dissertation, University Honors College, Middle Tennessee State University, 2017.
[29] A. Juliani, V.-P. Berges, E. Vckay, Y. Gao, H. Henry, M. Mattar, and D. Lange, “Unity: A
general platform for intelligent agents,” arXiv preprint arXiv:1809.02627, 2018.
[30] N. Nurym, R. Sambetova, M. Azybaev, and N. Kerimbayev, “Virtual reality and using the
unity 3d platform for android games,” in 2020 IEEE 10th International Conference on Inte-
lligent Systems (IS). IEEE, 2020, pp. 539–544.
[31] H. M. R. Moreno, L. C. C. Estrada, and C. F. Á. Caicedo, “Análisis a la implementación de la

realidad virtual como herramienta tecnológica emergente y su aplicación en el ámbito educati-
vo. caso: Simulador virtual de tiro en la escuela de cadetes de policı́a general francisco de paula
santander, colombia erika andrea camacho barón1,” REVOLUCIÓN EN LA FORMACIÓN Y
LA CAPACITACIÓN PARA EL SIGLO XXI, p. 351.
[32] C. Sultan, M. Corless, and R. E. Skelton, “Tensegrity flight simulator,” Journal of Guidance,
Control, and Dynamics, vol. 23, no. 6, pp. 1055–1064, 2000.
[33] M. L. Heilig, “Sensorama simulator,” Aug. 28 1962, uS Patent 3,050,870.
[34] P. Luckey, B. I. Trexler, G. England, and J. McCauley, “Virtual reality headset,” Sep. 8 2015,
uS Patent App. 29/472,807.
[35] D. W. Carruth, “Virtual reality for education and workforce training,” in 2017 15th Interna-
tional Conference on Emerging eLearning Technologies and Applications (ICETA). IEEE,
2017, pp. 1–6.
[36] M. Slater, “Place illusion and plausibility can lead to realistic behaviour in immersive virtual
environments,” Philosophical Transactions of the Royal Society B: Biological Sciences, vol.
364, no. 1535, pp. 3549–3557, 2009.
BIBLIOGRAFÍA 85
[37] A. Borrego, J. Latorre, M. Alcañiz, and R. Llorens, “Embodiment and presence in virtual
reality after stroke. a comparative study with healthy subjects,” Frontiers in neurology, vol. 10,
p. 1061, 2019.
[38] A. A. P. Conde, A. P. Fuentes, and A. P. Fuentes, “Sistema de visión estereoscópica basado

en gafas de realidad virtual y su aplicación en fotogeologı́a stereoscopic vision system based
on virtual reality glasses and its application in photogeology.”
[39] R. SÁNCHEZ-CABRERO, M. A. NOVILLO-LÓPEZ, A. ARIGITA-GARCÍA, Ó. COSTA-

ROMÁN, A. BARRIENTOS-FERNÁNDEZ, and F. J. PERICACHO-GÓMEZ, “Carencias y
limitaciones que afectan al asentamiento de la realidad virtual como tecnologı́a de referencia
en la sociedad actual,” Revista ESPACIOS, vol. 40, no. 10, 2019.
[40] R. A. Ghignone, F. S. Larosa, I. Castelucci Vidal, and M. Garcı́a Cabana, “Desarrollo de un

sistema embebido de fusión de sensores para cálculos de orientación.” Congreso Argentino
de Sistemas Embebidos (2018 ago 15-17: Córdoba), 2018.
[41] G. A. T. Samperio, A. F. Arcega, M. D. J. G. Sánchez, and A. S. Navarrete, “Metodologı́a

para el modelado de sistemas de realidad virtual para el aprendizaje en dispositivos móviles,”
Pistas Educativas, vol. 39, no. 127, 2018.
[42] W. F. Santos Rodriguez et al., “Aplicación de sistemas mems integrados en smartphones para
la detección y análisis de vibraciones mecánicas de baja frecuencia de estructuras civiles.”
[43] K. L. Zegarra Tacsa, “Grúa mecatrónica de tres grados de libertad basada en cables y contro-
lada por dispositivo móvil: Gm-lk.”
[44] V. Google, “Google vr ndk controller, google developers,” Oct 2018. [Online]. Available:
https://developers.google.com/vr/reference/gvr-ndk-controller
[45] W. E. Acevedo Sierra, “Acelerometro, principio y aplicacion del sensor de aceleracion emplean-
do la tecnologia mems (micro electro-mechanical systems).” Ph.D. dissertation, Universidad
Industrial de Santander, Escuela de Ingenierı́a Eléctrica . . . , 2004.
[46] F. J. Somma, “Cuaterniones y ángulos de euler para describir rotaciones en,” Ph.D. disserta-
tion, UNIVERSIDAD ABIERTA INTERAMERICANA, 2018.
[47] G. T. del Castillo, “La representación de rotaciones mediante cuaterniones,” Miscelanea Ma-
temtica, pp. 43–50, 1999.
[48] J. Chen, “Open sourcing google cardboard,” Nov 2019. [Online]. Available: https:
//developers.googleblog.com/2019/11/open-sourcing-google-cardboard.html
[49] O. Meza and M. Ortega, “Grafos y algoritmos,” Equinoccio, Ediciones de la Universidad Simón
Bolı́var. Caracas, 1993.
[50] E. Coto, “Algoritmos básicos de grafos,” Lecturas en Ciencias de computación. ISSN 1316,
vol. 6239, 2003.
BIBLIOGRAFÍA 86
[51] E. Simó Mezquita, Vulnerabilidad del diámetro de ciertas familias de grafos. Universitat
Politècnica de Catalunya, 1995.
[52] F. Rincón, N. Henao, and P. Beltrán, “De los sólidos platónicos a los arquimedianos: un estudio
desde las matrices de adyacencia,” 2017.
[53] R. S. Pressman, “Ingenierı́a del software,” Un enfoque, 2011.
[54] M. Trigás Gallego, “Metodologia scrum,” 2012.
[55] R. S. Pressman and J. M. Troya, “Ingenierı́a del software,” 1988.
[56] D. Gallardo López and C. Pomares Puig, “Programación orientada a objetos,” Lenguajes y
Paradigmas de Programación, 2008.
[57] A. E. C. González, “Programación orientada a objetos,” 2018.
[58] U. Technologies, “Unity user manual (2019.4 lts),” 2020. [Online]. Available: https:
//docs.unity3d.com/Manual/UnityManual.html
[59] J. Antón Alonso and X. Zhu Chen, “Estudio y simulación de un vehı́culo autopilotado en unity
5 haciendo uso de algoritmos de aprendizaje automático,” 2018.
[60] S. Hernández, P. Millado, C. Delrieux, and M. P. Cipolletti, “Interpolación polinomial,” in

XIV Workshop de Investigadores en Ciencias de la Computación, 2012.
[61] J. Rojas, R. Martı́nez, and M. Morales, “Mecánica 3d: python y el algoritmo de verlet,” Revista
mexicana de fı́sica E, vol. 60, no. 1, pp. 51–65, 2014.
APÉNDICE A
Anexo: Scripts
En este apartado se incluyeron los guiones más esenciales para el funcionamiento del programa y
los que podrı́an ser de interés de los lectores.
A.1. Lógica de locomoción
using System . C o l l e c t i o n s ;
using System . C o l l e c t i o n s . G e n e r i c ;
using UnityEngine ;
using UnityEngine . UI ;
p u b l i c c l a s s TeleportManager : MonoBehaviour
{
#r e g i o n S i n g l e t o n
p r i v a t e s t a t i c TeleportManager i n s t a n c e ;
p u b l i c s t a t i c TeleportManager I n s t a n c e
{
get
{
i f ( i n s t a n c e == n u l l )
{
i n s t a n c e = new TeleportManager ( ) ;
}
return instance ;
}
}
#e n d r e g i o n
[ Header ( ” T e l e p o r t ” ) ]
A.1 Lógica de locomoción 88
p u b l i c Image imgFade ;
[ Range ( 0 f , 1 f ) ] p u b l i c f l o a t t i m e T e l e p o r t = 0 . 5 f ;
p u b l i c Transform p l a y e r ;
f l o a t playerGroundPos ; / / v a r i a b l e para e v i t a r que s e m o d i f i q u e l a
p o c i s i o n o r i g i n a l d e l p l a y e r en y
p r i v a t e v o i d Awake ( )
{
{
instance = this ;
}
else
{
Destroy ( gameObject ) ;
}
}
void Start ( )
{
playerGroundPos = p l a y e r . p o s i t i o n . y ;
Fade ( t r u e ) ;
}
p u b l i c v o i d Fade ( b o o l i s F a d e I n )
{
i f ( i s F a d e I n ) imgFade . CrossFadeAlpha ( 0 , t i m e T e l e p o r t , t r u e ) ;
//0 i n v i s i b l e , tiempo 0 , 5 s , i g n o r a t i m e s c a l e
e l s e imgFade . CrossFadeAlpha ( 1 , t i m e T e l e p o r t , t r u e ) ;
}
p u b l i c v o i d T e l e p o r t ( Vector3 newPos ) // r e c i b e p o s i c i o n de t e l e p o r t
point
{
S t a r t C o r o u t i n e ( MovePosition ( newPos ) ) ;
}
IEnumerator MovePosition ( Vector3 newPos )
{
Fade ( f a l s e ) ;
y i e l d r e t u r n new WaitForSeconds ( t i m e T e l e p o r t ) ;
p l a y e r . p o s i t i o n = new Vector3 ( newPos . x , newPos . y +
playerGroundPos , newPos . z ) ;
y i e l d r e t u r n new WaitForSeconds ( t i m e T e l e p o r t ) ;
Fade ( t r u e ) ;
A.2 Integral de Verlet 89
}
}
A.2. Integral de Verlet
u s i n g UnityEngine ;
u s i n g System ;
u s i n g System . C o l l e c t i o n s ;
p u b l i c c l a s s HoseComponent : MonoBehaviour
{
#r e g i o n C l a s s members
[ SerializeField ] private int v e r l e t i t e = 1;

[ SerializeField ] private int solveite = 1;
[ SerializeField ] private float s t i f f = 1 f ;
p u b l i c LineRenderer l i n e ;
p r i v a t e DrawVerlet [ ] p o i n t s ;
[ S e r i a l i z e F i e l d ] p r i v a t e Transform endPoint ;
public Material hoseMaterial ;
[ S e r i a l i z e F i e l d ] p r i v a t e f l o a t hoseLength = 0 . 5 f ;
[ SerializeField ] private int totalSeg = 5;
[ S e r i a l i z e F i e l d ] p r i v a t e f l o a t segpu = 2 f ;
p r i v a t e i n t segments = 0 ;
[ S e r i a l i z e F i e l d ] p r i v a t e f l o a t hoseW = 0 . 1 f ;
#e n d r e g i o n
#r e g i o n I n i t i a l s e t u p
void Start ( )
{
InitDrawVerlets () ;
InitLineRenderer () ;
}
void InitDrawVerlets ( )
i f ( t o t a l S e g > 0)
segments = t o t a l S e g ;
else
segments = Mathf . C e i l T o I n t ( hoseLength ∗ segpu )
;
Vector3 c a b l e D i r e c t i o n = ( endPoint . p o s i t i o n − t r a n s f o r m
. p o s i t i o n ) . normalized ;
f l o a t i n i t i a l S e g m e n t L e n g t h = hoseLength / segments ;
p o i n t s = new DrawVerlet [ segments + 1 ] ;
f o r ( i n t p o i n t I d x = 0 ; p o i n t I d x <= segments ; p o i n t I d x
++) {
Vector3 i n i t i a l P o s i t i o n = t r a n s f o r m . p o s i t i o n +
( cableDirection ∗ ( initialSegmentLength ∗
pointIdx ) ) ;
p o i n t s [ p o i n t I d x ] = new DrawVerlet (
initialPosition ) ;
}
DrawVerlet s t a r t = p o i n t s [ 0 ] ;
DrawVerlet end = p o i n t s [ segments ] ;
s t a r t . Bind ( t h i s . t r a n s f o r m ) ;
end . Bind ( endPoint . t r a n s f o r m ) ;
}
void InitLineRenderer ( )
{
l i n e = t h i s . gameObject . AddComponent<LineRenderer >() ;
l i n e . SetWidth ( hoseW , hoseW ) ;
l i n e . SetVertexCount ( segments + 1 ) ;
l i n e . GetComponent<Renderer >() . e n a b l e d = t r u e ;
l i n e . material = hoseMaterial ;
}
#e n d r e g i o n
#r e g i o n Render Pass
v o i d Update ( )
{
RenderCable ( ) ;
v o i d RenderCable ( )
{
f o r ( i n t p o i n t I d x = 0 ; p o i n t I d x < segments + 1 ;
p o i n t I d x++)
{
l i n e . SetPosition ( pointIdx , points [ pointIdx ] .
Position ) ;
}
}
#e n d r e g i o n
#r e g i o n V e r l e t i n t e g r a t i o n & s o l v e r p a s s
v o i d FixedUpdate ( )
{
for ( int verletIdx = 0; verletIdx < verletite ;
v e r l e t I d x ++)
{
VerletIntegrate () ;
SolveConstraints () ;
}
}
void V e r l e t I n t e g r a t e ( )
{
Vector3 g r a v i t y D i s p l a c e m e n t = Time . f i x e d D e l t a T i m e ∗
Time . f i x e d D e l t a T i m e ∗ −1;
f o r e a c h ( DrawVerlet p a r t i c l e i n p o i n t s )
{
p a r t i c l e . UpdateVerlet ( gravityDisplacement ) ;
}
void SolveConstraints ( )
{
for ( int iterationIdx = 0; iterationIdx < solveite ;

i t e r a t i o n I d x ++)
{
SolveDistanceConstraint () ;
SolvestiffConstraint () ;
}
}
#e n d r e g i o n
#r e g i o n S o l v e r C o n s t r a i n t s
void SolveDistanceConstraint ( )
{
f l o a t segmentLength = hoseLength / segments ;
f o r ( i n t SegIdx = 0 ; SegIdx < segments ; SegIdx++)
{
DrawVerlet parA = p o i n t s [ SegIdx ] ;
DrawVerlet parB = p o i n t s [ SegIdx + 1 ] ;
SolveDistanceConstraint ( particleA , particleB ,

segmentLength ) ;
}
}
v o i d S o l v e D i s t a n c e C o n s t r a i n t ( DrawVerlet p a r t i c l e A , DrawVerlet
p a r t i c l e B , f l o a t segmentLength )
{
Vector3 d e l t a = p a r t i c l e B . P o s i t i o n − par
A. P o s i t i o n ;
f l o a t c u r r e n t D i s t a n c e = d e l t a . magnitude ;
f l o a t e r r o r F a c t o r = ( c u r r e n t D i s t a n c e − segmentLength ) /
currentDistance ;
i f ( parA . I s F r e e ( ) && parB . I s F r e e ( ) )

{
parA . P o s i t i o n += e r r o r F a c t o r ∗ 0 . 5 f ∗ d e l t a ;
parB . P o s i t i o n −= e r r o r F a c t o r ∗ 0 . 5 f ∗ d e l t a ;
}
else i f ( particleA . IsFree () )
{
parA . P o s i t i o n += e r r o r F a c t o r ∗ d e l t a ;
}
e l s e i f ( parB . I s F r e e ( ) )
{
p a r t i c l e B . P o s i t i o n −= e r r o r F a c t o r ∗ d e l t a ;
}
}
void S o l v e s t i f f ( )
{
f l o a t d i s t a n c e = ( p o i n t s [ 0 ] . P o s i t i o n − p o i n t s [ segments
] . P o s i t i o n ) . magnitude ;
i f ( d i s t a n c e > hoseLength )
{
f o r e a c h ( DrawVerlet p a r t i c l e i n p o i n t s )
{
SolvestiffConstraint ( particle , distance
);
}
}
}
v o i d S o l v e s t i f f ( DrawVerlet DrawVerlet , f l o a t d i s t a n c e )
{
#e n d r e g i o n
}
A.3 Logica de Interpolación 94
A.3. Logica de Interpolación
u s i n g System . C o l l e c t i o n s . G e n e r i c ;
p u b l i c c l a s s I n t e r p o l a t i o n M a n a g e r : MonoBehaviour
{
#r e g i o n S i n g l e t o n
private s t a t i c InterpolationManager instance ;
public s t a t i c InterpolationManager Instance
{
get
{
{
i n s t a n c e = new I n t e r p o l a t i o n M a n a g e r ( ) ;
}
return instance ;
}
}
#e n d r e g i o n
p r i v a t e v o i d Awake ( )
{
{
instance = this ;
}
else
{
Destroy ( gameObject ) ;
}
}
p u b l i c v o i d I n t e r p o l a t i o n ( Vector3 moveTo , GameObject o b j e c t )
{
S t a r t C o r o u t i n e ( I n t e r p o l a t i o n P o s i t i o n ( moveTo , o b j e c t , 0 . 7 f ) ) ;
//Debug . Log ( ” Mis manos e s t a n l l e n a s ” ) ;
}
IEnumerator I n t e r p o l a t i o n P o s i t i o n ( Vector3 t a r g e t P o s i t i o n ,
GameObject o b j e c t , f l o a t d u r a t i o n )
{
f l o a t time = 0 ;
A.4 Lógica del Grafo y Retı́cula de selección 95
Vector3 s t a r t P o s i t i o n = o b j e c t . transform . p o s i t i o n ;
w h i l e ( time < d u r a t i o n )
{
o b j e c t . t r a n s f o r m . p o s i t i o n = Vector3 . Lerp ( s t a r t P o s i t i o n ,
t a r g e t P o s i t i o n , time / d u r a t i o n ) ;
time += Time . deltaTime ;
yield return null ;
}
// o b j e c t . gameObject . S e t A c t i v e ( f a l s e ) ;
i f ( o b j e c t . name == ” l e n t e s ” )
{
object . SetActive ( f a l s e ) ;
}
o b j e c t . transform . p o s i t i o n = t a r g e t P o s i t i o n ;
}
}
A.4. Lógica del Grafo y Retı́cula de selección
u s i n g UnityEngine . UI ;
p u b l i c c l a s s R e t i c l e S e l e c t i o n : MonoBehaviour
{
p u b l i c Image R e t i c l e T ;
p u b l i c f l o a t timTotal ;
p u b l i c f l o a t timCurrent ;
public bool i n t e r a c t i o n ;
p r i v a t e Ray cast Hit h i t ;
// t o o l s l o g i c
p u b l i c GameObject myHands ;
GameObject t o o l ;
[ SerializeField ]
p r i v a t e b o o l busyHands ;
p r i v a t e i n t a l l t o o l s =0;
// l o g i c h o s e
GameObject h o s e ;
// c o n e c t i o n s
private s t r i n g phrase ;
p u b l i c s t r i n g [ , ] c o n e x i o n e s = new s t r i n g [ 2 5 , 2 5 ] ;
// v e r i f i c a r
p r i v a t e i n t [ , ] s o l u t i o n s = new i n t [ 2 5 , 2 ] ;
// I n t e r a c t u a b l e s
A n i m a t o r C o n t r o l l e r P a r a m e t e r param ;
p u b l i c Animator ani , CDE;
p u b l i c GameObject c i l i n d r o ;
bool f l a g ;
// CountManager
p u b l i c CountManager countManager ;
p u b l i c i n t phase ;
i n t count ;
// G a m i f i c a t i o n
[ SerializeField ]
private Material HoseMaterial ;
[ SerializeField ]
private Material ConectorMaterial ;
i n t puntos ;
// Probe
public f l o a t rotationSpeed = 30;
void Start ( )
{
T im er E xi t ( ) ;
Crear Matriz () ;
phaseLab ( ) ;
countManager = GameObject . Find ( ” GameManager ” ) . GetComponent<
CountManager >() ;
}
v o i d Update ( )
{
Timer ( ) ;
i f ( p321 . t r a n s f o r m . p o s i t i o n . x > p322 . t r a n s f o r m . p o s i t i o n . x &&

mem == 0 )
{
Vector3 t e m p P o s i t i o n = p321 . t r a n s f o r m . p o s i t i o n ;
p321 . t r a n s f o r m . p o s i t i o n = p322 . t r a n s f o r m . p o s i t i o n ;
p322 . t r a n s f o r m . p o s i t i o n = t e m p P o s i t i o n ;
mem++;
}
i f ( puntos ==9 && mem==0)
{
phaseLab ( ) ;
}
}
public void Cilindro ( bool estado )
{
CDE = c i l i n d r o . GetComponent<Animator >() ;
CDE. S e t B o o l ( ”COn” , e s t a d o ) ;
}
IEnumerator Espera ( b o o l e s t a d o )
{
y i e l d r e t u r n new WaitForSeconds ( 1 ) ;
a n i . S e t B o o l ( ”Go” , f a l s e ) ;
Cilindro ( estado ) ;
}
IEnumerator c o n e c t o r C o l o r ( MeshRenderer [ ] c o n e c t o r s )
{
y i e l d r e t u r n new WaitForSeconds ( 0 . 5 f ) ;
f o r e a c h ( var n e g r i i n c o n e c t o r s )
{
n e g r i . m a t e r i a l = Conector ;
}
}
p r i v a t e v o i d Timer ( )
{
i f ( interaction )
{
p r i n t ( ” Estoy d e t e c t a n d o a l g o ” ) ;
timCurrent += Time . deltaTime ;

R e t i c l e T . f i l l A m o u n t = timCurrent / t i m T o t a l ;
i f ( timCurrent >= t i m T o t a l && Input . GetKeyDown ( KeyCode .
Mouse0 ) )
{
interaction = false ;
i f ( P h y s i c s . Raycast ( Camera . main . t r a n s f o r m . p o s i t i o n ,

Camera . main . t r a n s f o r m . forward , out h i t , Mathf .

Infinity ))
{
p r i n t ( ” e s t o y aprentando c l i c k ” ) ;
switch ( h i t . c o l l i d e r . tag )
{
case ” tools ”:
t o o l = h i t . c o l l i d e r . gameObject ;
p r i n t ( ”Tome e l o b j e t o : ”+ h i t . c o l l i d e r . name )
;
p r i n t ( ” Ordene e l o b j e t o : ” + h i t . c o l l i d e r .
name ) ;
p r i n t ( ” Estoy cargando e l o b j e t o : ” + h i t .
c o l l i d e r . name ) ;
t o o l . GetComponent() . e n a b l e d =
false ;
InterpolationManager . Instance . Interpolation
( myHands . t r a n s f o r m . p o s i t i o n , t o o l ) ;
a l l t o o l s ++;
busyHands = t r u e ;
i f ( a l l t o o l s == countManager . countTool )
{
phase =1;
phaseLab ( ) ;
}
t o o l . t r a n s f o r m . S e t P a r e n t ( myHands . t r a n s f o r m
. parent ) ;
break ;
case ” hose ” :
h o s e = h i t . c o l l i d e r . gameObject ;
h o s e . GetComponent() . e n a b l e d =
false ;
( myHands . t r a n s f o r m . p o s i t i o n , h o s e ) ;
i f ( h o s e . GetComponent<CableComponent >() )
{
LineRenderer HoseMaterialx = hose .
GetComponent<CableComponent >() . l i n e ;
HoseMaterialx . material = HoseMaterial ;
}
break ;
c a s e ”mesa ” :
t o o l . t r a n s f o r m . S e t P a r e n t ( gameObject .
transform . parent ) ;
i f ( phase == 1 ) h i t . c o l l i d e r . gameObject .
GetComponent() . e n a b l e d =
false ;
( h i t . point , t o o l ) ;
p r i n t ( ” Deje e l o b j e t o en : ” + h i t . c o l l i d e r .
name ) ;
break ;
case ” conector ”:
h i t . c o l l i d e r . GetComponent() .
enabled = f a l s e ;
count = numberTool ( h i t . c o l l i d e r . name ) ;
p r i n t ( ” c o n e c t a n d o a ”+ h i t . c o l l i d e r . name ) ;
C l a s i f i c a d o r C R ( h i t . c o l l i d e r . name . S p l i t ( ’ ’ )
, count ) ;
break ;
case ” t e l e p o r t s ”:
p r i n t ( ” T e l e p o r t t o : ” + h i t . c o l l i d e r . name )
;
TeleportManager . I n s t a n c e . T e l e p o r t ( h i t . p o i n t
);
break ;
c a s e ” camera2 ” :
TeleportManager . I n s t a n c e . T e l e p o r t ( h i t . p o i n t
);
break ;
case ” interactuable ”:
a n i = h i t . c o l l i d e r . gameObject . GetComponent<
Animator >() ;
s w i t c h ( h i t . c o l l i d e r . name )
{
c a s e ”SeguroVC ” :
i f ( f l a g == t r u e )
{
ani . SetBool (” i n t e r r u p t o r ” ,
false ) ;
flag = false ;
p r i n t ( ” todo apagado ” ) ;
}
else
{
ani . SetBool (” i n t e r r u p t o r ” , true
);
f l a g = true ;
p r i n t ( ” todo e n c e n d i d o ” ) ;
}
break ;
c a s e ”1 Palanca V3 / 2 ” :
a n i . S e t B o o l ( ”Go” , t r u e ) ;
S t a r t C o r o u t i n e ( Espera ( t r u e ) ) ;
// C i l i n d r o ( t r u e ) ;
break ;
c a s e ”2 Palanca V3 / 2 ” :
a n i . S e t B o o l ( ”Go” , t r u e ) ;
S t a r t C o r o u t i n e ( Espera ( f a l s e ) ) ;
// C i l i n d r o ( f a l s e ) ;
break ;
default :
p r i n t ( ”NO HAY NINGUN INTERRUPTOR” ) ;
break ;
}
break ;
default :
p r i n t ( ” Tag d e s c o n o c i d o ” ) ;
break ;
}
}
}
}
}
p u b l i c v o i d Timer Enter ( )
{
interaction = true ;
}
p u b l i c v o i d T i me r E xi t ( )
{
interaction = false ;
ReticleT . fillAmount = 0;
timCurrent = 0 ;
}
public int Verification ( int [ ] spaceSolution )
{
int i = 0;
i n t j = s p a c e S o l u t i o n . Length −1;
w h i l e ( i <s p a c e S o l u t i o n . Length )
{
i f ( c o n e x i o n e s [ s p a c e S o l u t i o n [ i ] , s p a c e S o l u t i o n [ j ] ] ==
c o n e x i o n e s [ s p a c e S o l u t i o n [ j ] , s p a c e S o l u t i o n [ i ] ] &&
c o n e x i o n e s [ s p a c e S o l u t i o n [ i ] , s p a c e S o l u t i o n [ j ] ] != ””&&
c o n e x i o n e s [ s p a c e S o l u t i o n [ j ] , s p a c e S o l u t i o n [ i ] ] != ””
&& ! c o n e x i o n e s [ s p a c e S o l u t i o n [ i ] , s p a c e S o l u t i o n [ j ] ] .
Contains (” ”)
&& ! c o n e x i o n e s [ s p a c e S o l u t i o n [ j ] , s p a c e S o l u t i o n [ i ] ] .
Contains (” ”) )
{
p r i n t ( c o n e x i o n e s [ s p a c e S o l u t i o n [ i ] , s p a c e S o l u t i o n [ j ] ] +”
y ”+ c o n e x i o n e s [ s p a c e S o l u t i o n [ j ] , s p a c e S o l u t i o n [ i ] ]
+”son i g u a l e s ” ) ;
return 1;
}
i ++;
j −−;
}
return 0;
}
p u b l i c v o i d phaseLab ( )
{
i f ( phase == 0 )
{
s t r i n g [ ] d i s a b l e = { ” conector ” , ” hose ” , ” i n t e r a c t u a b l e ” } ;
disableBoxColliders ( disable ) ;
}
e l s e i f ( phase == 1 )
{
string [ ] disable = { ” tools ”};
s t r i n g [ ] enable = { ” conector ” , ” hose ” } ;
enableBoxColliders ( enable ) ;
}
e l s e i f ( phase == 2 )
{
s t r i n g [ ] d i s a b l e = { ” conector ” , ” hose ” } ;
s t r i n g [ ] enable = { ” interactuable ” };
enableBoxColliders ( enable ) ;
}
}
public void Crear Matriz ( )

{
f o r ( i n t i = 0 ; i < 2 5 ; i ++)
{
f o r ( i n t j = 0 ; j < 2 5 ; j ++)
{
conexiones [ i , j ] = ””;
}
}
}
p u b l i c i n t numberTool ( s t r i n g nameTool )
{
int i = 0;
w h i l e ( nameTool != countManager . nameTool [ i ] )
{
i ++;
p r i n t ( countManager . nameTool [ i ] ) ;
}
return i ;
}
p u b l i c b o o l c o n e c t o r l i b r e ( s t r i n g e x t r e m o c a b l e , i n t pos )
{
i f ( c o n e x i o n e s [ pos , pos ] == ” ” )
{
c o n e x i o n e s [ pos , pos ] = e x t r e m o c a b l e ;
return true ;
}
return f a l s e ;
}
public int [ ] buscar par ( string extremo cable )
{
string extremo actual = extremo cable . S p l i t ( ’ ’ ) [ 0 ] ;
i n t [ ] c o n e c t o r e s = new i n t [ 2 ] ;
c o n e c t o r e s [ 0 ] = −1;
c o n e c t o r e s [ 1 ] = −1;
i n t aux = 0 ;
f o r ( i n t i = 0 ; i < 2 5 ; i ++)
{
i f ( c o n e x i o n e s [ i , i ] . S p l i t ( ’ ’ ) [ 0 ] == e x t r e m o a c t u a l )
{
c o n e c t o r e s [ aux ] = i ;
aux++;
}
}
return conectores ;
}
public void a s i g n a r i n s t r u m e n t o a l a m a t r i z ( i n t [ ] conectores , s t r i n g
cable )
{
f o r ( i n t i = 0 ; i < 2 5 ; i ++)
{
i f ( c o n e c t o r e s [ 0 ] == i | | c o n e c t o r e s [ 1 ] == i ) //
{
i f ( c o n e x i o n e s [ c o n e c t o r e s [ 0 ] , c o n e c t o r e s [ 1 ] ] == ”” &&
c o n e x i o n e s [ c o n e c t o r e s [ 0 ] , c o n e c t o r e s [ 1 ] ] == ” ” )
{
conexiones [ conectores [ 0 ] , conectores [ 1 ] ] = cable .
Split ( ’ ’) [ 0 ] ;
conexiones [ conectores [ 1 ] , conectores [ 0 ] ] = cable .
Split ( ’ ’) [ 0 ] ;
break ;
}
}
}
}
p u b l i c v o i d C l a s i f i c a d o r C R ( s t r i n g [ ] numero , i n t p o s i n s t r u m e n t o )
{
p r i n t ( ” Entre a l c o n e c t o r ”+ numero [ 2 ] +”de l a p i e z a ” + numero
[0]) ;
i f ( c o n e c t o r l i b r e ( h o s e . name , p o s i n s t r u m e n t o ) )
{
int negri ;
p r i n t(”=============================================”);
negri = pos instrumento ;
print ( negri ) ;
p r i n t ( ” e n t r e a l c o n e c t o r ”+ numero [ 2 ] + ” d e l i n s t r u m e n t o
e s t a l i b r e , conectando . . . ” ) ;
InterpolationManager . Instance . I n t e r p o l a t i o n ( h i t . point ,
h o s e ) ; / / r e c i e n i r a a su l u g a r
i n t [ ] c o n e c t o r e s = b u s c a r p a r ( h o s e . name ) ;
p r i n t ( ” l o s c o n e c t o r e s son : ” + c o n e c t o r e s [ 0 ] + ” , ” +
conectores [ 1 ] ) ;
i f ( c o n e c t o r e s [ 0 ] != −1 && c o n e c t o r e s [ 1 ] != −1)// s i ambos
c a b l e s e s t a n c o n e c t a d o s e s d e c i r guardados en l a m a t r i z
entran
{
p r i n t ( ” e l c a b l e e s t a c o n e c t a d o en ambas p a r t e s ” ) ;
a s i g n a r i n s t r u m e n t o a l a m a t r i z ( c o n e c t o r e s , h o s e . name ) ;
p r i n t ( ” Nueva c o n e x i o n en l a m a t r i z = ” + c o n e x i o n e s [
conectores [ 0 ] , conectores [ 1 ] ] ) ;
p r i n t ( ” Nueva c o n e x i o n en l a m a t r i z = ” + c o n e x i o n e s [
conectores [ 1 ] , conectores [ 0 ] ] ) ;
p r i n t(”==============================”);
// s o l u c i o n e s
i n t [ ] s o l = { 2 1 , 22 } ;
i n t [ ] s o l 2 = { 1 2 , 1 3 , 1 4 , 1 5 , 1 6 , 1 7 , 1 8 , 19 } ;
i f ( c o n e c t o r e s [ 0 ] == 7 && c o n e c t o r e s [ 1 ] == 2 3 ) puntos
++;
++;
++;
f o r ( i n t i = 0 ; i < s o l . Length ; i ++) i f ( c o n e c t o r e s [ 0 ]

== 3 && c o n e c t o r e s [ 1 ] == s o l [ i ] ) puntos++;
f o r ( i n t i = 0 ; i < s o l . Length ; i ++) i f ( c o n e c t o r e s [ 0 ]

== 6 && c o n e c t o r e s [ 1 ] == s o l [ i ] ) puntos++;
f o r ( i n t i = 0 ; i < s o l 2 . Length ; i ++) i f ( c o n e c t o r e s [ 0 ]

== s o l 2 [ i ] && c o n e c t o r e s [ 1 ] == 2 0 ) puntos++;

== 2 && c o n e c t o r e s [ 1 ] == s o l 2 [ i ] ) puntos++;
== 5 && c o n e c t o r e s [ 1 ] == s o l 2 [ i ] ) puntos++;
// s o l u c i o n e s
p r i n t(”==============================”);
p r i n t ( ” Tus puntos son ” + puntos ) ;

}
else
{
i f ( c o n e c t o r e s [ 0 ] == 9 && c o n e c t o r e s [ 1 ] == −1) puntos
++;
p r i n t(”==============================”);
p r i n t ( ” Tus puntos son ” + puntos ) ;
p r i n t ( ” s o l o un extremo e s t a c o n e c t a d o ” ) ;
}
}
}
public void enableBoxColliders ( s t r i n g [ ] enable )
{
s t r i n g [ ] tagsToEnable = e n a b l e ;
f o r e a c h ( s t r i n g t a g i n tagsToEnable )
{
GameObject [ ] gameObjects = GameObject .
FindGameObjectsWithTag ( t a g ) ;
f o r e a c h ( GameObject gameObj i n gameObjects )
{
gameObj . GetComponent() . e n a b l e d = t r u e ;
}
}
}
public void d i s a b l e B o x C o l l i d e r s ( s t r i n g [ ] d i s a b l e )
{
s t r i n g [ ] tagsToEnable = d i s a b l e ;
f o r e a c h ( s t r i n g t a g i n tagsToEnable )
{
GameObject [ ] gameObjects = GameObject .
FindGameObjectsWithTag ( t a g ) ;
f o r e a c h ( GameObject gameObj i n gameObjects )
{
gameObj . GetComponent() . e n a b l e d = f a l s e ;
}
}
}
}

IMT375 UCB Template Copy

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IMT375 UCB Template Copy

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD CATÓLICA BOLIVIANA “SAN PABLO”

UNIDAD ACADÉMICA REGIONAL LA PAZ

LABORATORIO DE REALIDAD VIRTUAL EDUCATIVO

Proyecto de grado presentado para la obtención del Grado de

Por: Amilkar Jhonny Massy Fernandez

Tutor: Ing. Diego César Calderón Iturricha

Relator: Ing. Freddy Fernando Ferrufino Gutierrez

Con todo mi corazón a mi papá Jhonny, mi

Gracias por ser parte de mi vida.

A Dios por su guı́a a lo largo de mi formación profesional.

El COVID-19 ha cambiado de forma global e instantánea la forma en la que se imparte

Lı́nea de investigación: E-learning – Entrenamiento con realidad virtual.

Research area: E-learning - Virtual reality training.

2-1. Paso a seguir en el proceso de fotolitografı́a . . . . . . . . . . . . . . . . . . . . . . . 7

3-1. Esquema general del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3-7. Modelo del laboratorio de la UCB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

1-1. Clasificación de los entornos experimentales . . . . . . . . . . . . . . . . . . . . . . . 1

2-1. Signo lectura esperada del giroscopio . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3-1. Elementos principales del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Tabla 1-1: Clasificación de los entornos experimentales 1 .

Actualmente el desarrollo de laboratorios virtuales cimentados en la realidad virtual continua [8],

1.2. Planteamiento del Problema

1.2.1. Definición del problema

1.3.2. Objetivos especı́ficos

• Diseñar el laboratorio virtual cimentado en los requerimientos y contenidos impartidos por

• Prototipar los componentes previamente analizados en el laboratorio de la UCB de forma

• Programar el entorno virtual en un motor grafico capaz de integrarse a múltiples plataformas

1.5. Lı́mites y Alcances

• El entorno se limitará a un laboratorio virtual con animaciones y modelado 3D.

• Se implementará el laboratorio para la plataforma Android que permite una inmersión 3D y

• El laboratorio virtual estará dirigido a los estudiantes y docentes de Ingenierı́a Mecatrónica

2.1. Estado del Arte

A) Towards an Immersive Guided Virtual Reality Microfabrication Laboratory

Figura 2-1: Paso a seguir en el proceso de fotolitografı́a

ciencias de la computación de la Universidad de Missouri continua y en el presente trabajan en

B) Utilizing virtual reality to assist students in learning physics

Figura 2-2: Avatar Albert Einstein, profesor del laboratorio virtual

C) Virtual reality as a tool in mechatronics education

Figura 2-3: Entorno de aprendizaje, componentes de la lavadora

D) Parabolix: Educational Simulation Game on Classical Mechanics Based on

El proyecto se ha desarrollado en el motor de juego unity3D con el lenguaje de programación C#,

Figura 2-4: Muestra de variables fı́sicas para el calculo

Figura 2-5: Entorno para el mantenimiento de un tablero eléctrico

F) STRIVR: Caso BMW

Figura 2-6: Simulación mantenimiento bajo un automovil.

G) Virtual Reality as good practice for teamwork with engineering students

Figura 2-7: Técnica Raycasting, para interacción con los objetos.

H) Uso didáctico de la realidad virtual inmersiva con interacción natural de

Figura 2-8: Menú de interacciones con reconocimiento kinect.

I) Desarrollo de una herramienta de apoyo para el estudio de la naturaleza de

Figura 2-9: Técnica Raycasting, para interacción con los objetos

J) Creación de una aplicación interactiva utilizando realidad virtual para plata-

Figura 2-10: Primer escenario puzzle.

K) Desarrollo de una aplicación para simular un vuelo con Realidad Virtual

Figura 2-11: Modelo y simulación de los controles del aeroplano ”Tucano”.

2.1.2. Cascos de realidad virtual

virtual obviando que el usuario es portador de un teléfono inteligente [22].

• Samsung Gear VR.

Figura 2-12: Casco de realidad virtual, VR Box.

• Sony PlayStation VR.

Figura 2-13: Casco de realidad virtual, HTC Vive.

los Microsoft HoloLens [26] en su salida al mercado, algunos ejemplares son:

Figura 2-14: Casco de realidad virtual, Microsoft HoloLens