RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 3 de 5)

Tras acabar con los primeros prototipos, nos dimos cuenta de que necesitábamos un diseño más profesional si queríamos capturar más y mejores datos para entrenar los algoritmos de Machine Learning que nos permitieran identificar a los usuarios, así que tuvimos que recurrir a profesionales del diseño y la impresión 3D, en este caso Moebyus Machines.

Figura 25: RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 3 de 5)

Como podéis ver, la impresión de las fichas fue bastante más profesional, y se pusieron pequeños imanes para conseguir que los movimientos fueran mucho más acoplados en cada uno de los giros, y no tuviera que preocuparse el usuario de terminar el movimiento correctamente.

Figura 26: Cubo de Rubik impreso por Moebyus Machines

Como se puede ver en el siguiente vídeo, este prototipo nos daba calidad suficiente para capturar datos de una manera robusta y fiable de cualquier persona que hubiera manejado un Cubo de Rubik alguna vez en su vida.


Figura 27: Captura de datos con prototipo final de Rubik
Sobre este prototipo pusimos las primeras pegatinas y comenzamos a tomar los primeros datos con diferentes usuarios para entrenar nuestros algoritmos de una manera más profesional. Con este cubo es con el que hicimos el paper que os voy a dejar publicado en la siguiente parte de este artículo.

Figura 28: Cubo de Rubik con pegatinas que usamos en las pruebas

Como podéis ver, el diseño final de Rubika tiene un manejo bastante fluido, con toda la electrónica dentro del dispositivo, que ahora vamos a contaros.

Electrónica de Rubika

Para construir la electrónica que necesitábamos, necesitábamos una placa central para construir todo el sistema que fuera lo suficientemente flexible como para añadir un módulo BlueTooth y un módulo de captura de movimientos en el espacio, para saber de qué manera se estaban movimiento las caras del cubo y el cubo en el espacio en si mismo.

Figura 29: Arquitecta de Rubika con un core Atmel Tiny1634,
un módulo BlueTooth LE nRF52 y una IMU GY-25

Los componentes elegidos fueron los que podéis ver en el esquema. Un micro Atmel Tiny1634R con un memoria Flash de 16kB, una EEPROM de 256b y un 1kB de SRAM que funciona a 8 MHz y con solo 18 pines de I/O. El consumo era importante, así que esta placa era perfecta por us poco consumo. Usa un sistema picoPower con valores entre 1.8v y 5.5v.

Figura 30: Esquema conexiones de placas utilizadas

El módulo de BlueTooth LE (Low Energy) que elegimos es el que HOLYIOT-17095 para poder enviar los datos que capturásemos de los movimientos de Rubika a la extensión del navegador para que ésta enviara toda la información al backend y poder hacer los cálculos del algoritmo.

IMU: Inclination Module Unit

Merece una parte importante hablar de cómo funcionan las IMU en este tipo de dispositivos hardware, ya que cada una ofrece un determinado número de Grados de Libertad (DoF: Degrees of Freedoom). Para poder medirlos, una IMU es un dispositivo capaz de medir la fuerza (aceleración) y la velocidad. No mide ángulos directamente y se requieren ciertos cálculos para obtenerlos. Esto nos permitiría saber cómo se mueve el Cubo de Rubik además de cómo se giran las caras, que también lo controlamos, por supuesto.

Figura 31: Control del giro de las caras

Una IMU de 6 DOF (Degrees Of Freedom) usa un acelerómetro de 3 ejes y giróscopo de 3 ejes para saber cómo está siendo manipulado el dispositivo. En el caso de tener 9 DOF, además de un acelerómetro de 3 ejes y giróscopo también de 3 ejes, se usa un magnetómetro (brújula digital) de 3 ejes. Además, se podría tener un hardware que añadiera hasta 10 DOF poniendo un barómetro para calcular la altura relativa al nivel del mar.

Figura 32: Giros en los ejes del cubo medidos por la IMU

Toda la información generada por los sensores que se utilicen - el acelerómetro, giróscopo, magentómetro y/o barómetro - se usa un DMP (Digital Motion Processor) que procesa los datos recibidos por todos ellos, minimiza los efectos de los errores inherentes a cada sensor y calcula los resultados del movimiento en términos de cuaterniones para convertir los resultados en ángulos de Euler. En nuestro caso, Rubika utiliza una IMU GY-25 con 6 DoF que nos permite calcular cómo se está moviendo cada una de las caras haciendo un poco de cálculos.

Figura 33: Prototipo de Rubika acabado con pegatinas finales y cargador de batería

Con esta electrónica, y haciendo todos los cálculos necesarios para saber cómo se estaba moviendo el cubo en cada uno de los tres ejes. Para ello, con cada trama de datos que consta de 8 bytes sabemos cómo está respecto a cada eje. Los 8 bytes se reparten con 1 byte de marca de inicio, 2 bytes (int16_t) para el ángulo del eje Z (Yaw), 2 bytes (int16_t) para el ángulo del eje Y (Pitch) y  2 bytes (int16_t) para el ángulo del eje X (Roll), además de 1 byte de marca final.

Figura 34: Probando el prototipo final con imanes en las caras

Con la electrónica lista, ya teníamos el cubo completado para terminarlo. Pusimos los imanes en las esquinas de las caras para que el movimiento fuera más fluido, le hicimos un cargador de batería y lo dejamos listo para utilizar en la captura de datos.

Cubo de Rubik Xiaomi Giiker 

Llegado este punto toca hablar del Giiker, un Cubo de Rubik con conexión BlueTooth LE lanzado por Xiaomi que apareció entre que nosotros comenzamos con la idea original allá por 2017, y cuando publicamos Rubika - hace un par de semanas -. Giiker apareció a finales 2018 para reconocer y enviar por BlueTooth LE los movimientos de las caras que se estaban realizando.

Figura 35: Xiaomi Giiker Rubik Cube

Con él apareció una cantidad de software, así que nosotros decidimos que nuestro Rubika - que tenía además acelerómetro y giróscopo como ya hemos explicado - sería compatible con Giiker, haciendo que los datos se codificaran de la misma forma y pudiéramos usar un cubo como Rubika o un Giiker para nuestras pruebas.

Así, cuando la resolución del Cubo de Rubik se hace con un Giiker, los datos que capturamos para el algoritmo de Machine Learning son:

• Separación temporal entre cada movimiento
• Media de separaciones temporales
• Tiempo de resolución de la secuencia
• Número de movimientos de la secuencia
• Porcentaje de giros para cada cara en la secuencia
• Sentido de giro para cada cara en la secuencia

Por otro lado, cuando la secuencia de resolución - o manipulación - del Cubo de Rubik se hace con Rubika, además de los datos anteriores, el algoritmo tiene en cuenta el Posicionamiento del Cubo. Y este posicionamiento se mide como la situación para los ejes - definida por sus valores de "guiñada", balanceo y cabeceo - durante toda la secuencia. Sobre esos datos se calcula:

• Desviación típica de las medias de cada eje
• Valor medio de las desviaciones típicas
• Valor medio de la velocidad angular

Esto nos va a permitir tener un mayor grado de fiabilidad a la hora de aplicar el algoritmo, ya que de cada movimiento tenemos muchos más datos de la persona que resuelve el cubo, gracias al acelerómetro y el giróscopo.

Y con todo esto, ya estamos listos para comenzar a trabajar en la captura de los datos y la generación de un algoritmo que nos permita utilizar una resolución de un Cubo de Rubik usando Rubika como si fuera un sistema de autenticación Anti Rubber Hose.

Saludos Malignos!

**************************************************************************************************
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 1 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 2 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 3 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 4 de 5)
- RUBIKA: Un sistema Anti-Rubber Hose basado en un cubo de Rubik (Parte 5 de 5)
**************************************************************************************************