Educación Secundaria

Publicado el 5 de octubre de 2015 | por JVicente

0

Robot que Resuelve el Cubo de Rubik de 2x2x2

Datos del Proyecto

Nombre del proyecto: Robot que Resuelve el Cubo de Rubik de 2x2x2
Centro (donde se desarrolla la experiencia): IES Blas Infante
Localidad y provincia: Córdoba (Córdoba)
Nombre del docente que coordina el proyecto: José Vicente Galadí García
Estudiantes a los que va dirigido (nivel(es)/curso(s)): Segundo ciclo de ESO.
Número de estudiantes: 20
Enlaces de interés vinculados con el proyecto:

Descripción de la Experiencia

El proyecto presentado consiste en adaptar y programar un robot hecho con piezas de LEGO para resolver el cubo de Rubik de 2x2x2.

Dijimos en la entrada anterior, que el proyecto era innovador y complejo, pero que se encontraba al alcance del alumnado. Ha resultado ser cierto, pero es bien cierto que el tiempo ha resultado muy corto habida cuenta de la cantidad de imponderables con que nos hemos topado en esta segunda mitad del proyecto: problemas de compilado, errores en la lectura de los colores del cubo, desfases de ángulos acumulados en servomotores, errores en el diseño de secuencias de movimientos, etc. El resultado es que, a fecha de hoy, los dos prototipos que no se han desmontado no terminan la resolución a causa de dificultades imprevistas. Estos problemas se están solucionando a partir de ratos que le dedica el alumnado participante voluntariamente en los días posteriores a la finalización del programa. No obstante, se ha demostrado la factibilidad del programar el robot que resuelve el Rubik 2x2x2 en lenguaje Mindstorm, un lenguaje al alcance del alumnado de secundaria.

En la sexta sesión, se repartió el trabajo por esquinas. Bueno, esto requiere de cierta aclaración. Ya se dijo en la entrada anterior que la resolución del cubo por parte del robot se plantea como los alumnos también la resuelven: en tres fases. Primero, se resuelve la cara blanca (fácil de hacer intuitivamente, pero tediosa de programar). Segundo, se forma la cara opuesta amarilla sin ordenar. Y, por último se ordena la cara amarilla. Pues bien, la primera fase (la resolución de la cara blanca) requiere del estudio de las siete esquinas del cubo una por una y de su inmediata colocación y orientación correcta (si es que tienen una cara blanca; en caso contrario se ignora y se pasa a estudiar la siguiente esquina). Decimos siete esquinas, porque al entregar el cubo al prototipo, se le ofrece siempre la primera esquina (la blanca-roja-azul) como referencia espacial y las otras siete las estudia en función de esta primera. Entonces, cuando decíamos que se repartió el trabajo por esquinas, quiero decir que cada alumno escribe las 8 ó 9 secuencias que tiene que hacer el prototipo para colocar una esquina con una cara blanca en su sitio. Esto tuvo cierta dificultad, particularmente para las cuatro esquinas inferiores. No así programarlo, que básicamente consistió en introducir las secuencias (insisto, diseñadas por el alumnado) de movimientos B, B’, F, F, D, etc., en el interior de 7 bifurcaciones con 9 ramificaciones. Se crearon también dos bloques nuevos, «girar esquina a la derecha» y «girar esquina a la izquierda» para recolocar correctamente esquinas bien situadas, pero mal orientadas.

En la séptima sesión, se comentó que se habían desmontado dos prototipos: el Tilted Twister daba demasiados problemas en el momento de voltear, y el MindCuber NXT Home Edition se descartó porque no disponíamos de los tres sensores de color necesarios: inicialmente se pensó en programarlo con sensores de luz y que evaluara niveles de grises; pero las premuras de tiempo lo hicieron imposible. Se ha seguido trabajando en la ejecución y depuración de los tres niveles de secuencias básicas y ensayando los sensores de color. Como ya sabíamos, estos sensores no leen el color naranja, obligándonos a repintar las pegatinas del cubo de color negro. Pero la pintura negra no agarra bien y se desprendía poco a poco. Solución: se arrancaron las pegatinas naranjas y se trabajó con el color negro del cuerpo. Otro problema asociado a los sensores de color es que dan fallos de identificación del color cuando están demasiado cerca de la pegatina, esto obligó a un rediseño completo del brazo con tres sensores de color. Aparte del tiempo dedicado a la corrección de pequeños problemas técnicos, se avanzó en la articulación de la Secuencia A, que es la secuencia de movimientos que consigue formar la cara amarilla desordenada. No basta con aplicarla tal cual, es necesario, según el caso, aplicarla varias veces, reorientando el cubo inicialmente y, a veces, reorientándolo entre una aplicación de la secuencia y la siguiente. Para ello es necesario identificar el estado inicial de la cara amarilla (ocho casos diferentes que en realidad son veintisiete: más información en el blog que estamos creando y que se enlaza sobre estas líneas). Pues eso, una rutina de identificación del caso basada en numeración en base 3 y una bifurcación con… 27 ramificaciones!!!

En la octava sesión, se articuló la secuencia B que es la que ordena la cara amarilla y el bloque «Tachán». Tampoco basta con ejecutar la secuencia B para ordenar la cara amarilla, de los seis casos posibles que nos encontramos tomando como referencia la esquina amarilla-azul-roja, tres de ellos necesitaban rutinas complejas con aplicaciones reiteradas de la secuencia y reorientaciones del cubo completo. Fue, pues, necesaria de una rutina de identificación del caso, no tan compleja como la de la sesión anterior y de una bifurcación triple con una bifurcación normal dentro de cada una de sus tres ramas. El bloque «Tachán» es el que, una vez ordenada la cara amarilla, la hace girar para que cuadre con la cara contraria, la blanca, terminando la resolución del cubo, un juego de niños en comparación con las tres fases de la resolución del cubo.

Si se abre el programa, éste es, casi íntegramente, bloques de creación propia, dicho de otra manera, si no recurrimos constantemente a subrutinas que a su vez llaman a otras subrutinas que a su vez llaman a otras subrutinas, el programa compilado no cabría en la limitadísima memoria del NXT Mindstorm. Esta estrategia ha dado numerosos errores de compilación pendientes de resolución en el momento de redactar estas líneas. No obstante, la compilación y ejecución de partes del programa aisladas no da demasiados problemas.

Actualmente, profesor y alumnado continúan trabajando, tras la finalización de las clases, en el perfeccionamiento de los dos prototipos (NXT y EV3) y en la creación del blog que cuente detallada y pedagógicamente la experiencia. Haciendo uso de la autocrítica, el proyecto es factible de terminarse en las 24 horas del Andalucía Profundiza, pero necesitará de una planificación más realista y con mayor conocimiento de las soluciones a las dificultades técnicas imprevistas encontradas este año.

Imagen de Shutterstock.

Tags: , , , ,


Sobre el colaborador



Deja un comentario

Volver arriba ↑