viernes, 4 de septiembre de 2015

Introducción

El blog que aquí comienza muestra las conclusiones del proyecto de investigación Robot que Resuelve el Cubo de Rubik de 2x2x2 realizado en el Instituto de Enseñanza Secundaria Blas Infante de Córdoba entre marzo y junio de 2015.

El proyecto se realizó dentro del Programa Andalucía Profundiza. Este  programa consiste en "la realización de proyectos de investigación en los centros educativos en horario extraescolar. Estos proyectos se dirigen a la estimulación del aprendizaje y de la iniciativa en aquellos alumnos y alumnas que destacan por su interés y motivación hacia la realización de actividades que supongan una profundización con respecto al currículo ordinario".



El programa Andalucía Profundiza se dirige a alumnado de Primaria o de ESO y se desarrolla a lo largo de 8 sesiones de tres horas de duración cada una en horario de tarde. En el caso de nuestro proyecto, es evidente que se orientó a alumnado de segundo ciclo de ESO. Su impartición estuvo a cargo de profesorado del Departamento de Tecnología del IES mencionado.

Nuestro proyecto pretende, muy resumidamente, adaptar y programar un robot hecho con piezas de LEGO para resolver el cubo de Rubik de 2x2x2 (en lo sucesivo Rubik 23).





Como se comenta en la entrada correspondiente a  nuestro proyecto en el blog de Andalucía Profundiza, este "proyecto de investigación es innovador: si bien en internet podemos encontrar varios robots de esas características, su complejidad exige conocimientos de lenguajes de programación de alto nivel y de robótica propios de titulado universitario en Informática o en Ingeniería en Automatización. Por eso no es extraño que no se encuentren precedentes de alumnado de secundaria que haya creado y programado un robot para la resolución de un “cubo mágico”."

"No obstante, la elección de un cubo más simple (el Rubik 23 frente al clásico Rubik 33) y de un lenguaje de programación como el MindStorm permite que la dificultad del proyecto no exceda las posibilidades del alumnado de secundaria", y hace factible acometerlo dentro de las 24 horas del Andalucía Profundiza. O al menos intentarlo.

Este blog pretende ser una guía didáctica para profesores y alumnos mostrando las soluciones técnicas y los inconvenientes con los que se puede encontrar el desarrollo de prototipos "Rubik cube solvers" basados en los kits de robótica LEGO Mindstorm. Pero también dejando margen para la investigación y soluciones propias para quien quiera repetir la experiencia (en otras palabras: no lo doy todo hecho).

Quien quiera compartir sus conclusiones, detecte errores o encuentre soluciones técnicas alternativas, puede hacerlo en los "deja un comentario" de cada entrada. Si la aportación es interesante, se añadirá a la entrada relativa a las conclusiones y mejoras al final del blog. De igual manera, se pueden preguntar dudas que se irán respondiendo a medida que tenga un rato para ello.

miércoles, 8 de julio de 2015

Sesión 1: MindCuber y Tilted Twister

La combinación del cubo de Rubik y la robótica debió resultar irresistible para los matemáticos, ingenieros e informáticos que disfrutaron en su niñez del primero y estudiaron en su juventud la segunda. Han aparecido, incluso en las noticias del telediario, robots que llegan a resolverlo hasta en 3 segundos. Con los primeros kits de LEGO de robótica, internet se pobló de demostraciones de robots que resolvían no ya el clásico cubo de 3x3x3, sino también los cubos de  2x2x2, 4x4x4 y 5x5x5 y sus muchas otras variantes poliédricas.

Basta con escribir las palabras LEGO, RUBIK CUBE y SOLVER en el buscador de Google o en el de Youtube para encontrar multitud de robots que resuelven el cubo. Algunos son tan vistosos como los desarrollados por Copper Dragon, por ARM,  o por I'Asemble.

Pero nosotros nos hemos centrado en los MindCuber desarrollados por David Gilday  y en los Tilted Twister desarrollados por Hans Andersson. Muestran sus  creaciones con planos detallados de montaje y permiten descargar el código fuente del programa en C , así como el programa ya compilado. Además incluyen enlaces al lenguaje de programación (NXC), consejos, vídeos, consejos para solventar posibles problemas, FAQ, etc. Otra ventaja añadida es que se pueden construir estos robots a partir de uno o dos kits fácilmente localizables y no hay que disponer de un arsenal inmenso de piezas de LEGO.

En esta primera sesión, los alumnos de este proyecto de Andalucía Profundiza se constituyeron en cuatro equipos que construyeron cuatro dispositivos diferentes con la intención de que cada equipo aportara soluciones técnicas distintas a problemas similares.

El primer prototipo es el MindCuber for NXT 2.0. Está pensado para construirse a partir del LEGO Mindtorm NXT 2.0 Home Edition (o el de la caja grande azul de cartón). Ahora mismo está descatalogada. No obstante, puede montarse a partir de la versión educativa del Mindstorm NXT (cofre blanco de plástico) con la adición de un sensor de color y de la caja de ampliación para NXT (cofre azul de plástico) si perdonamos algunos elementos decorativos como las cejas del sensor de ultrasonidos.



El segundo prototopo es el Mindcuber for NXT 8527 or Education Base Set. Está pensado para construirse con la primera versión del NXT (la caja naranja de cartón que poca gente conoce en España) o con la versión Education Base Set que es la que hay en la mayoría de los Institutos de Secundaria de España. En ambos casos necesitará de la adición de un sensor de color. En el segundo caso, es necesario complementar con la caja de expansión para NXT.


Estas son las clásicas bandejas naranja y blanca de la Education Base Set



El tercer prototipo es el  Mincub3er for Lego Mindstorm EV3. Se puede montar a partir del Lego MindstormEV3 (home edition) o a partir del Lego Mindstorm EV3 Education Core Set (cofre de plástico negro), conjuntamente en este último caso con la caja de expansión (otro cofre de plástico negro). Hay que tener cuidado porque no es posible montar el prototipo primero (home) con la caja del segundo (education). Por eso hay dos planos de montaje distintos en la web Mindcuber. Esta confusión provocó un retraso irrecuperable para el equipo de trabajo de este prototipo. Como tampoco teníamos la caja de expansión para EV3 nos tuvimos que apañar con la homónima para NXT y con otras piezas que teníamos del concurso FLL, perdonando elementos puramente decorativos como el peinado punk del sensor de ultrasonidos. El resultado es que costó terminar de montarla el doble de tiempo que los otros prototipos Mindcuber.


El cuarto prototipo es el Tilted Twister 2.0. Se puede montar a partir del Mindstorm NXT 2.0 (home edition) o a partir del Mindstorm NXT Education Base Set con un sensor de color y la ayuda puntual de la caja de expansión del NXT (aunque de esto último no estoy muy seguro). Se monta mucho más rápidamente que los otros prototipos. De su funcionamiento ya hablaremos en la entrada correspondiente a la siguiente sesión.





martes, 7 de julio de 2015

Sesión 2: Ensayo de prototipos.

El primer prototipo terminado fue el Tilted Twister. Tras montarse y programarse se ensayó y funcionó aceptablemente. Empieza pidiéndote que pongas el cubo, el programa lo detecta gracias al sensor de ultrasonidos (que no tiene más utilidad que esa en este prototipo y en los demás) para, a continuación, empezar a leer los colores con el sensor de color. Para ello, voltea el cubo entero, ofreciendo al lector una cara distinta cada vez, utilizando también el giro de la bandeja que aloja el cubo. Tras terminar la lectura de colores emplea un algoritmo para calcular tres posibles soluciones (de unos 50-60 movimientos aproximadamente) y ejecutando la de menor número de movimientos.

Además de los dos sensores mencionados, el prototipo utiliza tres servomotores para, respectivamente, mover el brazo volteador/bloqueador, girar la bandeja que aloja el cubo y acercar/alejar el sensor de color.

El funcionamiento basado en la detección de la presencia del cubo, la lectura de los colores de sus caras, el cálculo de la secuencia de movimientos para la solución del cubo y la ejecución de esta secuencia es común para los cuatro prototipos montados.

Conviene aclarar el funcionamiento del brazo volteador/bloquedor:
  • El volteo consiste en, mediante un movimiento del brazo en un sentido y en el contrario, conseguir voltear el cubo entero 90º a la izquierda (según se mira con el brazo v/b a la izquierda y el sensor de color a la derecha); atención: el volteo del  Tilted Twister consiste en girar el cubo 90º a la derecha si se mira como se indicó antes.
  • El bloqueo consiste en bajar el brazo y sujetar las dos capas superiores del cubo para que, gracias al giro de la bandeja, hacer girar la capa inferior; a continuación, se desbloquea levantando el brazo.
Combinando volteos y bloqueos con giro en un sentido u otro de la capa inferior, conseguimos los clásicos movimientos del cubo F (girar la cara frontal 90º en el sentido de las agujas del reloj), F' (girar 90º la cara frontal en el sentido contrario al de las agujas del reloj), L y L' (para la cara izquierda), R, R', B, B', U, U', D, y D' (derecha, trasera, superior e inferior). Si queremos girar una capa intermedia, basta combinar dos de los anteriores (R y L', por ejemplo). Ya volveremos más adelante sobre estos movimientos y sobre su particularización para el robot que resuelve el cubo de Rubik de 2x2x2.

El caso es que el Tilted Twister fallaba con cierta frecuencia debido a un desfase en la posición original del brazo volteador/bloqueador que se iba acumulando hasta dar lugar a volteos y bloqueos disfuncionales. Esto llevó a retocar el código fuente y añadir un retraso de tres segundos tras cada volteo para corregir la posición del cubo manualmente, caso de que el volteo o elgiro de la capa inferior resultara fallido. Aparte de este inconveniente, iba como la seda. Este vídeo muestra el funcionamiento de nuestro prototipo con las "correcciones manuales" tras los volteos fallidos. Estas correcciones, indeseables si se desea que el robot lo haga todo solo sin ayuda exterior, se convirtieron en irrenunciables en lo sucesivo.


El siguiente en terminarse fue el MindCuber for NXT Education Base Set. Funcionó perfectamente una de las primeras veces (en unas condiciones de luz que no fuimos capaces de repetir) y el resto de las veces dio error en la lectura de los colores de las caras; quizá porque era un cubo como el que se ve en el vídeo anterior: de los blancos con los colores serigrafiados en vez del clásico negro con las pegatinas de color. Hicimos muchos intentos con las instrucciones que aporta David Gilday en su web para solucionar los problema de identificación de colores, pero no fructificaron. Ante la ausencia de tiempo para intentar retocar el código fuente y realizar la lectura de colores más pausadamente, lo dejamos correr. No obstante, os enlazamos un vídeo de David Gilday en el que se puede ver como trabaja comparativamente con la versión Home Edition.



Después se acabó el MindCuber for NXT 2.1 (Home Edition). El mal sabor de boca que dejó el prototipo anterior y la ausencia de tiempo (y de cubos clásicos negros con pegatinas para intentarlo), nos dejó con la duda de si hubiera funcionado o no. Aquí tenéis el vídeo que hizo David Gilday.



El MindCub3r for EV3 Education Core Set no se terminó hasta bien avanzada la tercera sesión. La idea de ensayarlo era impensable. Reconozco que buena parte de la culpa fue mía: se perdió mucho tiempo intentando hacerlo a partir de los planos que facilité para la versión Home Edition. No obstante, se puede ver qué tal funciona en este vídeo de su creador.


En el momento de redactar estas líneas (y con la perspectiva de la premura de tiempo que tuvimos para terminar el proyecto) dedicar una sesión a hacer funcionar los prototipos que resolvían el 3x3x3 fue un desperdicio de horas. Ver un prototipo ajeno ya programado resolver el Rubik 33 no era el objetivo de este proyecto Andalucía Profundiza; rediseñar el prototipo y programarlo para resolver el Rubik 23 sí lo era.

En realidad, el error fue montar los prototipos sin conocer los problemas que ofrecerían y cómo solucionarlos. Es una tarea que este profesor debe llevar ya hecha a la clase. Fue el primero de una serie de errores...




lunes, 6 de julio de 2015

Sesión 3: Adaptando del Rubik 3x3x3 al 2x2x2

Con los prototipos originales montados y ensayados (con menor o mayor éxito), acometimos la adaptación de éstos al cubo de Rubik 2x2x2. Este cubo tiene una arista de 5 cm frente a la del cubo original de Rubik 3x3x3 de 8 cm. Esta diferencia motivó un rediseño de los elementos funcionales del cubo (brazo volteador/bloqueador, bandeja giratoria y brazo del sensor de color) dando lugar a prototipos completamente diferentes.



Se salvó de la adaptación el Tilted Twister: como funcionaba aceptablemente bien, lo exhibimos en la Feria de Robótica y Tecnología Educativas que se celebró en la Escuela Politécnica de Málaga y en la Feria Expociencia del IES Blas Infante. A tenor de la cantidad de gente que se quedó 10 minutos viendo y grabando en vídeo cómo el robot resolvía el Rubik 3x3x3, cabe decir que llamó mucho la atención.


 
Volvamos a los otros prototipos Mindcuber's que estábamos adaptando: al rediseñar  la bandeja giratoria cuadrada que aloja el cubo, hay que tener cuidado de que el centro de rotación coincida con el centro geométrico de la bandeja. Esta precaución no se tuvo en cuenta en uno de los prototipos y dio lugar a un nuevo rediseño de la bandeja (más retrasos).

Aquí se muestra cómo quedó la bandeja giratoria del prototipo NXT Education Base Set.






Y aquí cómo quedó la bandeja giratoria del prototipo EV3 Education Core Set.




El brazo volteador/bloqueador también se tuvo que cambiar por completo y poner en su lugar otro más estrecho y sensiblemente más corto. Las barras articuladas que le sirven de guía y de apoyo también tuvieron que ser rediseñadas para la diferente altura a la que que el brazo tiene que tocar el cubo para voltearlo o sujetarlo.

Aquí se muestran los cambios hechos para el brazo v/b del prototipo NXT Education Base Set





Y aquí los cambios para el brazo v/b del  prototipo EV3.






Estas tareas de rediseño no terminaban nunca: cuando parecía funcionar bien, aparecían fallos durante la programación y ensayo que obligaban a desmontar estos elementos funcionales y a cambiarlos una vez y otra.

El cambio más radical aparece en el sensor de color: en vez de ser un solo sensor de color que lee toda la cara superior del cubo al moverse simultánea y coordinadamente con el giro de la bandeja, decidimos que fuera tres sensores mirando hacia abajo, hacia atrás y hacia la izquierda para leer de una sola vez las tres caras de la esquina superior delantera derecha del cubo (según se mira de frente el prototipo con el brazo v/b a la izquierda y el triple lector de colores a la derecha). Habida cuenta de cómo pensábamos hacer la programación de la resolución del cubo, este modo de lectura resultaba más operativo y más rápido. Este era el diseño original

 
 
 

No obstante, este lector triple y la articulación movida por servomotor necesitó de varios reformas cuando se descubrió que el sensor de color daba error si tocaba la superficie a leer (particularmente para los colores oscuros como el azul o el verde): había que separarlo por unos 3-5 mm. Esto se solucionó interponiendo algunas piezas a modo de topes. Además debía mirar al centro de la pegatina: si el borde de la pegatina estaba cerca de la zona de lectura, daba error.
Aquí se muestra cómo quedó la articulación con el servomotor y los tres sensores en el NXT Education Base Set.
 




 
Y aquí cómo quedó la articulación con el servomotor y los tres sensores en el EV3 Education Core Set.







En los brazos articulados aparecen otros sensores (de contacto, por ejemplo) que no  tienen más función que servir de contrapesos para que no sufra mucho el servomotor y para que no caiga demasiado rápido el sensor triple contra el cubo. En el momento de hacer las fotos del EV3 no están enchufados los cables de datos de los sensores de color.

No disponemos de fotos de la adaptación en el prototipo  NXT 2.1 (home edition) por razones que ya comentaremos más adelante.

Hablemos del elemento más importante: el cubo 2x2x2. Compramos tres cubos ShengShou que giran con muchas facilidad (son prácticamente profesionales) y tenían un tamaño standard. Una alegría fue ver que venían acompañados del siguiente prospecto.





Como podéis ver todos los que habláis chino mandarín (o un inglés dudoso), son instrucciones de cómo resolver el cubo. Son las que hemos seguido para crear el programa que resuelva el cubo. Ya hablaremos de esto más detenidamente.

Un pequeño inconveniente con el que nos encontramos fue que el lector de color no reconoce el color naranja; el negro, sí. En un primer momento solventamos el problema pintando las pegatinas con un rotulador marcador negro; pero se desprendía al poco por el rozamiento. Lo mismo con pintura acrílica negra. Finalmente optamos por arrancar las pegatinas dejando la superficie de plástico negro al descubierto. Y fue bastante bien.

domingo, 5 de julio de 2015

Sesión 4: Haciéndonos con la Programación en Mindstorm.

El aspecto más novedoso de nuestro robot, además del hecho de ser acometido por alumnado de Secundaria, es que se va a programar en lenguaje NXT 2.1 Programming (o en EV3 Programming en el prototipo para EV3). Se trata de un lenguaje asociado a eventos donde los comandos son bloques que se insertan en un circuito (que imita las barras Technics de Lego) de manera que se asemejen a la típica representación gráfica de los algoritmos. Los prototipos de los que partimos y lo demás que se ven en internet están programados en NXC, que es una versión del lenguaje de alto nivel C adaptada para programar el "brick" del Mindstorm. Es impensable enseñar a programar en C al alumnado de ESO en 24 horas de Andalucía Profundiza; y es más impensable que al alumnado le dé tiempo además a escribir el programa que resuelva el cubo: los códigos fuente utilizados en los prototipos originales tenían una extensión de 20 folios. No obstante, el programa en lenguaje Mindstorm sí tiene una dificultad y extensión apropiadas para el alumnado de Secundaria. Es frecuente que el alumnado de 4º de ESO haya trabajado con estos robotos en el área de Tecnología.

Quizá haya llegado el momento de hablar del "brick" de Lego Mindstorm. Se trata de un dispositivo electrónico digital que se puede programar desde el ordenador vía cable USB para, luego, funcionar independientemente. El ladrillo (o "brick") tiene cuatro puertos de entrada (1, 2, 3 y 4) a los que conectar los sensores del robot (de contacto, de sonido, de ultrasonido, de luz, de color, de temperatura, de infrarrojos...) y de tres puertos de salida (A, B y C, más un cuarto puerto D en el EV3) a los que se conectan los servomotores. El ladrillo incluye también varias teclas para su manejo y una pantalla y un altavoz para mandar información al exterior de acuerdo al programa en ejecución. En la foto que sigue se muestra a la izquierda el ladrillo EV3 (más moderno) y a la derecha el ladrillo NXT.


El primer paso en nuestra programación es conocer el bloque "motor". Permite manejar los tres servomotores que se encargan de mover el brazo volteador/bloqueador, rotar la bandeja giratoria y acercar/alejar la articulación del triple sensor de color. Los alumnos aprendieron cómo distinguirlos a partir del puerto al que están enchufados en el "brick" Mindstorm NXT. Y cómo hacerlos girar en un sentido u otro, con un ángulo de giro determinado y con una velocidad deseada. También era importante saber cómo hacerlos girar durante un tiempo o dándoles un giro sin frenazo final (con flotación).

Así, el bloque motor mostrado en la figura haría girar al motor que está en el puerto B 360º en sentido horario (según se mire), con una velocidad del 75% de la máxima y frenando al final del recorrido (ver la configuración del bloque en la parte inferior de la pantalla).


Comprobaron también en sus prototipos qué motores eran los que se encargaban de cada elemento funcional y de cómo tenían que configurar el bloque del servomotor correspondiente para girar la bandeja 90º a la derecha (motor A), acercar el triple sensor de colores a la esquina delantera superior derecha del cubo (motor B) o para bloquear la capa superior del cubo mientras se hacía girar la inferior hacia la izquierda (motor C).

A continuación aprendieron a manejar el sensor de color. Los que lo conocían de haber trabajado en la paleta común (bloques básicos del lenguaje Mindstorm) sabían que los bloques sensor (de color naranja) se podían utilizar a modo de barrera o espera: una acción se mantenía en el tiempo hasta que uno de los sensores recibían una información del exterior que permitían pasar al siguiente bloque en la secuencia. Pero los que nos interesan son los bloques sensor (de color amarillo) de la paleta completa (bloques avanzados del lenguaje Mindstorm). Éstos devuelven un valor numérico o lógico que puede ser útil para decidir la acción a tomar.

El sensor de color puede hacer muchas cosas, pero una de ellas es devolver un valor numérico dependiendo del color que esté leyendo. A continuación, las concordancias número-color del sensor:
  1. Negro
  2. Azul
  3. Verde
  4. Amarillo
  5. Rojo
  6. Blanco 
 Para ello hay que llevar un hilo (cuando es de datos numéricos, este hilo es de color amarillo) a la entrada de la bifurcación que se muestra. Las bifurcaciones suelen ser dobles: son el equivalente del comando "If...then...else" de cualquier lenguaje de programación. Estas bifurcaciones ofrecen dos "caminos" u opciones en función un dato o resultado recabado por el programa. Pero, si le conectamos un hilo de datos numérico, puede abandonar la vista plana y adoptar tantos "caminos" como queramos. Para ello, asignamos un valor numérico a cada "camino", del 1 al 6 en el ejemplo que se muestra a continuación, y dentro de ellos (a los que accedemos mediante la pestañita que se ve en la bifurcación) colocar la secuencia de bloques que queremos que ejecute en función del color que haya leído.


En el ejemplo arriba mostrado, si el lector de colores (que está conectado al puerto 1) detecta un color verde,  mandará un valor numérico "3" a la bifurcación que ejecutará la secuencia 3 (se ve la solapa seleccionada un poco más clara). Dentro de esta secuencia, emitirá un sonido, mostrará algo en la pantalla del ladrillo Mindstorm (el mensaje "verde" sería muy apropiado) y no hará nada más hasta pasados 5 segundos.


Otra bloque fundamental es el "bucle": en general, la ejecución de cualquier programa informático se basa en bifurcaciones y bucles. Estos últimos son repeticiones de una secuencia de bloques que se producen  hasta que se cumple una condición. Así pues, necesitan de un valor lógico para salir de él.


En el ejemplo arriba mostrado, el sensor de color (que está conectado al puerto 3) hace una lectura y manda el valor numérico obtenido a ser comparado con un valor definido en una constante (la maleta con el candado). Si el valor y la constante son iguales, se sale del bucle y aparece un dibujo en la pantalla del ladrillo. Si no lo son, se repite la lectura una vez por segundo (bloque espera o "retardo" con el dibujo del temporizador y el reloj de arena) hasta que valor y constante coinciden. Fijémonos en que el hilo de datos es de color verde al transmitir datos lógicos (1-0, verdadero-falso, sí-no, ...). No obstante, hay un fallo en el programa mostrado: la comparación debería haberse configurado para la opción "A igual a B" en vez de "A menor que B".

La paleta personalizada reúne los bloques que hemos bajado de internet y, lo más interesante, bloques que hemos creado nosotros combinando otros bloques de la paleta. Es el equivalente de las "macros" o "rutinas" y "subrutinas" de otros lenguajes. Esta paleta es fundamental en nuestro proyecto. Permite que el programa en desarrollo no alcance un tamaño descomunal que haga lento y lleno de errores su manejo. Por otro lado, que haya rutinas a las que recurramos constantemente y no tengamos que programarlas bloque a bloque es muy útil: sobre todo porque, si hay que corregir algo en estas rutinas, al hacerlo dentro del bloque personalizado ya vale para todas las veces que este bloque personalizado aparezca. Como veremos más adelante, todo nuestro programa se basa en bloques personalizados.


En la imagen superior se ve la paleta personalizada desplegada y parte del programa (22jun) que resuelve el cubo. Observamos también cómo este programa se basa casi exclusivamente en bloques de creación propia.

Ha llegado el momento de acceder al programa creado para este prototipo. Debe estar trufado de errores; pero no se trata tanto de bajarlo y ejecutarlo como de verlo y ver cómo se ha acometido esta programación simultáneamente a lo aprendido en este blog. Se puede descargar en este enlace.



Un vez descomprimido el fichero Rubik Infante copiamos y pegamos el fichero 22jun.rbt en la carpeta
Mis documentos / LEGO Creations / MINDSTORM Projects / Profiles / Predeterminado

Y los demás ficheros correspondientes a bloques de creación propia en
Mis documentos / LEGO Creations / MINDSTORM Projects / Profiles / Predeterminado / Blocks /Mis bloques

Partimos del supuesto de que tenemos el programa NXT 2.1 Programming, claro. Si no, no tenemos la aplicación necesaria en nuestro ordenador.

Hay muchos otros bloques interesantes, pero ya hablaremos de ellos a medida que vayan apareciendo en próximas entradas.

sábado, 4 de julio de 2015

Sesión 5: Creando nuestros Bloques


Ya dijimos en el punto anterior que, si convertimos rutinas frecuentes en bloques de creación propia, podremos acudir a ellos cada vez que las necesitemos sin necesidad de escribir la secuencia cada vez que aparezca. Otra enorme ventaja añadida es que reduce espectacularmente el tamaño del programa compilado: esto es fundamental en el ladrillo NXT donde la memoria para programas es de apenas unos 70 KB; el ladrillo EV3 no está tan limitado.

Empezamos a crear nuestros primeros bloques (se explica como crearlos en el tutorial que incluye el NXT 2.1 Programmin. Se accede a este tutorial con la barra Technics naranja que ve en la pantalla del programa arriba a la derecha). Combinando lo aprendido en el manejo de los servomotores, empezamos a crear unas secuencias básicas que inmediatamente convertimos en bloques de la paleta personalizada accesibles dentro de "Mis bloques". Aparecen, si abrimos el programa "22jun" , con nombres que aparecerán en lo sucesivo en cursiva, al igual que los nombres de variables. Estos bloques básicos son:
  • girar bandeja 90º a izquierda (Mesaizquierda)
  • girar bandeja 90º a derecha (Mesaderecha)
  • bloquear (Blokeo): sujetar la capa superior del cubo para poder rotar sólo la capa inferior.
  • desbloquear (Desblokeo): dejar de sujetar la capa superior del cubo, devolviendo el brazo v/b a la posición de reposo.
  • voltear (Volteo): volcar el cubo entero 90º a la izquierda con la ayuda del brazo v/b. Importante: si trabajamos con el prototipo Tilted Twister, como quiera que voltea hacia la derecha (si mantenemos el convenio de mirar frontalmente el prototipo con el brazo v/b a la izquierda y los sensores de color a la derecha), habría que rediseñar toda la propuesta de  los 12 bloques (B, B', F, F', etc) que se explica más abajo.
A estos añadimos los bloques
  • girar capa inferior 90º a la izquierda (planoinfizq)
  • girar capa inferior 90º a la derecha (planoinfder)
Estos dos bloques deberían programarse a partir de una combinación como la que sigue:

planoinfizq = Blokeo + Mesaizquierda+ Desblokeo

Pero, debido a la necesaria holgura de la bandeja respecto del cubo, la cara superior no se terminaba de quedar escuadrada con la capa inferior. Entonces, se optó por lo siguiente:

planoinfizq = Blokeo + girar bandeja a la izquierda 105º + Desblokeo +girar bandeja a la derecha 15º

Y lo mismo para planoinfder. Este escuadre no siempre se obtiene al 100%. Cuando el desfase de ángulo entre la cara superior e inferior alcanza un mínimo, suele provocar disfunciones  en el movimiento de volteo siguiente que obligan a hacer correcciones manualmente. En la última entrada del blog aportaremos ideas para corregir o minimizar los problemas detectados.

A continuación creamos otros 12 bloques que son los movimientos básicos para resolver nuestro cubo de Rubik de 2x2x2. Estos bloques son U, U', D, D', R, R', L, L', F, F', B y B'. En el dibujo adjunto se muestran 6 de estos movimientos. Los movimientos con la "comilla" son los mismos, pero en sentido contrario, esto es, en sentido antihorario si se mira la cara afectada frontalmente.


Estos movimientos se pueden programar y guardar como bloques personalizados como sigue:

D = planoinfder
D' =planoinfizq
L = Volteo + plainfder + Volteo + Volteo + Volteo

Estos tres  últimos volteos sirven para dejar el cubo con la orientación que tenía inicialmente; veremos, cuando sigamos generando secuencias, que es fundamental dejar siempre el cubo con la orientación que tenía inicialmente para que las secuencias basadas en los 12 movimientos no pierdan el sentido.

L' = Volteo + planoinfizq + Volteo + Volteo + Volteo
U = Volteo + Volteo + planoinfder + Volteo + Volteo
U' = Voleot + Volteo + planoinfizq + Volteo+ Volteo
R = Volteo + Volteo + Volteo + planoinfder + Volteo
R' = Volteo + Volteo + Volteo + planoinfizq + Volteo
F  = planoinfder + R + planoinfizq
F' = planoinfder + R'+ planoinfizq
B = planoinfizq +R + planoinfder
B' = planoinfizq +R' + planoinfder

Éste podría ser un buen momento para programar y ejecutar la secuencia siguiente con el prototipo y un cubo completado y comprobar si hemos hecho bien toda la programación de la sesión.



En este programa de prueba sería deseable que entre un movimiento y otro hubiera una pausa de 5 segundos y un pitido y/o un mensaje en pantalla que nos diera tiempo a asegurarnos de que se ha terminado correctamente cada movimiento básico.

Y ahora acometemos otro par de bloques personalizados: son Secuencia A y Secuencia B. Para comprender de qué hablamos, hay que adelantar que la resolución del cubo la basamos en tres etapas que se detallarán en próximas entradas: la primera es la resolución de la cara blanca (superior); la segunda es completar la cara amarilla (inferior) con sus cuatro vértices sin ordenar; y la tercera es la ordenación de esta cara amarilla. Pues bien, la secuencia A es la que permite, repitiéndola varias veces dependiendo del caso, hacer la segunda etapa. Y la secuencia B es la que permite resolver la tercera etapa, repitiéndola varias veces dependiendo del caso.

Secuencia A = R' + U' + F' + U + F + R
Secuencia B = L + F'+ L + B + B + L' + F + L + B + B + L + L


No serán los últimos bloques que creemos. Ya iremos describiéndolos a medida que aparezcan en las siguientes entradas.