Desarrollo de un sistema de realidad virtual para que los niños creen prototipos de objetos interactivos
febrero de 2021
Visión general
Smart Codesign VR es una plataforma prototipo para construir y probar «objetos inteligentes» interactivos en realidad virtual. Los jugadores eligen tres tarjetas, una de entorno, una de entrada y una de salida, y después utilizan movimientos físicos para definir cuándo responde el objeto y qué hace. Pueden colocar el objeto virtual terminado en un parque y probar su comportamiento.
El proyecto parte de SNaP (The Smart Nature Protagonists), un juego de mesa desarrollado por i3Lab en el Politecnico di Milano. En SNaP, los niños combinan tarjetas para inventar objetos inteligentes y los describen con una frase en papel. Este proyecto se propuso convertir esas descripciones en objetos virtuales que los niños pudieran construir y con los que pudieran interactuar mediante sus propios movimientos.
Nuestro equipo de cuatro personas diseñó e implementó el sistema como proyecto final de Advanced User Interfaces en el Politecnico di Milano durante el curso 2020–2021. Lo diseñamos para niños de entre 11 y 13 años, prestando especial atención a quienes tienen trastornos del neurodesarrollo (NDD, por sus siglas en inglés). Desarrollado en Unity y C# para Oculus Quest 2, el prototipo permite completar toda la secuencia, desde la selección de tarjetas hasta la interacción en el parque virtual.
SNaP y el contexto de diseño
Un juego que sitúa a los niños en el papel de diseñadores
En SNaP, entre dos y cuatro niños actúan como «diseñadores», mientras un facilitador adulto interpreta al «alcalde». El alcalde presenta una misión y los niños debaten ideas y combinan tarjetas para diseñar un objeto inteligente que la resuelva. El juego busca desarrollar la creatividad, la colaboración y la capacidad de expresar ideas. También se contempló su uso por niños con trastornos del neurodesarrollo, aunque este proyecto no evaluó efectos terapéuticos ni educativos.
Tres tipos de tarjeta: entorno, entrada y salida
SNaP tiene tres tipos de tarjeta, cada uno con una función distinta.
Las tarjetas de entorno representan el objeto que se hará inteligente: un árbol, un banco, un columpio, una masa de agua, una piedra, una farola, una papelera, una bicicleta, un puente, unas escaleras o una mochila escolar. Son objetos y elementos habituales de parques y calles. La tarjeta de entorno identifica el objeto que incorporará las funciones de entrada y salida.
Las tarjetas de entrada definen lo que el objeto detecta o aquello a lo que responde, como un botón, movimiento, contacto, distancia, temperatura, humedad, luminosidad, color, sonido, fuego, nivel del agua o una previsión meteorológica. Representan las entradas del objeto inteligente, de forma análoga a los sensores.
Las tarjetas de salida definen la respuesta del objeto: iluminarse, emitir un sonido, vibrar, moverse, mostrar, grabar o enviar información. Representan sus funciones de salida, de forma análoga a los actuadores.
La tarjeta de entorno da contexto a una pareja de entrada y salida. Si la entrada es movimiento y la salida es sonido, una papelera podría emitir un sonido cuando alguien no acierta al tirar algo, mientras que una farola podría anunciar que alguien se acerca. La entrada y la salida especifican cómo se comporta un dispositivo; añadir el entorno vincula ese comportamiento a una situación cotidiana.
Convertir ideas escritas en objetos virtuales interactivos
En el momento de este proyecto, una sesión de SNaP terminaba con una descripción escrita del objeto inteligente diseñado por los niños. En paralelo, i3Lab estaba desarrollando un «tablero físico» que combinaba una tableta con Arduino para convertir esas descripciones en prototipos físicos. Smart Codesign VR exploró otra vía mediante la realidad virtual, un medio que el equipo de investigación todavía no había estudiado para este fin.
La realidad virtual ofrecía dos oportunidades. En primer lugar, los niños podían crear prototipos con movimientos de todo el cuerpo: agarrar, transportar, iluminar y pintar con un pincel se convertían en formas de establecer condiciones y definir comportamientos. En segundo lugar, sus ideas podían adoptar una forma visible como objetos virtuales con los que interactuar de inmediato. Una descripción escrita podía convertirse en un objeto con tamaño y forma situado ante ellos.
Usuarios previstos
Los usuarios previstos eran niños de entre 11 y 13 años, con especial atención a quienes tienen trastornos del neurodesarrollo. Diseñar un objeto inteligente requiere cierto razonamiento lógico, por lo que tanto SNaP como su versión de realidad virtual se diseñaron para esa franja de edad.
El proyecto buscaba ayudar a los niños a expresar sus ideas mediante el prototipado práctico y la interacción. Eran objetivos de diseño, no resultados terapéuticos o educativos demostrados; el prototipo no se evaluó con niños.
Diseñar un espacio cómodo
A partir de los materiales consultados para el proyecto, utilizamos cuatro ámbitos para orientar el diseño espacial: sonido, luz y color, organización espacial y materiales. En cuanto al sonido, consideramos el aislamiento del ruido, el volumen regulable y un audio suave y uniforme para atender a las sensibilidades auditivas. En cuanto a la luz y el color, consideramos un fondo tranquilo y poco saturado, limitando los colores vivos y saturados a zonas pequeñas. También contemplamos límites espaciales claros, una disposición ordenada, formas sencillas y legibles y libertad de movimiento sin obstáculos. Un entorno virtual permite controlar estos aspectos. El proyecto no evaluó sus efectos sobre la comodidad de los usuarios.
Limitaciones y riesgos de la realidad virtual
El proyecto también consideró las limitaciones y los riesgos de la realidad virtual: coste del equipo, mareo, sobrecarga de cabeza y cuello por el peso del visor, accidentes al ocultar el visor el entorno físico, fatiga visual por uso prolongado y preocupación por la dependencia asociada a una inmersión excesiva.
Estas consideraciones orientaron tres decisiones de diseño: mantener interacciones sencillas con un reto suficiente para apoyar el aprendizaje; ofrecer imágenes y audio claros sin una estimulación excesiva; y dar a la experiencia un final definido. Una vez completados el prototipado y las pruebas en el parque, la actividad termina, en lugar de animar a permanecer indefinidamente en la realidad virtual.
El prototipo: experiencia e implementación
Cuatro etapas de la experiencia
La aplicación tiene cuatro etapas: pantalla de espera, selección de tarjetas, prototipado e interacción en el parque virtual.
1. Pantalla de espera
La aplicación se abre en una pantalla de título y espera a que se pulse un botón del mando para continuar. Esta pausa deliberada da al jugador tiempo para colocarse el visor y situarse antes de comenzar la experiencia principal.
2. Selección de tarjetas: agarrar y colocar
El jugador selecciona una tarjeta de entorno, una de entrada y una de salida agarrando el objeto correspondiente a cada tarjeta y colocándolo en la caja adecuada. Esta interacción de agarrar y colocar aprovecha el espacio tridimensional de la realidad virtual. Cuando las tres cajas están ocupadas, una indicación sonora guía al jugador a la etapa de prototipado. Las tarjetas pueden elegirse en cualquier orden, pero se necesitan las tres para continuar.
3. Prototipado: definir condiciones y comportamientos mediante el movimiento
El prototipado es el núcleo del sistema. Los jugadores definen la condición que activa la tarjeta de entrada elegida y la respuesta de la tarjeta de salida. Cada tarjeta tiene su propia interacción, con movimientos que requieren seguimiento de seis grados de libertad.
Por ejemplo, al seleccionar «previsión meteorológica», aparecen al alcance de la mano objetos que representan sol, nubes, lluvia, truenos y nieve. El jugador agarra uno y dirige su rayo al objeto de destino para establecer la condición. Si elige «iluminarse» como salida, toma un pincel, lo sumerge en un bote de pintura y pinta el objeto para elegir el color de su luz. Para borrar un color aplicado, sumerge el pincel en el bote de «agua» y vuelve a pasarlo por el objeto.
Una decisión clave de implementación fue admitir varias parejas de entrada y salida para un mismo objeto. El plan original permitía una sola regla, como «brillar en rojo cuando haga sol». Admitir varias parejas permitió que el objeto respondiera de distinta forma según las condiciones: rojo con sol, azul con lluvia y blanco con nieve. Los jugadores pueden probar cada pareja antes de confirmarla y volver a editarla si es necesario.
4. El parque: probar el objeto
Tras confirmar el objeto, el jugador entra en un parque virtual, lo coloca, activa la condición de entrada definida y observa su respuesta. Una celebración señala que el objeto ha funcionado correctamente y pone fin a la experiencia.
Flujo general
Los diagramas de actividad UML siguientes resumen la experiencia. El superior muestra el flujo general; los dos inferiores detallan las interacciones de «previsión meteorológica» e «iluminarse». Las bifurcaciones muestran cómo se puede volver a la selección de tarjetas tras recibir las instrucciones y a la edición después de confirmar y probar el objeto.
Traducción de las etiquetas y los recorridos del diagrama de actividad
Se conserva el diagrama histórico en inglés. «Overall Activity» corresponde al flujo general; «proceed» significa continuar, «re-edit» volver a editar y «finalize» finalizar.
- Flujo general. Pulsar el botón para salir de la pantalla de espera; seleccionar una tarjeta de entrada, una de entorno y una de salida; recibir las instrucciones del proceso de prototipado. Se puede cambiar la elección de tarjetas o continuar. Después se definen la condición de entrada y el comportamiento de salida, se confirma el objeto inteligente y se prueba su comportamiento. Desde la prueba se puede volver a editar o finalizar e interactuar con el objeto en el parque virtual.
- Definir la condición de entrada: tarjeta Weather (previsión meteorológica). Se agarra uno de los objetos y se dirige su rayo al objeto que se está configurando. Las correspondencias son: «sun» (sol) → «sunny» (soleado); «cloud» (nube) → «cloudy» (nublado); «raindrop» (gota de lluvia) → «rainy» (lluvioso); «lightning» (rayo) → «lightning» (relámpagos); «snowman» (muñeco de nieve) → «snowing» (nevando). A continuación se puede continuar o volver a editar la condición.
- Definir el comportamiento de salida: tarjeta Light Up (iluminarse). Se agarra el pincel y se sumerge en uno de los botes de pintura LED: «red» (rojo), «blue» (azul), «yellow» (amarillo) o «green» (verde). Se frota el pincel sobre el objeto inteligente para aplicar el color. «Add color» permite añadir color y «proceed» continuar. «Remove color» permite quitarlo: se sumerge el pincel en el bote «water» (agua), se frota sobre el objeto para borrar el color y se vuelve al punto de selección.
Equipo y herramientas
El prototipo se desarrolló para Oculus Quest 2. Su seguimiento de seis grados de libertad permite girar, desplazarse y manipular objetos virtuales. Como la interacción manual repetida era central en la experiencia, el equipo descartó los visores basados en teléfonos y limitados a un seguimiento de tres grados de libertad.
La aplicación se desarrolló en Unity y C#. El paquete Oculus Integration la conectó con Quest 2 y proporcionó las API para el comportamiento de la cámara de realidad virtual, el renderizado y la entrada de los mandos.
Cuatro escenas y 13 clases
El sistema utiliza cuatro escenas de Unity, una por cada etapa de la experiencia. Contiene 13 clases, incluidas tres abstractas.
La escena de título contiene una sola clase, TitleSceneCore, que pasa a la siguiente escena cuando el jugador pulsa un botón.
La escena de selección de tarjetas utiliza CardSelectionSceneCore y CardSelectionDetector. CardSelectionSceneCore crea tres instancias detectoras, una para cada caja de entorno, entrada y salida. Cada caja atrae un objeto de tarjeta cercano y marca su categoría como seleccionada. Cuando se completan las tres selecciones, la escena las escribe en la clase estática SmartObject y continúa. SmartObject conserva estos datos entre cambios de escena, conectando las cuatro escenas en una experiencia continua.
En la escena de prototipado, PrototypingSceneCore coordina el flujo de trabajo. El comportamiento de Card se representa mediante una jerarquía de herencia: Card es la clase base, InputCard y OutputCard derivan de ella, y clases concretas como Weather, Fire, MakeSound y LightUp implementan las interacciones individuales. Card, InputCard y OutputCard son abstractas porque solo las subclases concretas realizan operaciones de prototipado.
PrototypingSceneCore mantiene una lista de instancias de condiciones de entrada y otra de instancias de comportamientos de salida. Si las tarjetas elegidas son «previsión meteorológica» e «iluminarse», las listas contienen instancias de Weather y LightUp, respectivamente. Al inicio se crea una instancia de cada una; al pulsar el botón de añadir se crea otra pareja. En cada fotograma, el sistema evalúa las condiciones de entrada e invoca los comportamientos de salida correspondientes. Cuando el usuario confirma el objeto, isConfirmed pasa a ser verdadero y los datos del comportamiento construido se escriben en las propiedades estáticas de SmartObject.
La escena de interacción contiene una sola clase, InteractionSceneCore. Gestiona la colocación del objeto en el parque, las pruebas de las condiciones y respuestas definidas y la celebración final.
Smart Object», en la parte inferior central, conserva los datos entre escenas. Los atributos y métodos se simplifican para facilitar la lectura.Leyenda de las escenas y los identificadores del diagrama de clases
Los nombres originales se conservan como identificadores del diseño de software. «Title Scene» es la escena de título o pantalla de espera; «Card Selection Scene», la escena de selección de tarjetas; «Prototyping Scene», la escena de prototipado; e «Interaction Scene», la escena de interacción. Las cuatro corresponden a las etapas descritas en esta página.
«Smart Object» designa el objeto inteligente compartido entre escenas. «Card» es la clase abstracta de tarjeta; «Input Card» y «Output Card» son las tarjetas de entrada y salida. Las clases concretas «Weather Card», «Fire Card», «Make Sound Card» y «Light Up Card» corresponden a las tarjetas de previsión meteorológica, fuego, emisión de sonido e iluminación, respectivamente.
Código fuente:
github.com/takafumihoriuchi/SmartCodesignVR — Assets/myScripts
Resultados y trabajo pendiente
Nueve de las 49 tarjetas implementadas
El prototipo implementa nueve tarjetas. Sus funciones principales están operativas: selección de tarjetas, definición de condiciones y comportamientos, gestión de varias instancias y transferencia de datos entre escenas. Esto proporciona una base para añadir más tarjetas, aunque esa implementación sigue pendiente. Se diseñaron otras seis tarjetas sin llegar a implementarlas; las 34 restantes todavía requieren tanto el diseño de interacción como la implementación.
| Estado | Tarjetas |
|---|---|
| Implementadas (9) | Entorno: árbol, farola, señal de tráfico, papelera, puente Entrada: fuego, previsión meteorológica Salida: emitir sonido, iluminarse |
| Solo diseñadas (6) | Entrada: botón, velocidad, sonido Salida: moverse, vibrar, enviar |
| Sin iniciar (34) | 15 tarjetas de entorno, 16 de entrada y 3 de salida (mostrar, activar, grabar) |
No se realizó una evaluación con usuarios
El prototipo no se evaluó con usuarios. El desarrollo coincidió con la participación a distancia durante la pandemia de COVID-19. No fue posible organizar ni un taller presencial con visores de realidad virtual ni una alternativa remota. El proyecto demuestra que la experiencia diseñada puede implementarse como un prototipo funcional. Su usabilidad para los niños y su valor en un contexto terapéutico siguen sin comprobarse.
Una futura evaluación estudiaría hasta qué punto la interfaz resulta intuitiva para crear prototipos. Las posibles medidas incluyen el tiempo de realización, la correspondencia entre el objeto inteligente final y la idea inicial del participante, y el número de pulsaciones involuntarias de botones. Un cuestionario posterior basado en la System Usability Scale (SUS) aportaría datos cuantitativos adicionales. También se contemplaría grabar las sesiones para observar los movimientos de los participantes, con su consentimiento y los procedimientos adecuados. Para el proyecto de 2021 se propuso evaluar a niños de 13 años, buscando conciliar la franja de edad prevista para SNaP con las indicaciones de Oculus consultadas entonces. Cualquier estudio futuro tendría que revisar la elegibilidad según las indicaciones aplicables y el protocolo de investigación.
Trabajo futuro
La primera prioridad de desarrollo es mejorar la interfaz y la experiencia de usuario. Las limitaciones de tiempo y experiencia hicieron que la mayor parte del esfuerzo se dedicara a que funcionaran las combinaciones de tarjetas, dejando menos desarrollados los aspectos visuales, sonoros y hápticos. También debe reconsiderarse el papel del texto en realidad virtual: la información diseñada para una superficie plana puede presentarse mejor mediante una interfaz de usuario espacial (SUI). La interacción por voz es otra línea que conviene investigar para los usuarios previstos.
El proyecto identificó tres líneas de investigación. La primera es la comparación con el tablero físico que estaba desarrollando i3Lab. Un estudio previo observó más conversación cuando los participantes jugaban al mismo juego colaborativo en un entorno virtual que en uno físico, lo que sugiere una comparación útil entre ambas plataformas. La segunda es la participación simultánea de varios usuarios: en consonancia con el nombre «Codesign», los niños podrían construir objetos juntos en realidad virtual. La tercera es un formato normalizado para describir objetos inteligentes que permita transferir los diseños entre plataformas.
Síntesis
Este proyecto creó un entorno para desarrollar prototipos de objetos inteligentes. Transformó los tres tipos de tarjeta de SNaP en elementos de construcción: el objeto, sus condiciones de activación y sus comportamientos. Los jugadores los conectan agarrando, señalando y pintando. El prototipo funcional convierte una idea escrita en un objeto virtual interactivo, cuyo comportamiento se representa como datos que pueden transferirse entre escenas.
Takafumi Horiuchi, Paul Cozma-Ivan, Elmira Katsajeva y Olivia Ludkiewicz. «Design and Implementation of a Smart Object Prototyping Platform in Virtual Reality for Children with NDD». Proyecto de examen final de Advanced User Interfaces (curso 2020–2021), Politecnico di Milano, febrero de 2021.