ROBOT PARA RESOLVER EL CUBO DE RUBIK RUBOK

ROBOT PARA RESOLVER EL CUBO DE RUBIK RUBOK

Trabajo de Fin de Grado

GRADO EN INGENIERÍA INFORMÁTICA

Julio de 2021

Autor

Miguel Rubio Arroyo

Tutores

Raúl Alves Santos

Jesús Fernando Rodríguez Aragón

1

D. Raúl Alves Santos, profesor del Departamento de Informática y Automática de la

Universidad de Salamanca

D. Jesús Fernando Rodríguez Aragón, profesor del Departamento de Informática y

Automática de la Universidad de Salamanca

Informan:

Que el trabajo titulado “Robot para resolver el cubo de Rubik - Rubok” ha sido realizado

por D. Miguel Rubio Arroyo, con DNI 70823869S y constituye la memoria del trabajo

realizado para la superación de la asignatura Trabajo Fin de Grado de la Titulación Grado

en Ingeniería Informática de esta Universidad.

Y para que así conste a todos los efectos oportunos.

En Salamanca, a 6 de julio de 2021

D. Raúl Alves Santos

Dpto. Informática y Automática


D. Jesús Fernando Rodríguez Aragón

Dpto. Informática y Automática


2

3

RESUMEN

Este documento contiene el proceso que se ha llevado a cabo para realizar el Trabajo de

Fin de Grado de Ingeniería Informática.

El objetivo de este proyecto es el desarrollo de un robot que sea capaz de resolver el

cubo de Rubik. La idea es que a partir de un cubo de Rubik mezclado (no resuelto) o bien

por una persona, o bien por el mismo robot, este último sea capaz de resolverlo en el

mínimo tiempo posible. Más adelante se detalla el método elegido para la resolución

del cubo, así como el modo de funcionamiento del robot.

La motivación para realizar este proyecto viene de dos de mis aficiones. La primera sería

el mundo de los cubos de Rubik y la segunda, la informática. Unir estas dos aficiones

resultó en la idea de desarrollar un robot sobre el que pudiese aplicar mis actuales

conocimientos en la resolución de cubos de Rubik, añadiendo las infinitas ventajas que

ofrece el mundo de la computación en cuanto a posibilidades de cálculo, velocidad y

planificación de movimientos.

El robot tendrá unos controles muy sencillos y no será necesario tener ningún

conocimiento técnico ni de resolución del cubo para que el usuario interactúe con las

funcionalidades que ofrece. Constará de una serie de botones que permitirán mezclar

el cubo, resolverlo y alguna función adicional que se comentará más adelante en la

memoria. Mediante unas cámaras el robot leerá el estado del cubo, posteriormente

calculará los movimientos necesarios para resolverlo y finalmente se los transmitirá a

los motores para que los apliquen sobre el cubo. El objetivo principal es que cualquier

persona pueda resolver el cubo pulsando un botón.

Palabras clave: Cubo de Rubik, robot, algoritmos, CFOP, Fridrich, Raspberry, motores,

cámaras.

4

5

SUMMARY

This document contains the process that has been carried out to develop the Final

Degree Project in Computer Engineering.

The objective of this project is the development of a robot that can solve the Rubik's

cube. The idea is that from a mixed Rubik's cube (not solved) either by a person, or by

the robot itself, the latter is able to solve it in the shortest possible time. The method

chosen to solve the cube will be detailed later, as well as the robot's operating mode.

The motivation to carry out this project comes from two of my hobbies, the first would

be the world of Rubik's cubes and the second, computing. Joining these two hobbies

resulted in the idea of developing a robot on which I could apply my current knowledge

in the resolution of Rubik's cubes, adding to it the infinite advantages that the world of

computing offers in terms of calculation, speed, and movement planning.

The robot will have very simple controls and it will not be necessary to have any technical

or resolution knowledge of the cube for the user to interact with the functionalities

offered by the robot. It will consist of a series of buttons that will allow you to mix the

cube, solve it and some additional function that will be discussed later. By means of

cameras the robot will read the state of the cube, later it will calculate the movements

necessary to solve it and finally it will transmit them to the motors so that they can apply

them on the cube. The main objective is that anyone can solve the cube by pressing a

button.

Keywords: Rubik's cube, robot, algorithms, CFOP, Fridrich, Raspberry, motors, cameras.

Rubok Miguel Rubio Arroyo

6

7

Tabla de contenidos 1. INTRODUCCIÓN ....................................................................................................... 15

1.1. EL CUBO DE RUBIK ........................................................................................... 15

1.2. MOTIVACIÓN Y FUNCIONAMIENTO DEL ROBOT ............................................. 16

2. OBJETIVOS DEL PROYECTO ...................................................................................... 19

2.1. OBJETIVOS TÉCNICOS ....................................................................................... 19

2.2. OBJETIVOS PERSONALES .................................................................................. 20

3. CONCEPTOS TEÓRICOS ............................................................................................ 21

3.1. GIROS ............................................................................................................... 24

3.2. NOTACION DE LAS PIEZAS ................................................................................ 26

3.3. SOLUCIÓN DEL CUBO ....................................................................................... 27

3.3.1. EL MÉTODO FRIDRICH .............................................................................. 30

3.3.2. MÉTODO FRIDRICH MEJORADO ............................................................... 31

4. HERRAMIENTAS SOFTWARE ................................................................................... 33

4.1. JAVA ................................................................................................................. 33

4.2. PYTHON ............................................................................................................ 35

4.3. OPENCV ............................................................................................................ 35

4.4. NETBEANS ........................................................................................................ 36

4.5. FRITZING........................................................................................................... 37

4.6. LUCIDCHART ..................................................................................................... 37

4.7. PAINT.NET ........................................................................................................ 38

4.8. INKSCAPE.......................................................................................................... 38

4.9. TINKERCAD ....................................................................................................... 39

4.10. MICROSOFT WORD ...................................................................................... 40

4.11. RASPBERRY PI OS .......................................................................................... 40

4.12. VNC VIEWER ................................................................................................. 40

5. ASPECTOS RELEVANTES DEL DESARROLLO ............................................................. 41

5.1. METODOLOGÍA ................................................................................................ 41

5.2. INICIO ............................................................................................................... 41

5.3. ANÁLISIS ........................................................................................................... 46

5.4. DISEÑO ............................................................................................................. 50

5.5. IMPLEMENTACIÓN SOFTWARE ........................................................................ 52

5.5.1. PRIMER ALGORITMO, CROSS .................................................................... 56


8

5.5.2. SEGUNDO ALGORITMO, F2L ..................................................................... 57

5.5.3. TERCER ALGORITMO, OLL ......................................................................... 61

5.5.4. CUARTO ALGORITMO, PLL ........................................................................ 65

5.5.5. QUINTO ALGORITMO, OPTIMIZAR MOVIMIENTOS ................................. 67

5.5.6. RESOLVER SOBRE TODAS LAS CARAS ....................................................... 69

5.5.7. GIROS DOBLES .......................................................................................... 70

5.5.8. ALGORITMO PATRÓN ............................................................................... 70

5.5.9. ALGORITMO MEZCLAR ............................................................................. 71

5.5.10. PRUEBAS ............................................................................................... 71

5.5.11. FICHEROS .............................................................................................. 73

5.5.12. SCRIPTS ................................................................................................. 75

5.6. ESTRUCTURA FÍSICA ......................................................................................... 78

5.6.1. CORTADORA LASER CNC ........................................................................... 80

5.6.2. METACRILATO Y MADERA ........................................................................ 85

5.7. HARDWARE Y COMPONENTES FÍSICOS ........................................................... 88

5.7.1. FUENTE DE ALIMENTACIÓN ..................................................................... 88

5.7.2. MODULO ADAPTADOR DE CORRIENTE ATX ............................................. 89

5.7.3. RASPBERRY PI ........................................................................................... 90

5.7.4. CÁMARAS USB .......................................................................................... 91

5.7.5. ALTAVOZ DE PC ......................................................................................... 92

5.7.6. NEMA 17 ................................................................................................... 93

5.7.7. ACOPLADOR NEMA 17 .............................................................................. 93

5.7.8. BARRAS ROSCADAS Y TUERCAS CUADRADAS .......................................... 94

5.7.9. POLOLU DRV8825 ..................................................................................... 94

5.7.10. CABLES, RESISTENCIAS, CONDENSADORES, LEDS, BOTONES ............... 95

5.7.11. PROTOBOARD ....................................................................................... 95

5.7.12. ENCABEZADOS APILABLES .................................................................... 96

5.7.13. TIRAS LED Y PERFILES ............................................................................ 97

5.7.14. CUBO DE RUBIK ..................................................................................... 98

5.8. CONEXIONES DE LA RASPBERRY ...................................................................... 99

5.8.1. CALIBRACIÓN DEL DRIVER ...................................................................... 103

5.9. RESULTADOS .................................................................................................. 105

6. PROYECTOS RELACIONADOS ................................................................................. 113

9

6.1. GAN ROBOT .................................................................................................... 113

6.2. SUB 1 RELOADED ........................................................................................... 114

6.3. LEGO CUBESTORMER 3 .................................................................................. 114

6.4. RUBOT II THE CUBINATOR ............................................................................. 115

7. CONCLUSIONES ..................................................................................................... 117

7.1. LÍNEAS FUTURAS DE TRABAJO ....................................................................... 118

8. BIBLIOGRAFÍA ........................................................................................................ 121

8.1. MANUALES, GUIAS Y CONSULTAS ................................................................. 121

8.2. SOFTWARE ..................................................................................................... 122

8.3. REFERENCIAS DE IMÁGENES .......................................................................... 123


10

11

ÍNDICE DE ILUSTRACIONES Ilustración 1. Variaciones del cubo ................................................................................. 15

Ilustración 2. Botones ..................................................................................................... 17

Ilustración 3. Notación caras .......................................................................................... 21

Ilustración 4. Notación cubo ........................................................................................... 21

Ilustración 5. Notación piezas......................................................................................... 22

Ilustración 6. Kernel ........................................................................................................ 22

Ilustración 7. Centro ....................................................................................................... 22

Ilustración 8. Arista ......................................................................................................... 22

Ilustración 9. Esquina ...................................................................................................... 23

Ilustración 10. Interior del cubo ..................................................................................... 23

Ilustración 11. Estados del cubo ..................................................................................... 24

Ilustración 12. Patrones .................................................................................................. 24

Ilustración 13. Notación giros 1 ...................................................................................... 24





Ilustración 18. Notación piezas 1 .................................................................................... 26

Ilustración 19. Notación piezas 2 .................................................................................... 27

Ilustración 20. Evolución Número de Dios ..................................................................... 28

Ilustración 21. Pasos método Fridrich ............................................................................ 31

Ilustración 22. Casos de uso y actores ............................................................................ 42

Ilustración 23. Factores de complejidad técnica ............................................................ 43

Ilustración 24. Factores de complejidad del entorno .................................................... 44

Ilustración 25. Estimación temporal ............................................................................... 45

Ilustración 26. Diagrama de Gantt.................................................................................. 46

Ilustración 27. Objetivos ................................................................................................. 47

Ilustración 28. Requisitos de información ...................................................................... 47

Ilustración 29. Diagrama de paquetes ............................................................................ 48

Ilustración 30. Caso de uso ............................................................................................. 48

Ilustración 31. Casos de uso ........................................................................................... 49

Ilustración 32. Diagrama de secuencia ........................................................................... 50

Ilustración 33. Diagrama de clases ................................................................................. 51

Ilustración 34. Gestión cubo ........................................................................................... 51

Ilustración 35. Diagrama de secuencia ........................................................................... 52

Ilustración 36. Orden de los cuadrados .......................................................................... 53

Ilustración 37. Código giro .............................................................................................. 54

Ilustración 38. Giro de aristas ......................................................................................... 55

Ilustración 39. Giro de esquinas ..................................................................................... 55

Ilustración 40. Vista desde consola ................................................................................ 56

Ilustración 41. Cruz ......................................................................................................... 57

Ilustración 42. Casos F2L ................................................................................................ 60

Ilustración 43. F2L ........................................................................................................... 60


12

Ilustración 44. Casos OLL ................................................................................................ 64

Ilustración 45. OLL .......................................................................................................... 65

Ilustración 46. Casos PLL ................................................................................................. 67

Ilustración 47. PLL ........................................................................................................... 67

Ilustración 48. 4 giros iguales ......................................................................................... 67

Ilustración 49. 3 giros iguales ......................................................................................... 68

Ilustración 50. Giros opuestos ........................................................................................ 68

Ilustración 51. 2 giros iguales y uno opuesto ................................................................. 69

Ilustración 52. CFOP sobre todas las caras ..................................................................... 70

Ilustración 53. Patrones .................................................................................................. 70

Ilustración 54. Cubo mezclado ....................................................................................... 71

Ilustración 55. Tiempo prueba PC .................................................................................. 72

Ilustración 56. Tiempo prueba Raspberry ...................................................................... 72

Ilustración 57. Log ........................................................................................................... 73

Ilustración 58. Fichero ejecución .................................................................................... 74

Ilustración 59. Fichero imágenes .................................................................................... 74

Ilustración 60. Documento ejecución ............................................................................. 75

Ilustración 61. Parámetros cámaras ............................................................................... 76

Ilustración 62. Vista de las cámaras ............................................................................... 77

Ilustración 63. Medición de los colores .......................................................................... 77

Ilustración 64. Parámetros extraídos del cubo............................................................... 78

Ilustración 65. Esquema software .................................................................................. 78

Ilustración 66. Estructura física ...................................................................................... 80

Ilustración 67. Máquina corte laser CNC ........................................................................ 80

Ilustración 68. Plano corte material opaco 1 ................................................................. 81


Ilustración 70. Plano corte material transparente 1 ...................................................... 83

Ilustración 71. Plano corte material transparente 2 ...................................................... 84


Ilustración 73. Parte superior ......................................................................................... 86

Ilustración 74. Parte inferior ........................................................................................... 86

Ilustración 75. Parte superior e inferior ......................................................................... 87

Ilustración 76. Boceto hardware .................................................................................... 88

Ilustración 77. Fuente de alimentación .......................................................................... 89

Ilustración 78. Adaptador de corriente ATX ................................................................... 89

Ilustración 79. Adaptador de 20 a 24 pines ATX ............................................................ 90

Ilustración 80. Raspberry Pi 3 modelo B+....................................................................... 91

Ilustración 81. Raspberry Pi 3 modelo B+ componentes ............................................... 91

Ilustración 82. Webcam USB .......................................................................................... 92

Ilustración 83. Altavoz PC ............................................................................................... 92

Ilustración 84. Nema 17 .................................................................................................. 93

Ilustración 85. Acopladores Nema 17 ............................................................................ 93

Ilustración 86. Barras, tuercas y soldadura .................................................................... 94

Ilustración 87. Barra roscada y tuerca ............................................................................ 94

13

Ilustración 88. DRV8825 ................................................................................................. 95

Ilustración 89. Componentes electrónicos ..................................................................... 95

Ilustración 90. Protoboard .............................................................................................. 96

Ilustración 91. Pines VMOT y GND ................................................................................. 96

Ilustración 92. Encabezados apilables ............................................................................ 96

Ilustración 93. DRV8825 con encabezados apilables ..................................................... 97

Ilustración 94. Leds ......................................................................................................... 98

Ilustración 95. Centros perforados ................................................................................. 98

Ilustración 96. Centros visibles y no visibles .................................................................. 99

Ilustración 97. Esquema hardware ............................................................................... 100

Ilustración 98. Componentes hardware ....................................................................... 100

Ilustración 99. Pines Raspberry Pi ................................................................................ 101

Ilustración 100. Conexiones DRV8825 .......................................................................... 102

Ilustración 101. Conexiones componentes .................................................................. 102

Ilustración 102. Potenciómetro DRV8825 .................................................................... 103

Ilustración 103. Configuración stepping DRV8825 ....................................................... 104

Ilustración 104. Imagen inicial mezclar ........................................................................ 106

Ilustración 105. Imagen final mezclar........................................................................... 107

Ilustración 106. Resultados mezclar ............................................................................. 107

Ilustración 107. Giros por segundo mezclar ................................................................. 107

Ilustración 108. Imagen inicial resolver ........................................................................ 108

Ilustración 109. Imagen final resolver .......................................................................... 108

Ilustración 110. Resultados resolver ............................................................................ 109

Ilustración 111. Giros por segundo resolver ................................................................ 109

Ilustración 112. Imagen inicial patrón .......................................................................... 109

Ilustración 113. Imagen final patrón ............................................................................ 110

Ilustración 114. Resultados patrón............................................................................... 110

Ilustración 115. Giros por segundo patrón ................................................................... 110

Ilustración 116. Robot GAN .......................................................................................... 113

Ilustración 117. Robot SUB 1 RELOADED ..................................................................... 114

Ilustración 118. Robot Lego Cubestormer 3 ................................................................. 115

Ilustración 119. Robot Rubot II ..................................................................................... 116


14

15

1. INTRODUCCIÓN

1.1. EL CUBO DE RUBIK

El cubo de Rubik es uno de los pocos rompecabezas que se ha mantenido como un

superventas pese a haber sido creado hace más de 40 años. Su aparente simplicidad,

pero gran dificultad a la hora de resolverlo, fue lo que lo convirtió en un éxito de masas.

No solo es el rompecabezas más vendido del mundo, también se considera el juguete

más vendido del mundo. Hasta enero de 2009 ya se habían vendido 350 millones de

cubos [1].

El cubo clásico consta de seis caras, cada una con 9 piezas de igual tamaño, y estas a su

vez poseen un color, siendo los colores tradicionales blanco, rojo, azul, naranja, verde y

amarillo. La estructura consiste en un mecanismo de ejes que permite a cada cara girar

independientemente, dando lugar a que se puedan mezclar las piezas. Este mecanismo

permite más de 43 trillones de permutaciones [2]. Se considera que el rompecabezas

está resuelto cuando en cada cara todas las piezas son del mismo color.

Actualmente existen múltiples variaciones, ya sea con diversos números de cuadrados

por cara, múltiples números de caras e incluso formas esféricas o piramidales.

Ilustración 1. Variaciones del cubo

El cubo fue inventado en 1974 por el escultor y profesor de arquitectura Ernő Rubik [3].

Su intención no era construir un rompecabezas, sino crear una herramienta de

enseñanza para ayudar a comprender el problema estructural de mover las partes de

un mecanismo de manera independiente sin que todo el mecanismo se desmoronara.

Fue cuando mezcló el cubo por primera vez y posteriormente trató de llevarlo a su

estado original cuando se dio cuenta de lo que tenía entre manos [4].

En 1975 patentaría el cubo en su país bajo el nombre cubo mágico. Dos años después

salieron a la venta los primeros ejemplares del cubo en jugueterías de Budapest. En

septiembre de 1979 el profesor firmó un acuerdo con Ideal Toy Company para vender

el cubo mágico a nivel mundial. A principios de 1980 haría su debut internacional en las


16

ferias de juguetes de Londres, París, Núremberg y Nueva York. El rompecabezas fue todo

un éxito a nivel internacional, y finalmente la compañía le asignó el nombre que todos

conocemos: el cubo de Rubik [5].

1.2. MOTIVACIÓN Y FUNCIONAMIENTO DEL ROBOT

Actualmente estamos viendo cómo día a día los robots son cada vez más complejos. Son

capaces de realizar desde tareas muy simples —como poner un tornillo— a otras mucho

más complejas —como realizar una cirugía con una precisión inigualable por un

humano—.

Las capacidades de los robots en cuanto a potencia de cálculo para prever todas las

situaciones posibles antes de actuar, su milimétrica precisión para llevar a cabo sus

propósitos, o incluso su tiempo de respuesta —que supera con creces a los reflejos de

un humano— hacen que desempeñen mejor muchas de las actividades que realizan el

común de los mortales.

Por otro lado, el cubo de Rubik sigue ganando aficionados y no parece que vaya a quedar

obsoleto. Sus ventas se mantienen a la par que siguen apareciendo nuevas

modificaciones y fabricantes. Al fin y al cabo, en casi todas las casas hay presente un

cubo que por lo general suele estar mezclado, ya que su propietario nunca fue capaz de

devolverlo a su estado original.

Una de las motivaciones para decidirme por este proyecto fue la asignatura Periféricos,

en la que aprendimos a manejar la plataforma Arduino, y vimos las múltiples

posibilidades que nos brindan estas placas de microcontrolador. Se pueden crear desde

proyectos domóticos a robots o máquinas de impresión 3D de una manera muy sencilla

y todo ello sin tener que gastar mucho dinero. Con una simple búsqueda en Internet, se

pueden encontrar centenares de proyectos creados y compartidos por otros usuarios.

Además, existen múltiples webs destinadas específicamente a este propósito de

colaboración entre la comunidad, donde los usuarios aportan sus proyectos, así como la

metodología, diseños o materiales que han usado para llevarlos a cabo.

Por todo lo anteriormente comentado, me surgió la idea de crear un robot que fuese

capaz de superarme a la hora de resolver un cubo de rubik (hecho que no resulta

demasiado difícil) tanto en velocidad a la hora de realizar los giros como en la eficiencia

de los giros escogidos para lograr la tarea.

Otra de las motivaciones fue crear un robot que pudiese ser replicado por cualquier

persona con unos conocimientos básicos de informática y electrónica. Por lo tanto, otro

de los objetivos es intentar mantener unos costes razonables y aprovechar al máximo

las posibilidades del hardware disponible para que las diferentes piezas se ajusten al

presupuesto planteado.

17

Para que el robot funcione habrá que conectarlo a una corriente de 230 V (voltaje común

en España). Una vez conectado, el robot estará listo para funcionar, y esperará a que se

le indique alguna orden. El modo de uso del robot es muy sencillo. Para operarlo,

dispondremos de 4 botones:

Botón mezclar

Se realizan una serie aleatoria de giros que mezclarán el cubo

Botón resolver

Se resuelve el cubo

Botón patrón

Si el cubo no está resuelto, lo resolverá y posteriormente aplicará un patrón elegido de manera aleatoria de una lista de patrones

Botón apagar

Apaga el robot

Ilustración 2. Botones


18

19

2. OBJETIVOS DEL PROYECTO

El objetivo principal del proyecto es desarrollar un robot que sea capaz de resolver el

cubo de rubik. Para ello, deberá ser capaz de leer el estado del cubo mediante

fotografías, calcular la mínima cantidad posible de giros para resolverlo y finalmente

aplicar estos giros a través de los motores que están acoplados a cada una de las caras

del cubo (un motor por cara, en total hay seis motores).

2.1. OBJETIVOS TÉCNICOS

- Entrada de datos: el robot deberá leer el estado del cubo por medio de dos

cámaras. Cada una será capaz de leer tres de las seis caras del cubo. Para ello

dichas cámaras se colocarán apuntando a dos vértices opuestos del cubo. Las dos

cámaras realizarán una fotografía cuando se les indique y se las proporcionará al

sistema para su tratamiento y el reconocimiento del cubo.

- Desarrollo de algoritmos de lectura de imágenes: para leer el estado del cubo a

partir de las imágenes proporcionadas por las cámaras, se utilizará una biblioteca

de visión artificial. Estos algoritmos deben tratar las imágenes obtenidas mediante

las cámaras de modo que extraigan el estado de cada una de las caras del cubo, sin

importar los colores que contengan dichas caras.

- Creación y controles del cubo: crear un software capaz de representar el estado

del cubo a partir del parámetro recibido, así como aplicar giros sobre las diferentes

caras.

- Desarrollo de algoritmo para mezclar el cubo: este algoritmo debe calcular una

serie de giros de manera aleatoria asegurando que el cubo quede mezclado.

- Desarrollo de algoritmos de resolución del cubo: estos algoritmos deben calcular

una serie de giros de forma eficiente de modo que al aplicarlos sobre el cubo pase

de estar mezclado a resuelto.

- Desarrollo de algoritmo de patrones: este algoritmo debe proporcionar una serie

de giros previamente definidos que permitan aplicar un patrón sobre el cubo.

- Desarrollo de algoritmo de giro de motores: este algoritmo deberá procesar los

giros que reciba como parámetro y asignárselos a los diferentes motores del robot,

asegurándose de que se ejecuten en el orden correcto e incluso permitiendo giros

de varios motores simultáneamente siempre que sea posible y no altere el proceso

de resolución del cubo.

- Desarrollo de hardware: elección de todos los componentes físicos que

participarán en el proceso, así como diseño de interconexiones entre los mismos.

Es decir, fuente de alimentación, motores, cámaras, SBC (Single Board Computer),

controladores, leds, cables, resistencias, condensadores, protoboard….

- Desarrollo de estructura física: creación de la estructura donde se albergarán

todos los componentes hardware. Esta estructura debe ser sólida y robusta tanto


20

para el correcto funcionamiento del robot como para su desplazamiento, y debe

permitir la visualización del cubo de rubik que se alberga en su interior. También

debe proporcionar algún tipo de iluminación que permita la correcta lectura del

estado del cubo independientemente de la luz que reciba del exterior.

2.2. OBJETIVOS PERSONALES

El desarrollo de este proyecto tiene como principal objetivo personal unificar mis

conocimientos en informática y en resolución de cubos de Rubik para crear un proyecto

físico que posea utilidad.

- Aplicar los diferentes conocimientos adquiridos a lo largo del grado.

- Tratar de crear un proyecto de manera autónoma.

- Emplear técnicas de visión artificial para leer los colores del cubo de rubik de cada

una de sus caras.

- Desarrollar algoritmos eficientes que aprovechen las ventajas brindadas por la

computación.

- Crear la circuitería necesaria para que los diferentes componentes del robot se

comuniquen e interaccionen de manera segura y eficiente.

- Crear un proyecto que pueda replicar cualquier persona con unos conocimientos

mínimos en informática y electrónica.

- Solucionar los diferentes problemas que vayan surgiendo durante el desarrollo del

proyecto: desde la implementación de los algoritmos hasta la correcta

sincronización de los movimientos de los motores pasando incluso por las posibles

limitaciones del hardware y software que puedan aparecer. Todo ello intentando

mantener unos costes razonables.

21

3. CONCEPTOS TEÓRICOS

A continuación, se presentarán algunos conceptos sobre el cubo de Rubik como la

notación utilizada y la forma de resolverlo que se ha implementado en el robot.

Se utilizará la notación Singmaster por ser la más ampliamente usada [6]. Como se ha

mencionado anteriormente, el cubo consta de seis caras: Cara U (Up), cara F (Front),

cara R (Right), cara D (Down), cara B (Back) y cara L (Left).

Ilustración 3. Notación caras

Para referirnos a determinadas partes del cubo podemos hablar de caras, cuadrados y

niveles.

Ilustración 4. Notación cubo

El tamaño estándar del cubo es de 57 milímetros en cada lado. Las piezas que componen

el cubo serían las esquinas, que están compuestas de tres colores; las aristas, de dos

colores; los centros, que tienen un único color; y el kernel o eje central. Cada pieza tiene

una combinación única de colores, por lo que no hay dos piezas iguales. Los centros

están fijados al eje central. Son las únicas piezas del cubo que no se pueden mover entre

las diferentes caras y, por lo tanto, indican el color de cada cara. Un cubo consta de ocho

esquinas, doce aristas, seis centros y el eje central. Es decir, un total de 27 piezas.


22

Ilustración 5. Notación piezas

Kernel

Ilustración 6. Kernel

Centro

Ilustración 7. Centro

Arista

Ilustración 8. Arista

23

Esquina

Ilustración 9. Esquina

Ilustración 10. Interior del cubo

Se considera que el rompecabezas está resuelto cuando en cada cara todas las piezas

son del mismo color. El cubo también puede estar mezclado o resuelto con un patrón.


24

Ilustración 11. Estados del cubo

Un patrón de Rubik es un estado alcanzado por una secuencia de giros desde alguna

configuración inicial (normalmente el estado resuelto). Se pueden distinguir fácilmente

por la simetría o las formas reconocibles que presentan. A continuación, se muestran

algunos ejemplos de patrones.

Ilustración 12. Patrones

3.1. GIROS

Para describir los diferentes giros del cubo se usan letras. De este modo el giro U

indicaría un giro en el sentido de las agujas del reloj de la cara U (Up), el giro F un giro

en el sentido de las agujas del reloj de la cara F (Front) y así sucesivamente. Si el giro va

acompañado de un apóstrofo o comilla simple, significa que el giro ha de realizarse en

el sentido opuesto a las agujas del reloj, de modo que el giro U’ indicaría un giro en el

sentido opuesto de las agujas del reloj de la cara U (Up).

Ilustración 13. Notación giros 1

25

También existe notación para giros que involucran al cubo completo. El giro X giraría el

cubo en el sentido de las agujas del reloj sobre el eje X, y el giro X’ lo haría en el sentido

opuesto de las agujas del reloj. De igual manera, el giro Y se haría sobre el eje Y y el giro

Z sobre el eje Z.


De igual modo, se asignan las letras M (Middle), E (Equator) y S (Standing) para referirse

a giros sobre los niveles intermedios del cubo. Estos giros serían lo mismo que realizar

un giro sobre dos caras opuestas, uno en sentido horario y el otro en sentido antihorario,

y posteriormente realizar una rotación del cubo.


También se pueden realizar giros que involucren a dos niveles, que reciben la misma

notación que las rotaciones de una cara, pero en minúscula. Estos giros serían lo mismo

que girar una cara y posteriormente realizar una rotación del cubo.


Por último, se puede indicar un giro de 180 grados. O lo que es lo mismo, dos giros de

90 grados seguidos, añadiendo el número dos después de la letra que indica el giro. Cabe

destacar que un giro de 180 grados U2 sería lo mismo que realizar un giro U’2, puesto

que el cubo acabaría en el mismo estado. No tiene sentido realizar giros de más de 180

grados, como por ejemplo el giro U3 de 270 grados, ya que esto sería lo mismo que


26

realizar el giro U’, con la diferencia de tener que realizar tres giros de 90 grados frente a

un único giro, por lo que solo se realizarán giros de 90 o 180 grados. Un giro de 360

grados dejaría el cubo en el mismo estado en el que se encontraba antes de realizar el

giro.


3.2. NOTACION DE LAS PIEZAS

Anteriormente se nombraron las tres piezas que forman el cubo: centros, aristas y

esquinas. Las únicas piezas que pertenecen solamente a una cara, y por lo tanto tiene

un único color, serían los centros. Mientras tanto, las aristas pertenecen a dos caras, por

lo que se componen de dos colores, y las esquinas, a tres caras y se componen de tres

colores.

Para identificar cada pieza del cubo, se le asignan las letras que identifican a las caras a

las que pertenece esa pieza. Por ello, los centros se nombrarían con una única letra, las

aristas con dos letras y las esquinas con tres letras.

Ilustración 18. Notación piezas 1

27

Ilustración 19. Notación piezas 2

3.3. SOLUCIÓN DEL CUBO

Existe una gran variedad de métodos para resolver el cubo. Todos ellos presentan

diferentes niveles de dificultad y cada uno tiene sus ventajas e inconvenientes. Hay

métodos pensados para realizar speedcubing, métodos con un número muy bajo o alto

de algoritmos, o incluso métodos para resolver el cubo a ciegas. El método más común

para iniciarse en el proceso de resolver el cubo sería el método principiantes, que consta

de siete pasos.

La decisión de qué método escoger para llevar a cabo el proyecto no es sencilla. Lo ideal

sería recurrir a algoritmos de búsqueda como podría ser el algoritmo A estrella que nos

devolvería siempre la solución óptima (aquella con menos cantidad de giros), la cual se

ha demostrado que conlleva menos de 20 movimientos en cualquiera de los casos

posibles.

Se conoce como número de Dios (God’s number) al número máximo de movimientos

requeridos para resolver cualquiera de las 43.252.003.274.489.856.000 combinaciones

del cubo de rubik [7]. Esta cifra ha ido variando a lo largo del tiempo. En 1981 se estimó

que el número de movimientos necesarios eran 52, y se fue reduciendo hasta 22 en

2008. Sin embargo, el profesor matemático David Breyer Singmaster tenía la teoría de

que esta cifra se podía reducir hasta 20 movimientos. Fue en 2010 cuando un grupo de

investigadores utilizó una enorme cantidad de potencia de cómputo proporcionada por

Google para demostrar que la teoría de Singmaster era cierta: el número de Dios es 20.

Para ello se examinaron todas las posiciones posibles del cubo de rubik, las cuales

pasaban de ser más de 43 trillones a solo 55.882.296, ya que la gran mayoría de

posiciones eran matemáticamente equivalentes por cuestiones de simetría y cobertura

de conjuntos. A partir de todas estas configuraciones, buscaron todas las soluciones

posibles, descartando aquellas que excedían los 20 movimientos. En total necesitaron

35 años de CPU, siendo un año de CPU la cantidad de trabajo de cómputo realizado por

una máquina de un GFLOP en un año de servicio dedicado (8.760 horas).

En el siguiente gráfico se puede ver cómo ha evolucionado este número de Dios:


28

Ilustración 20. Evolución Número de Dios

Aquel algoritmo que solucione el cubo en el menor número de giros posibles es conocido

como el algoritmo de Dios. Este algoritmo siempre devolverá un número de giros menor

o igual que el número de Dios.

Teniendo en cuenta lo comentado, lo ideal sería utilizar algún algoritmo como el A

estrella, o incluso los algoritmos Kociemba o Korf que se basan en el algoritmo IDA*

(Iterative Deepening A*). Sin embargo, esta estrategia queda descartada por los

desmesurados tiempos que se requieren para encontrar la solución o la dificultad que

conlleva comprender dichos métodos.

Para este trabajo, se han desarrollado múltiples implementaciones de estos algoritmos.

Incluso se ha dividido el proceso de resolución y se han aplicado estos algoritmos a cada

etapa del procedimiento para encontrar la secuencia de movimientos necesaria, lo que

reduce exponencialmente la cantidad de estados a explorar, con el consecuente

aumento de movimientos en la solución obtenida. Pero aun siguiendo todos estos pasos,

los tiempos siguen siendo enormes, por lo que se descartó esta posibilidad.

Se han explorado tanto estrategias de búsqueda en amplitud como en profundidad. En

las estrategias de búsqueda en amplitud, se tardaba mucho tiempo en hallar la solución,

pudiendo llegar a tardar varias horas, aunque el número de giros obtenidos era el mismo

que el que se obtendría con el algoritmo de Dios o un poco superior dependiendo de la

implementación. Sin embargo, con las estrategias de búsqueda en profundidad sí que

se obtuvieron tiempos asequibles, pero el número de giros obtenidos estaba lejos de ser

un resultado eficiente.

El problema de la gran cantidad de tiempo que se tarda en obtener la solución en las

estrategias de búsqueda en amplitud se podría mitigar con el uso de herramientas

18 18 18 18 18 20 20 20 20 20 20 20

20

52

4239 37

29 29 28 27 26 25 23 22

20

jul-

81

dic

-90

may

-92

may

-92

ene-

95

ene-

95

dic

-05

abr-

06

may

-07

mar

-08

abr-

08

ago

-08

jul-

10

Número de Dios

Limite inferior Limite superior

29

hardware de cálculo intensivo. Por ejemplo, el uso de tarjetas gráficas. Pero este hecho

anularía el objetivo de que el proyecto se ajuste a un presupuesto asequible por el alto

coste de dichos componentes hardware.

Una vez descartadas las técnicas de búsqueda anteriores, decidí optar por usar

algoritmos propios de resolución del cubo. Existen multitud de métodos, cada uno con

sus ventajas e inconvenientes para el humano que lo resuelve. Pero dichas ventajas e

inconvenientes cambian radicalmente cuando el que lo va a resolver es un computador,

ya que por ejemplo un computador podría almacenar un número ilimitado de algoritmos

y explorar las posibles soluciones completas sin necesidad de realizar ningún giro.

Los métodos más usados para la resolución del cubo serían CFOP, Petrus, Roux, ZZ y

Waterman. Los métodos CFOP, Roux y ZZ son conocidos como los “Big 3” ya que son los

3 métodos más populares y con mejores resultados en cuanto a tiempos y número de

giros [8].

El método Roux fue inventado por el speedcuber francés Gilles Roux. Este método está

basado en el Blockbuilding (construcción de bloques) y Corners First (esquinas primero).

Destaca por su bajo número de movimientos y la falta de rotaciones, lo que lo hace muy

útil para la resolución con una sola mano.

El método ZZ fue inventado por el polaco Zbigniew Zborowski. Su objetivo era obtener

un bajo número de movimientos y gran velocidad en los giros realizados. Para resolver

los dos primeros niveles del cubo mediante este método, solo se realizan giros L, U y R,

lo que permite que no haya que estar desplazando las manos o girando el cubo para

aplicar los distintos movimientos, posibilitando al usuario una gran velocidad en los

giros.

Los métodos descritos anteriormente contienen menos algoritmos que el método CFOP,

y son más intuitivos. Por ello, resultan más sencillos de aprender para el humano,

aunque para el computador estos factores son irrelevantes. En cuanto a la ventaja que

ofrece el método ZZ de gran velocidad de los giros, tampoco es un factor a tener en

cuenta para el computador, ya que va a realizar todos los giros a la misma velocidad

independientemente de la cara sobre la que haya que realizarlos.

Finalmente, escogí el método Fridrich (también conocido como CFOP), el cual es

considerado actualmente como el mejor método para speedcubing. La gran mayoría de

los récords mundiales han sido conseguidos mediante el uso de este método.


30

3.3.1. EL MÉTODO FRIDRICH

El método Fridrich fue publicado por Jessica Fridrich en 1997. Se basa en dividir el cubo

en capas, de modo que se debe resolver cada capa utilizando algoritmos en cada paso,

conservando las piezas que se han colocado en los pasos anteriores. Este método

también se denomina CFOP debido a los 4 pasos en los que se subdivide el proceso.

- C: Cross / Cruz.

- F2L: First Two Layers / Primeras dos capas.

- OLL: Orientation of the Last Layer / Orientación de la última capa.

- PLL: Permutation of the Last Layer / Permutación de la última capa

Este método implica la memorización de un gran número de algoritmos (119),

ofreciendo como resultado unos tiempos y un número de movimientos más que

aceptables para las capacidades de resolución humanas. Existen versiones reducidas de

este método que requieren la memorización de muchos menos algoritmos con la

desventaja de obtener una menor eficiencia en cuanto al número de movimientos. Sin

embargo, no nos interesa barajar esta posibilidad ya que una de las ventajas que nos

brinda la computación es que podemos almacenar todos los algoritmos que deseemos.

- Cross: No hay algoritmos predefinidos. El hecho de obtener un buen resultado en

este paso depende totalmente de la destreza del usuario o, en este caso, de la

eficiencia de los algoritmos desarrollados para resolver este paso. El objetivo de este

paso es formar una cruz en el nivel inferior o base del cubo. Se considera que se ha

completado este paso cuando están en la base las cuatro aristas que tienen el color

del centro del nivel inferior, y además el segundo color de estas coincide con las

piezas centrales de las caras de alrededor.

- F2L: Este segundo paso se compone de 42 posibilidades si contamos el caso en el

que la esquina y arista se encuentran en su posición correcta, por lo que se puede

resolver mediante 41 algoritmos que hay que aplicar una vez sobre las 4 esquinas

del nivel inferior del cubo. El objetivo de este paso es conseguir que queden los

niveles inferior e intermedio del cubo resueltos.

- OLL: El tercer paso presenta 58 posibilidades si incluimos el caso en el que ya está

orientado el nivel superior, por lo que hay 57 algoritmos posibles para completarlo.

Este paso está realizado cuando las 4 aristas y 4 esquinas que tienen el color del

centro del nivel superior están posicionadas de modo que dicho color se encuentre

en el nivel superior.

- PLL: El cuarto y último paso ofrece 22 posibilidades si incluimos el caso en el que el

cubo ya se encuentra totalmente resuelto, por lo que hay 21 algoritmos posibles

para completarlo. Este paso se acaba cuando el cubo queda completamente

resuelto.

31

Ilustración 21. Pasos método Fridrich

3.3.2. MÉTODO FRIDRICH MEJORADO

El método Fridrich original se puede mejorar aprovechando las posibilidades que ofrece

la computación. Mientras que una persona elegiría el algoritmo que debe aplicar en

función del estado del cubo según resuelve las diferentes etapas CFOP, una máquina

podría calcular la secuencia de pasos completa y posteriormente procesar todos los

movimientos obtenidos durante las 4 fases CFOP para eliminar los giros redundantes u

optimizar la solución.

Una vez calculados todos los giros necesarios para resolver el cubo, se aplicará un

algoritmo de eliminación de movimientos redundantes. Este algoritmo se ejecutará

muchas veces hasta que no se pueda mejorar más la solución.

El algoritmo examinará todos los movimientos que se han calculado aplicando las

siguientes reglas en el orden que se muestra a continuación:

- 4 giros iguales consecutivos se eliminan. Por ejemplo, si en la secuencia de

movimientos se diesen 4 giros U de 90 grados seguidos, sería lo mismo que realizar

un giro de 360 grados sobre U. Como se mencionó anteriormente, un giro de 360

grados dejaría el cubo en el mismo estado, por lo que se pueden eliminar sin que

esto afecte a la solución.

- 3 giros iguales consecutivos se sustituyen por un giro en el sentido inverso. Por

ejemplo, si en la solución se encuentran 3 giros seguidos U, se traduciría en realizar

un giro U de 270 grados, que sería lo mismo que realizar un giro de 90 grados en el

sentido opuesto. Es decir, los 3 giros producirían el mismo efecto que realizar un giro

U’.


32

- Un giro seguido de su giro opuesto se elimina. Por ejemplo, si la solución contiene

un giro U seguido de un giro U’, se pueden eliminar ambos giros puesto que el estado

del cubo es el mismo antes y después de realizar estos giros.

33

4. HERRAMIENTAS SOFTWARE

4.1. JAVA

Versión: Java SE Development Kit 8

Se trata de un lenguaje de programación desarrollado por Sun Microsystems y que

actualmente está presente en una gran cantidad de aplicaciones, sitios web, centros de

datos, juegos, teléfonos móviles…. Se considera uno de los lenguajes de programación

más populares, especialmente cuando hablamos de aplicaciones cliente-servidor. Su

sintaxis está basada en gran medida en C y C++, aunque posee menos utilidades a bajo

nivel que ambos lenguajes. Las aplicaciones java, una vez compiladas, se pueden

ejecutar en cualquier máquina virtual java (JVM) independientemente de la arquitectura

del computador subyacente.

Java se desarrolló en torno a 5 objetivos:

- Debería usar el paradigma de la programación orientada a objetos.

- Debería permitir la ejecución de un mismo programa en múltiples sistemas

operativos.

- Debería incluir por defecto soporte para trabajo en red.

- Debería diseñarse para ejecutar código en sistemas remotos de forma segura.

- Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos,

como C++.

Estas serían las principales características del lenguaje:

- Simple: posee la funcionalidad de un lenguaje potente, pero elimina las

características menos usadas y más confusas del mismo. Por ejemplo, elimina

características como la aritmética de punteros, la definición de tipos o la necesidad

de liberar memoria. La liberación de memoria se realiza mediante el garbage

collector (reciclador de memoria dinámica) que evita tener que preocuparse de esta

tarea.

- Orientado a objetos: tanto los datos como el código (funciones o métodos) se

combinan en entidades denominadas objetos. Un objeto es lo que alberga el

comportamiento (el código) y el estado (datos). Esta filosofía otorga una base sólida

y estable para el desarrollo de un sistema software, permitiendo desarrollar grandes

proyectos manteniendo la calidad y reduciendo los posibles fallos. Otra gran ventaja

sería la reutilización del software.

- Distribuido: Java en sí no es distribuido, pero proporciona las librerías y

herramientas necesarias para que los programas puedan serlo, permitiendo su

ejecución e interacción en múltiples máquinas. Posee múltiples capacidades de

interconexión TCP/IP, además de librerías de rutinas que hacen uso de los protocolos

http y ftp.


34

- Robusto: con el fin de detectar errores durante el ciclo de desarrollo, Java realiza

verificaciones para buscar posibles problemas tanto en tiempo de compilación como

en tiempo de ejecución. Además, se encarga del manejo de la memoria, de modo

que el programador no debe preocuparse de la liberación o corrupción de esta.

También carece de la aritmética de punteros, reduciendo los posibles errores de

sobreescritura o corrupciones de memoria propias de los arrays.

- Arquitectura Neutral: Java compila el código fuente a bytecode de modo que se

ejecutará en cualquier máquina que posea el sistema de ejecución (run-time)

independientemente del hardware o software en el que se generó el bytecode. El

run-time sí que es dependiente de la máquina, y actualmente existen versiones en

la mayoría de los sistemas operativos o plataformas.

- Seguro: Java presenta un alto grado de seguridad. Para ello posee características

como impedir que se acceda a zonas dedicadas de memoria o sistema, o evitar que

se pueda modificar la pila de programa o memoria. También ofrece un método muy

seguro de autentificación por clave pública. El cargador de clase permite verificar

firmas digitales de modo que ningún objeto se crea ni almacena sin que se validen

los privilegios de acceso. Si se cumplen los estándares indicados por Sun, Java

presenta un alto grado de seguridad.

- Portable: Java ofrece portabilidad gracias a factores como ser de arquitectura

independiente. Además, posee estándares para los tipos de datos. Por ejemplo, los

enteros se tratan siempre como enteros de 32 bits en complemento a 2, permitiendo

que las operaciones siempre generen los mismos resultados independientemente

de la máquina. También se construyen las interfaces de usuario mediante un sistema

abstracto de ventanas para que se puedan implementar en cualquier sistema

operativo.

- Interpretado: el código fuente es a la vez compilado e interpretado. Gracias al

compilador, el código se traduce a bytecode. El intérprete ejecuta las instrucciones

generadas por el compilador, por lo que el programa se compila una vez, y se

interpreta cada vez que es ejecutado. Este hecho ofrece la ventaja de poder crear

aplicaciones multiplataforma, y la desventaja de que sea más lento que el código

compilado para una plataforma particular.

- Multihilo: Java puede manejar diversos hilos o procesos ligeros simultáneamente

durante la ejecución de un programa. Gracias a ello, se consigue aumentar el

rendimiento, debido a un mayor uso de los recursos disponibles.

Se ha utilizado este lenguaje para la implementación de todo el proceso de resolución

del cubo.

35

4.2. PYTHON

Versión: Python 2.7

Se trata de un veterano lenguaje de programación que se encuentra disponible en una

gran variedad de aplicaciones y sistemas operativos. Posee una curva de aprendizaje

moderada cuya filosofía pretende ofrecer una sintaxis de código legible. Este lenguaje

de programación multiparadigma es administrado por la Python Software Foundation y

posee una licencia de código abierto compatible con la Licencia Pública General de GNU.

Se dice que es multiparadigma porque permite varios estilos de programación: la

programación orientada a objetos, la programación imperativa y la programación

funcional. Algunas de las características a destacar del lenguaje serían:

- Se trata de un lenguaje sencillo, legible y elegante.

- Es un lenguaje interpretado, no compilado.

- El uso de tipado dinámico, ya que una variable puede tomar valores de distinto tipo,

y fuertemente tipado, lo que se traduce en que el tipo de valor no cambia

repentinamente, sino que requiere una conversión explícita.

- Conteo de referencias (técnica para contabilizar las veces que se ha referido un

determinado recurso) para la administración de memoria.

- Resolución dinámica de nombres.

- Es multiplataforma, lo que permite que su código fuente sea ejecutable entre

diferentes sistemas operativos.

- Es ideal para trabajar con grandes volúmenes de datos, lo que resulta ideal para Big

Data.

- Permite la automatización de procesos y ejecución de tareas en entorno cliente y

servidor.

El desarrollo de todos los scripts encargados de leer las pulsaciones de los botones,

realizar las fotografías con las cámaras y controlar los motores se ha hecho en Python.

4.3. OPENCV

Versión: OpenCV 3.3

Se trata de la biblioteca más popular de visión artificial. La primera versión data de 1999

y fue desarrollada por Intel, quien en 2012 delegó el proyecto a la fundación sin ánimo

de lucro OpenCV.org. Sus siglas se traducen en Open Computer Vision (Visión Artificial

Abierta). Algunas de sus aplicaciones serían el reconocimiento facial, de gestos u

objetos, realidad aumentada, tracking… Algunas de sus características más destacables

serían:

- Es una biblioteca libre, publicada bajo licencia BSD, que permite su uso con fines

comerciales y de investigación.


36

- Multiplataforma, funciona en la mayoría de los sistemas operativos y arquitecturas

hardware.

- Documentada y explicada: posee una extensa documentación muy completa y

actualizada, complementada con una gran variedad de tutoriales.

- Entorno de desarrollo fácil de utilizar.

- Altamente eficiente, desarrollado en C y C++ optimizados y capaz de aprovechar

procesamiento multinúcleo.

Esta biblioteca se ha utilizado para obtener el estado del cubo a partir de las fotografías

proporcionadas por las cámaras.

4.4. NETBEANS

Versión: NetBeans 8.2

Entorno de desarrollo integrado libre y gratuito sin restricciones de uso. Está enfocado

principalmente a la programación Java, aunque cuenta con un gran número de módulos

para extenderlo y permitir el desarrollo en otros lenguajes como PHP o Python. Además,

está disponible para multitud de sistemas operativos. Es un proyecto de código abierto

fundado por Sun Microsystems en el año 2000. Permite el desarrollo de aplicaciones

estructuradas mediante componentes de software llamados “módulos”.

- Soporta todas las novedades del lenguaje Java, siendo actualizado constantemente

para adaptarse a ellas cuando surgen.

- Es un potente editor de código multilenguaje, ofrece múltiples ayudas al

programador como podrían ser el coloreado para notificación de warnings y errores,

o también la disponibilidad de plantillas de código o la capacidad de mostrar

sugerencias de código.

- Posee diferentes vistas y asistentes de ayudas que simplifican la gestión de grandes

proyectos.

- El debugger es de gran utilidad para el depurado de errores y posee múltiples

utilidades, como la posibilidad de definir puntos de ruptura en el punto del código

que desee el programador, la monitorización en tiempo real de propiedades y

variables o incluso la posibilidad de ser lanzado una vez que ya se está ejecutando la

aplicación.

- El Profiler nos brinda la posibilidad de optimizar la aplicación con el fin de que se

ejecute más rápido y se minimice el consumo de recursos de esta. Para ello, nos

muestra gráficamente el comportamiento de la aplicación, aportando datos como el

consumo de recursos o los objetos que se crean.

- Permite la conexión a diferentes gestores de bases de datos como Oracle y MySQL

desde el mismo IDE, permitiendo visualizar, consultar y modificar las diferentes

tablas de las bases de datos.

- Posee un amplio catálogo de plugins que hacen que sea fácilmente extensible.

37

Este IDE ha sido el utilizado para desarrollar el código Java que resuelve el cubo.

4.5. FRITZING

Versión: Fritzing 0.9.3b

Iniciativa open-source desarrollada en C++ en la Universidad de Ciencias Aplicadas de

Potsdam. Se trata de un programa de automatización de diseño electrónico cuyo

objetivo es documentar prototipos y crear diseños de PCB o esquemas impresos para su

posterior fabricación.

Esta herramienta ha permitido realizar el prototipado del hardware del robot.

4.6. LUCIDCHART

Herramienta basada en la web que permite a los usuarios crear y compartir todo tipo de

diagramas, como diagramas de flujo, organigramas, diseños UML, esquemas de sitios

web…. Lucidchart funciona en navegadores que soportan HTML5 por lo que no requiere

actualizaciones de terceros y funciona en todos los navegadores web modernos, como

Google Chrome, Firefox, Safari e Internet Explorer. Presenta las siguientes

características:

- Basado en la nube, lo que evita descargas o actualizaciones de software. Los

proyectos se guardan en tiempo real en la nube y ofrece la posibilidad de que varios

usuarios trabajen simultáneamente y colaboren en la creación de un proyecto.

- Colaborativo. Ofrece diferentes herramientas para que se puedan comunicar los

usuarios que colaboran en el desarrollo del proyecto, como chat integrado,

comentarios, video chat o colaboración en tiempo real con el resto de los editores.

- Ofrece diferentes opciones de publicación de documentos, como la generación de

PDF o imágenes en formatos jpg y png.

- Posee una amplia colección de librerías de forma estándar que incluyen formas y

plantillas para el desarrollo de diagramas, planos, esquemas, bocetos….

- Permite cierto grado de personalización mediante la opción de importar SVG que

posibilitan que el usuario desarrolle sus propias librerías de formas.

Con esta herramienta se han realizado diferentes diagramas software e

imágenes de la memoria.


38

4.7. PAINT.NET

Versión: Paint.NET 4.2.16

Editor de imágenes para Windows desarrollado en la Universidad Estatal de Washington

y supervisado por Windows. Se ha llevado a cabo en C# con pequeñas cantidades de

código en C++ y utiliza el framework .NET. Aunque se trata de una versión evolucionada

de la herramienta Microsoft Paint integrada en Windows, no está relacionada con la

misma. Actualmente posee una licencia freeware. Ofrece las siguientes características:

- Posee una interfaz simple e intuitiva, con herramientas básicas que permiten

aprender rápido a usar el programa sin necesidad de recibir una extensa formación

como ocurre con herramientas de edición como Adobe Photoshop, aunque también

carece de la potencia y de la enorme variedad de posibilidades que ofrece esta

última.

- Utiliza un sistema de pestañas que permite manejar múltiples imágenes

simultáneamente, proporcionando una navegación simple y rápida.

- Ofrece un buen rendimiento independientemente del hardware en el que se instale,

ya que posee unos requisitos mínimos muy asequibles.

- Permite trabajar por capas, lo que resulta de gran utilidad para la edición gráfica y

suele ser una característica típica de software de pago.

- Actualmente sigue recibiendo actualizaciones que mejoran el programa en cada

versión, ya sea añadiendo nuevas características o mejoras de rendimiento o

corrigiendo errores.

- Posee un amplio catálogo de efectos para mejorar y perfeccionar las imágenes como

desenfoque, nitidez, eliminación de ojos rojos, distorsión ….

- Proporciona una ventana historial que muestra todas las acciones que se han

realizado durante la edición. Permite además deshacer y rehacer todas las acciones

que se desee puesto que el tamaño de esta solo está limitado por el espacio

disponible en disco.

Con esta herramienta se han creado la mayoría de las imágenes de la memoria.

4.8. INKSCAPE

Versión: Inkscape 1.1

Editor profesional de gráficos vectoriales para Windows, Linux y macOS libre y de código

abierto. Trabaja principalmente en formato SVG (Scalable Vector Graphics) y es

totalmente compatible con los estándares XML y CSS. Ofrece las siguientes

funcionalidades:

39

- Creación de objetos mediante herramientas de dibujo (lápiz, pluma o caligráfica),

herramientas de formas (rectángulos, elipses, estrella/polígono o espirales),

herramienta de texto, imágenes embebidas y clonación.

- Manipulación de objetos con herramientas de transformación, operaciones de

profundidad, agregación de objetos, capas y comandos de alineación y distribución.

- Relleno y borde con herramientas como cuentagotas para la selección de color,

editor de degradados, relleno con patrón o marcadores en el trazado, entre otras.

- Operaciones de trazado gracias a su editor de nodos, trazado de bitmaps,

simplificador de trazados o herramientas para convertir en trazado.

- Soporte de texto.

- Renderización mediante visualización con antialiasing, soporte de transparencia

propia del formato PNG o renderización interactiva durante la transformación de

objetos.

- También permite editar y visualizar código fuente de un documento gracias a su

editor XML, exportar a múltiples formatos o la creación y modificación de archivos

bajo el estándar de formato SVG.

Esta herramienta ha facilitado la creación de las diferentes piezas de la estructura del

robot. Estos diseños se han convertido posteriormente a G-code, que es un lenguaje de

programación usado en control numérico. Este G-code permite controlar fresadoras,

cortadoras, tornos e impresoras 3D. En este caso se ha utilizado para controlar la

cortadora láser CNC.

4.9. TINKERCAD

Programa online gratuito de modelado 3D. Su popularidad radica en su simplicidad y

facilidad de uso. Es ampliamente usado en entornos educativos para la creación de

modelos 3D, siendo una herramienta ideal para el campo de la geometría constructiva

de sólidos. Además, ofrece la posibilidad de exportar e importar los proyectos en

formato STL y OBJ para 3D, y en SVG para 2D.

Esta herramienta ha permitido realizar un prototipo 3D de la estructura física del robot,

permitiendo comprobar que todas las medidas de corte eran correctas, y que todas las

piezas encajaban de manera adecuada.


40

4.10. MICROSOFT WORD

Versión: Microsoft 365

Programa de procesamiento de textos contenida en el paquete ofimático Microsoft

Office. Se trata del procesador de texto más popular del mundo. Se ha utilizado para

desarrollar tanto la memoria como anexos de este proyecto.

4.11. RASPBERRY PI OS

Versión: Raspbian GNU/Linux 9 (stretch)

Inicialmente este sistema operativo se llamaba Raspbian. Se trata de una distribución

Linux basada en Debian y es el sistema operativo primario para la familia de placas SBC

de Raspberry Pi, siendo distribuido de forma oficial por la Raspberry Pi Foundation.

Actualmente se encuentra en desarrollo activo y sigue recibiendo actualizaciones,

además está muy optimizado para la Raspberry Pi. Posee una gran variedad de software

educativo y de programación, como Python, Scratch o Java entre otros. Gracias a este

sistema operativo la Raspberry Pi pasa de ser una placa con microcontrolador clásica a

un ordenador personal, exceptuando algunas funcionalidades de estos.

Para poder usar el sistema operativo en la Raspberry Pi es necesario instalarlo en la

Micro SD, que sería como el disco duro del ordenador, ya que hay que montar el sistema

operativo en la tarjeta, y es donde se almacenaran los datos. Una opción que simplifica

mucho este proceso de instalación es usar NOOBS (New Out Of the Box Software), que

es un sencillo instalador de sistemas operativos que contiene Raspberry Pi OS y

LibreELEC, además de ofrecer una lista de sistemas operativos alternativos que se

descargarían de internet y posteriormente se instalarían si el usuario lo indica.

4.12. VNC VIEWER

Versión: VNC Viewer 6.21.406

Se trata de un software libre basado en una arquitectura cliente-servidor que permite

ver y controlar un equipo en remoto. VNC son las siglas de Virtual Network Computing

(Computación Virtual en Red). Posee la ventaja de no imponer restricciones en el SO del

cliente con respecto al del servidor, por lo que un cliente puede conectarse a un servidor

del mismo sistema operativo o de cualquier otro. Se desarrollo como un programa de

código abierto en los laboratorios AT&T Olivetti Research Laboratory, en Cambridge. Lo

utilizaremos para controlar la Raspberry desde un PC y de ese modo evitar tener que

conectarle un monitor ni ningún periférico como el mouse y el teclado.

41

5. ASPECTOS RELEVANTES DEL DESARROLLO

A continuación, se exponen los aspectos más relevantes del desarrollo del proyecto.

5.1. METODOLOGÍA

El proceso de producción del robot comienza con la primera entrevista con los tutores y

finaliza una vez se consiguió un robot funcional que resolviese el cubo de Rubik.

Se ha desarrollado una metodología basada en el proceso unificado, realizando las

diferentes versiones del software mediante un enfoque iterativo e incremental.

La estrategia elegida para llevar a cabo el proyecto fue dividir el software en diferentes

tareas, y cada finalización de una tarea daría lugar a una nueva iteración. Desde un inicio

se programó todo el software en un PC, empezando por la simple tarea de representar

el cubo virtualmente. Estas versiones fueron evolucionando, añadiendo características

como realizar giros sobre el cubo, aplicar algoritmos complejos y finalmente resolverlo.

Igualmente se siguió la misma técnica con el resto de las funciones, por ejemplo, en un

principio el script de extracción de colores del cubo se realizaba sobre una imagen

creada con software de edición gráfica y finalmente se acabó aplicando sobre fotografías

reales.

5.2. INICIO

El primer paso fue realizar una estimación de esfuerzo y una planificación temporal.

La estimación de esfuerzo se llevará a cabo mediante una estimación basada en Casos

de Uso, usando UCP (Use Case Points) para calcular dichas estimaciones.

Con la estimación de esfuerzos estableceremos la relación entre el personal o recursos

humanos disponibles y el tiempo de desarrollo del proyecto.

Para realizar dicha estimación de esfuerzo de desarrollo usaremos la métrica

proporcionada por los UCP, que se basa en la funcionalidad representada en forma de

casos de uso, y considera actores, escenarios y factores técnicos y de entorno.

Para calcular los UCP debemos calcular previamente tres variables.

- UUCP: Unadjusted Use Case Points / Puntos de casos de uso sin ajustar

o UUCW: Unadjusted Use Case Weight / Peso de los casos de uso sin ajustar

o UAW: Unadjusted Actor Weight / Peso de los actores sin ajustar

- TCF: Technical Complexity Factor / Factores de complejidad técnica

- ECF: Enviroment Complexity Factor / Factores de complejidad del entorno


42

Una vez calculadas estas tres variables podemos calcular los UCP con la siguiente

formula

𝑈𝐶𝑃 = 𝑈𝑈𝐶𝑃 ∗ 𝑇𝐶𝐹 ∗ 𝐸𝐶𝐹

Los factores de peso de los casos de uso sin ajustar (UUCP) se dividen en tres grupos en

función del número de transacciones, siendo una transacción el conjunto de actividades

atómicas del caso de uso

- Simple: Tres transacciones o menos

- Medio: De cuatro a siete transacciones

- Complejo: Mas de siete transacciones

Los factores de peso de los actores sin ajustar (UAW) también se dividen en tres grupos

en función de la complejidad de los actores con los que tendrá que interactuar el sistema

- Simple: El actor es un sistema y la aplicación se comunica con el mediante una

API

- Medio: El actor es un sistema y la aplicación se comunica con el mediante un

protocolo (Internet)

- Complejo: El actor es una persona con una interfaz grafica

Los factores de complejidad técnica (TCF) y los factores de complejidad del entorno (ECF)

se calculan a partir de un peso (W) que se asigna a cada factor, y de una complejidad

percibida (F), que se corresponde con la percepción de complejidad que tiene el equipo

de desarrollo.

La siguiente ilustración muestra los casos de uso y actores.

Ilustración 22. Casos de uso y actores

43

El valor de UAW (factores de peso de los actores sin ajustar) se calcula con los “Actor”

(Actores) de la tabla, vemos que hay un total de 4, y que tienen complejidad Complex

(Factor de ponderación 3).

El valor de UUCW (factores de peso de los casos de uso sin ajustar) se calcula con los

“Usecase” (casos de uso) de la tabla, vemos que hay un total de 12, y que tienen

complejidad “Simple” (Factor de ponderación 5).

Con estos datos podemos calcular los UUCP (Puntos de casos de uso sin ajustar).

𝑈𝑈𝐶𝑃 = 𝑈𝐴𝑊 + 𝑈𝑈𝐶𝑊 = 12 + 60 = 72

La siguiente imagen muestra los factores de complejidad técnica (TCF).

Descripción Peso

Sistemas distribuidos 2

Rendimiento 2

Eficiencia del usuario final 1

Procesamiento interno complejo 1

Reusabilidad 1

Facilidad de instalación 0,5

Facilidad de uso 0,5

Portabilidad 2

Facilidad de cambio 1

Concurrencia 1

Características especiales de seguridad 1

Acceso directo a terceras partes 1

Se requiere entrenamiento especial el usuario 1

Ilustración 23. Factores de complejidad técnica

Calculamos el TFactor a partir del valor F (complejidad percibida) y del W (Peso) de los

diferentes factores de complejidad técnica (TCF).

𝑇𝐹𝑎𝑐𝑡𝑜𝑟 =∑𝑊𝑖

13

𝑖=1

𝐹1 = 33

Calculamos los TCF con la siguiente formula.

𝑇𝐶𝐹 = 𝐶1 + 𝐶2∑𝑊𝑖

13

𝑖=1

𝐹1 = 𝐶1 + 𝐶2 ∗ 𝑇𝐹𝑎𝑐𝑡𝑜𝑟 = 0,93

La siguiente imagen muestra los factores de complejidad del entorno (ECF).


44

Descripción Peso

Familiaridad con UML 1,5

Experiencia en la aplicación 0,5

Experiencia en orientación a objetos 1

Capacidad del analista líder 0,5

Motivación 1

Estabilidad de los requerimientos 2

Personal part-time -1

Dificultad del lenguaje de programación

-1

Ilustración 24. Factores de complejidad del entorno

Calculamos el EFactor a partir del valor F (complejidad percibida) y del W (Peso) de los

diferentes factores de complejidad del entorno (ECF).

𝐸𝐹𝑎𝑐𝑡𝑜𝑟 =∑𝑊𝑖

8

𝑖=1

𝐹1 = 19

𝐸𝐶𝐹 = 𝐶1 + 𝐶2∑𝑊𝑖

8

𝑖=1

𝐹1 = 0,83

Llegados a este punto ya podemos calcular los UCP

𝑈𝐶𝑃 = 𝑈𝑈𝐶𝑃 ∗ 𝑇𝐶𝐹 ∗ 𝐸𝐶𝐹 = 72 ∗ 0,93 ∗ 0,83 = 55,5768

45

Ilustración 25. Estimación temporal

La imagen anterior muestra la estimación temporal denominada Total Effort, en la que

aparece el número de horas que se tardaría en desarrollar, que son 1111,536 horas. Este

valor está calculado con una estimación de 20 horas por UCP.

La planificación temporal consistirá en la identificación de tareas, así como la asignación

de tiempos y recursos a dichas tareas de forma óptima con el fin de minimizar el tiempo

de desarrollo del proyecto. El resultado será un calendario o programa de tiempos

donde se visualizará gráficamente los pasos o actividades a seguir para la realización del

proyecto.

Este proyecto se expuso a los tutores en octubre de 2019. En un principio se planteó

presentar el proyecto en 2020, lo que hubiera dado lugar a la presentación de un

proyecto inmaduro. Tras realizar la planificación y valorar la enorme cantidad de

factores a tener en cuenta para su desarrollo, no sería posible desarrollar este proyecto

en tan poco tiempo, por lo que finalmente se optó por presentar el proyecto al año

siguiente. Concretamente se planifico la realización de este para febrero de 2021. Esta

fecha es muy temprana respecto a la fecha de la defensa. Esto es debido a que se prefirió

dejar un buen margen de tiempo para evitar las típicas complicaciones que aparecen en

cualquier proyecto y que no se prevén hasta que surgen.

El primer paso fue realizar un análisis del sistema para analizar los problemas que

podrían surgir. En este paso se trató de analizar todas las tecnologías que se tendrían

que aprender, como por ejemplo Python para la realización de scripts.

Posteriormente se realizó el diseño del sistema, y finalmente su implementación. Una

vez alcanzado este punto, se realizarán diversas pruebas de funcionamiento para validar

el robot, y posteriormente se completará la documentación.


46

Para desarrollar la planificación temporal vamos a usar diagramas de Gantt, que nos

permiten realizar una estimación temporal bastante realista, o al menos organizarnos

para gestionar el tiempo del que disponemos de una manera más exacta.

Se pretende optimizar el desarrollo del proyecto mediante el solapamiento de tareas

que sean independientes, y por lo tanto se puedan realizar simultáneamente.

A continuación, se muestran las cinco fases en las que se ha dividido la creación del

robot.

Ilustración 26. Diagrama de Gantt

Se puede ver el proceso de especificación de requisitos software completo en el anexo

I.

5.3. ANÁLISIS

El siguiente paso sería definir los requisitos que deberá cumplir la parte software del

robot. Estos requisitos se analizarán para obtener el modelo del dominio del problema,

y de este modo se ira generando el diseño del sistema. A continuación, se exponen los

aspectos más relevantes del mismo.

Comenzaremos detallando la especificación de requisitos, que contiene los objetivos,

los requisitos de información, los de restricción y los no funcionales. Para esta elicitación

de requisitos se usará la metodología de Durán y Bernárdez, generando las diferentes

tablas con la herramienta REM.

Posteriormente se expondrán los casos de uso y su correspondiente matriz de

rastreabilidad.

Finalizaremos con el diagrama de clases y los diagramas de secuencia.

A continuación, se muestra un ejemplo de los objetivos que se pretendían alcanzar:

OBJ-0005 Gestión cubo

Versión 1.0 ( 14/06/2021 )

Autores • Miguel Rubio Arroyo •

file:///C:/Users/R2D2/Desktop/TFG/Rubok_REM_Default_Spanish_DRS.html%23STK-0001

47

Fuentes • Propias •

Descripción El sistema deberá ser capaz de gestionar el cubo de Rubik que reciba como parámetro, asegurándose de que los parámetros recibidos sean correctos

Subobjetivos Ninguno

Importancia vital

Urgencia inmediatamente

Estado pendiente de verificación

Estabilidad alta

Comentarios Ninguno

Ilustración 27. Objetivos

También se definieron los requisitos de información, que indican los datos que deberá

almacenar y manejar el sistema software, a continuación, se muestra un ejemplo:

IRQ-0001 Cubo

Versión 1.0 ( 28/07/2020 )

Autores • Miguel Rubio Arroyo

Fuentes • Propias

Dependencias • [OBJ-0005] Gestión cubo

Descripción El sistema deberá almacenar la información correspondiente a el color de caza pieza del cubo físico. Creará internamente un cubo con el mismo estado que el físico. Hay tres tipos de piezas. En concreto:

Datos específicos

• Centros

• Aristas

• Esquinas

Tiempo de vida

Medio Máximo

1 minuto(s) 2 minuto(s)

Ocurrencias simultáneas

Medio Máximo

1 1

Importancia vital


Estado pendiente de verificación

Estabilidad alta

Comentarios Ninguno

Ilustración 28. Requisitos de información




file:///C:/Users/R2D2/Desktop/TFG/Rubok_REM_Default_Spanish_DRS.html%23OBJ-0005


48

El siguiente paso fue obtener los requisitos funcionales y no funcionales. Adicionalmente

se han definido los requisitos de restricción para agregar una mayor estabilidad al

software. Por ejemplo, se comprueba que el cubo recogido sea resoluble.

El sistema se ha dividido en cuatro paquetes bien definidos que recogen las funciones

que realiza el robot. Estos paquetes serian mezclar, resolver y aplicar patrón sobre el

cubo, y apagar el robot.

Ilustración 29. Diagrama de paquetes

Posteriormente se realizaron los casos de uso de cada uno de los paquetes, a

continuación, se muestra un ejemplo de uno de ellos.

Ilustración 30. Caso de uso

Cada caso de uso se describe detalladamente mediante las correspondientes tablas

REM. A continuación, se muestra un ejemplo:

49

UC-0005 Botón resolver

Versión 1.0 ( 15/06/2021 )

Autores • Miguel Rubio Arroyo

Fuentes • Propias

Dependencias • [OBJ-0005] Gestión cubo

• [OBJ-0002] Resolver cubo

• [IRQ-0006] Algoritmos

• [IRQ-0001] Cubo

• [UC-0014] Algoritmos patrón

Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario quiere resolver el cubo o durante la realización de los siguientes casos de uso: [UC-0007] Botón patrón

Precondición

Secuencia normal

Paso Acción

1 El actor Usuario (ACT-0001) quiere resolver el cubo, para ello pulsa el botón resolver cubo.

2 Se realiza el caso de uso Cámaras hacen fotos (UC-0002)

3 Se realiza el caso de uso Extraer colores (UC-0011)

4 Se realiza el caso de uso Algoritmos resolver (UC-0013)

5 Se realiza el caso de uso Motores (UC-0003)

6 Se realiza el caso de uso Cámaras hacen fotos (UC-0002)

7 Se realiza el caso de uso Extraer colores (UC-0011)

8 El sistema comprueba que el cubo de las fotos se corresponde con el que se ha generado virtualmente.

9 Se realiza el caso de uso Crear informe (UC-0004)

Postcondición

Excepciones Paso Acción

- -

Rendimiento Paso Tiempo máximo

- -

Frecuencia esperada

PD

Importancia vital


Estado validado

Estabilidad alta

Comentarios Ninguno

Ilustración 31. Casos de uso

Finalmente se han realizado los diagramas de secuencia que muestran la comunicación

entre los diferentes objetos de manera secuencial.





file:///C:/Users/R2D2/Desktop/TFG/Rubok_REM_Default_Spanish_DRS.html%23IRQ-0006

file:///C:/Users/R2D2/Desktop/TFG/Rubok_REM_Default_Spanish_DRS.html%23IRQ-0001

file:///C:/Users/R2D2/Desktop/TFG/Rubok_REM_Default_Spanish_DRS.html%23UC-0014

file:///C:/Users/R2D2/Desktop/TFG/%23UC-0007

file:///C:/Users/R2D2/Desktop/TFG/Rubok_REM_Default_Spanish_DRS.html%23ACT-0001









50

Ilustración 32. Diagrama de secuencia

Se puede ver el proceso de análisis completo en el anexo II.

5.4. DISEÑO

En este punto se procedió a definir las especificaciones de la fase de diseño. De este

modo obtendremos un modelo del dominio de la solución. Una vez realizado este paso

se procederá a la implementación del sistema.

En este punto se deben tomar decisiones importantes que condicionaran la arquitectura

de los datos. Estas decisiones influirán en los factores de calidad, es decir, el desempeño

final del software del robot.

A continuación, se muestra el diagrama de clases de diseño del sistema:

51

Ilustración 33. Diagrama de clases

Se ha diseñado una arquitectura basada en el patrón modelo-vista-controlador con el

fin de modular las capas según su contenido. A continuación, se muestra un subsistema

del sistema.

Ilustración 34. Gestión cubo


52

También se han rediseñado los diagramas de secuencia para amoldarlos a la evolución

del proyecto. A continuación, se muestra un ejemplo:

Ilustración 35. Diagrama de secuencia

Se puede ver el proceso de especificación de diseño completo en el anexo III.

5.5. IMPLEMENTACIÓN SOFTWARE

El proyecto se ha realizado de manera iterativa, comenzando con versiones muy

limitadas tanto en la resolución del cubo como en la extracción del estado del cubo

mediante fotografías, o el control de giro de los motores.

El primer objetivo fue realizar un software capaz de resolver el cubo en cualquiera de

sus estados. El proyecto fue evolucionando gracias a las sucesivas versiones iterativas

que ampliaron sus funcionalidades. Las primeras versiones del software de resolución

del cubo se enfocaron en poder representar el cubo. Para ello, se definieron 3 clases que

representan las tres piezas que constituyen el cubo: los centros, las aristas y las esquinas.

El planteamiento para cada pieza es que tuviese un nombre y una serie de cuadrados,

de modo que los centros se llamarían U, F, R, D, B y L y tendrían un único cuadrado o

53

color. Por otro lado, las aristas se llamarían UF, UR, UB, UL, DF, DR, DB, DL, FL, FR, BL Y

BR y cada una tendría dos cuadrados o colores. Por último, las esquinas se denominan

UFR, UBR, UBL, UFL, DFR, DBR, DBL y DFL y tendrían tres cuadrados o colores. Se

implementaron las siguientes clases:

- Cuadrado: Almacena un entero que representa un color. Hay 6 colores posibles, ya

que el cubo tiene 6 caras. Se planteó almacenar el color en formato entero para

abstraer la implementación de los colores reales del cubo de los algoritmos de

resolución, de modo que el software sea capaz de resolver cualquier cubo

independientemente de los colores que tenga.

- Centro: Contiene una cadena que será el nombre y un objeto Cuadrado.

- Arista: Contiene una cadena que será el nombre y dos objetos Cuadrado.

- Esquina: Contiene una cadena que será el nombre y tres objetos Cuadrado.

- Cubo: Contiene un array de objetos Centro, otro de objetos Arista y otro de objetos

Esquina.

Para construir el cubo, se usa el constructor de la clase Cubo, que recibe como

parámetro una cadena formado por enteros ordenados de manera que indica el color

de cada cuadrado del cubo, en total la cadena tendría 54 enteros (9 cuadrados o colores

por cada una de las 6 caras). Un cubo resuelto se expresaría de la siguiente manera:

“0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2

3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5”

El orden que sigue este parámetro que recibe el constructor sería 1º la cara U, 2º la cara

F, 3º la cara R, 4º la cara D, 5º la cara B y 6º la cara L. La siguiente imagen muestra el

orden en el que se deben pasar los colores de un cubo al constructor.

Ilustración 36. Orden de los cuadrados

Una vez hecho esto, el siguiente paso fue implementar todos los giros posibles. Cabe

destacar que por cómo se ha planteado el modo de funcionamiento del robot, donde

cada uno de los 6 motores se conectan al centro de las distintas caras del cubo, solo se

pueden realizar giros de una única cara, quedando descartadas las rotaciones del cubo

entero, las del nivel intermedio, o las de dos niveles. En los algoritmos de resolución del


54

método Fridrich, se utilizan estas rotaciones, pero esto se soluciona traduciendo esos

giros a rotaciones de una única cara. Por ejemplo, el giro “u” que consiste en un giro en

sentido horario de los niveles superior e intermedio, sería lo mismo que realizar un giro

“D” que es un giro en sentido antihorario del nivel inferior y posteriormente una

rotación del cubo “Y”, que consiste en rotar el cubo entero en sentido horario.

Dicho esto, se implementaron los giros “U”, “F”, “R”, “D”, “B”, “L”, “X”, “Y”, “Z”, y sus

respectivos giros en el sentido opuesto “U’”, “F’”, “R’”, “D’”, “B’”, “L’”, “X’”, “Y’” y “Z’”.

Estos últimos se especificaron como “UPRI”, “FPRI”, “DPRI”, … para evitar confusiones y

posibles problemas a la hora de introducir las comillas en una cadena, ya que estas

deben ir precedidas de la barra inversa “\” para que el compilador genere el resultado

deseado.

La clase Giro, que contiene todas las funciones necesarias para llevar a cabo los

diferentes giros, recibe como parámetro un objeto Cubo que contiene el estado actual

del cubo, y una cadena que indica el giro a realizar, y devuelve un objeto Cubo con el

estado resultante de haber realizado el giro. En fases del desarrollo posteriores, se

crearon las clases de movimientos con el objetivo de añadir más funcionalidades. Por

ejemplo, el poder suministrarle a la clase Giro más de un giro en cada llamada a la

función girar.

En la clase Giro se implementaron las funciones giroArista, giroEsquina y giroIntermedio

para llevar a cabo los posibles giros indicados anteriormente. La idea de estas funciones

es indicarle las piezas que habría que desplazar en el giro.

De este modo, la función giroF consistiría en dos llamadas a la función giroArista, puesto

que cada arista se compone de dos cuadrados y tres llamadas a la función giroEsquina,

ya que cada esquina se compone de tres cuadrados.

Ilustración 37. Código giro

A continuación, se muestra gráficamente el resultado de las llamadas a las funciones

giroArista y giroEsquina.

La primera llamada a giroArista se correspondería con las flechas de color rosa y

desplaza los cuadrados UF 1, FL 2, DF 1 Y FR 2. Y la segunda llamada, con la flecha de

color gris, y desplaza los cuadrados UF2, FL 1, DF 2 Y FR 1. El resultado de estas dos

llamadas es que se ha aplicado el giro sobre las aristas involucradas en el giro F, es decir,

las aristas UF, FL, DF Y FR.

55

Ilustración 38. Giro de aristas

La primera llamada a giroEsquina se correspondería con las flechas de color gris y

desplaza los cuadrados UFL 2, DFL 2, DFR 2 Y UFR 2. La segunda llamada, con la flecha

de color azul, y desplaza los cuadrados UFL 1, DFL 3, DFR 1 Y UFR 3. La tercera llamada

con la flecha de color rosa, y desplaza los cuadrados UFL 3, DFL 1, DFR 3 Y UFR 1. El

resultado de estas tres llamadas es que se ha aplicado el giro sobre las esquinas

involucradas en el giro F, es decir, las esquinas UFR, UFL, DFL Y DFR.

Ilustración 39. Giro de esquinas

El resto de los giros “U”, “R”, “D”, “B”, “L”, “UPRI”, “RPRI”, “DPRI”, “BPRI” y “LPRI” se

realizan de la misma forma, con dos llamadas a la función giroArista y tres llamadas a la

función giroEsquina.

En cuanto a los giros “X”, “Y”, “Z”, “XPRI”, “YPRI” y “ZPRI”, rotarían el cubo completo.

Una vez implementados todos los giros posibles del cubo, se crearon las clases de

movimientos.

La clase Movimiento contiene una cadena que indica uno de los giros anteriormente

mencionados.


56

La clase Movimientos contiene un array de objetos Movimiento. Esta clase posee un

constructor que recibe una cadena con varios giros, y crea un nuevo elemento del array

de objetos Movimiento por cada giro que se ha indicado en la cadena. De este modo, se

implementó que la clase Giro pudiese recibir una instancia de la clase Movimientos que

contiene varios objetos Movimiento, por lo que la clase Giro es capaz de recibir varios

giros y devolver el estado del cubo tras aplicárselos.

Hasta este punto se estaba visualizando el cubo como la cadena de enteros que lo

compone, en la que los enteros representan los colores del cubo. Para visualizar con

mayor rapidez y facilidad el estado del cubo, se implementó la clase Consola, que nos

permite utilizar la consola del propio IDE o la del sistema operativo. Esta clase mediante

la función imprimir, que recibe un objeto Cubo como parámetro, nos muestra las 6 caras

del cubo en forma de cruz, utilizando colores en vez de enteros, por lo que resulta mucho

más cómodo y menos confuso para el proceso de desarrollo.

Ilustración 40. Vista desde consola

Una vez hecho esto, se realizaron varias pruebas para comprobar que los giros

realizaban los desplazamientos de los diferentes cuadrados involucrados de manera

correcta y no se daban situaciones inesperadas o erróneas. El siguiente paso fue

implementar los algoritmos de resolución del cubo.

5.5.1. PRIMER ALGORITMO, CROSS

Se trata del único paso que no tiene algoritmos predefinidos en el método Fridrich. La

forma de resolverlo en un mayor o menor número de giros depende totalmente de la

destreza del usuario que lo resuelve.

57

En el método Fridrich, se suele realizar la cruz en el nivel inferior o base del cubo. De

este modo, tendríamos el cubo en la posición deseada para realizar el resto de los pasos

de una manera más óptima, ya que no tendremos que voltear el cubo para buscar las

piezas que debemos colocar.

Se ha creado un bucle que se ejecutará mientras que no esté completa la cruz. Este bucle

contiene una serie de comprobaciones que se realizarán sobre el estado del cubo actual.

Si el cubo cumple la comprobación que se realiza, se aplica el movimiento o

movimientos que contiene, y se vuelve a ejecutar el bucle siempre que no haya quedado

resuelta la cruz. Primero se realizan las comprobaciones que necesitan un único giro

para colocar la arista. Posteriormente, las que necesitan dos giros, tres giros, cuatro

giros y finalmente las de cinco giros, que sería el peor caso posible, ya que lo que nos

interesa es colocar una arista con el menor número de giros posibles. En los casos que

requieren más de un giro y que estos giros se realizan en caras diferentes, hay que

asegurarse de que, si se deshace algún paso conseguido anteriormente, después de

colocar la arista se vuelva a hacer lo deshecho para no perder lo que se había conseguido

hasta ese punto. Estos son los casos que más giros requieren. Finalmente devuelve un

objeto Movimientos, que como indicamos anteriormente contiene una serie de giros,

en este caso los giros con los que se resuelve la cruz.

Ilustración 41. Cruz

5.5.2. SEGUNDO ALGORITMO, F2L

Se ha implementado un bucle que se ejecutará hasta que no se haya completado el F2L,

o lo que es lo mismo, hasta que no estén los niveles inferior e intermedio del cubo

resueltos. Para completar este paso, habría que colocar en el peor de los casos las cuatro

esquinas del nivel inferior y las cuatro aristas del nivel intermedio. Cada esquina con su

arista contigua se emparejará en la cara superior y luego se insertará en su posición

correspondiente. Habría que aplicar uno de los 41 algoritmos posibles sobre cada una

de las cuatro parejas formadas por la esquina y arista contiguas. Esto se traduce en que

tendremos que adaptar los 41 algoritmos a cada una de las 4 parejas o lados del cubo.

Tendremos 164 comprobaciones posibles (41 x 4), sobre las que se aplicará uno de los

41 algoritmos en cada comprobación. El proceso de implementación de todas estas

posibilidades resultó bastante tedioso, pero los resultados obtenidos son óptimos en


58

cuanto a tiempo requerido para resolver este paso, y en cuanto al número de

movimientos necesarios.

A continuación, se muestran los casos posibles, agrupados por la posición de la esquina

blanca y la arista que debe adjuntarse a ella [9].

Primer caso: Casos fáciles

R U R'

F' U' F

U' F' U F

U R U' R'

Segundo caso: Esquina en el nivel inferior, arista en el nivel superior

(U R U' R') (U' F' U F)

(U' F' U F) (U R U' R')

(F' U F) (U' F' U F)

(R U R') (U' R U R')

(R U' R') (U R U' R')

(F' U' F) (U F' U' F)

Tercer caso: Esquina en el nivel superior, arista en el nivel intermedio

(R U R' U') (R U R' U') (R U R')

(R U' R') (d R' U R)

(U F' U F) (U F' U2 F)

(U F' U' F) (d' F U F')

59

(U' R U' R') (U' R U2 R')

(U' R U R') (d R' U' R)

Cuarto caso: Esquina apuntando hacia afuera, arista en el nivel superior

(R U' R' U) (d R' U' R)

(F' U F U') (d' F U F')

(U F' U2 F) (U F' U2 F)

(U' R U2 R') (U' R U2 R')

(U F' U' F) (U F' U2 F)

(U' R U R') (U' R U2 R')

(U' R U' R' U) (R U R')

(U F' U F U') (F' U' F)

(U' R U R' U) (R U R')

(U F' U' F U') (F' U' F)

(U F' U2 F U') (R U R')

(U' R U2 R' U) (F' U' F)

Quinto caso: Esquina apuntando hacia arriba, arista en el nivel superior

(R U R' U') U' (R U R' U') (R U R')

y' (R' U' R U) U (R' U' R U) (R' U' R)


60

(U2 R U R') (U R U' R')

(U2 F' U' F) (U' F' U F)

(U R U2 R') (U R U' R')

(U' F' U2 F) (U' F' U F)

(R U2 R') (U' R U R')

(F' U2 F) (U F' U' F)

Sexto caso: Esquina en el nivel inferior, arista en el nivel intermedio

(R U' R' d R' U2 R) (U R' U2 R)

(R U' R' U R U2 R') (U R U' R')

(R U' R' U' R U R') (U' R U2 R')

(R U R' U' R U' R') (U d R' U' R)

(R U' R' d R' U' R) (U' R' U' R)

Ilustración 42. Casos F2L

Ilustración 43. F2L

61

5.5.3. TERCER ALGORITMO, OLL

Este tercer paso se ha implementado de manera muy similar al anterior, aunque este es

bastante más sencillo puesto que no hay que multiplicar por cuatro las posibilidades. Se

ejecuta un bucle mientras que no se haya completado el OLL, y dentro del bucle, se

realizan un total de 57 comprobaciones, que son todas las posibilidades que contempla

este paso. Si el cubo cumple alguna de las comprobaciones, se aplica uno de los 57

algoritmos, de lo contrario y si el OLL no se ha resuelto, se rota la cara superior y se

vuelve a ejecutar el bucle. Al igual que los pasos anteriores, el tiempo requerido para

hallar la solución y el número de movimientos son óptimos.

A continuación, se muestran los casos posibles, agrupados por su aspecto [10].

Dot / Punto

R U B' l U l2' x' U' R' F R F'

R' F R F' U2 R' F R y' R2 U2 R

y L' R2 B R' B L U2' L' B M'

R' U2 x R' U R U' y R' U' R' U R' F

(R U R' U) R' F R F' U2 R' F R F'

M' U2 M U2 M' U M U2 M' U2 M

R' U2 F (R U R' U') y' R2 U2 x' R U

F (R U R' U) y' R' U2 (R' F R F')

Line / Línea

R' U' y L' U L' y' L F L' F R

R U' y R2 D R' U2 R D' R2 d R'

F U R U' R' U R U' R' F'

L' B' L U' R' U R U' R' U R L' B L

Cross / Cruz


62

L U' R' U L' U (R U R' U) R

(R U R' U) R U' R' U R U2 R'

L' U R U' L U R'

R' U2 (R U R' U) R

R' F' L F R F' L' F

R2 D R' U2 R D' R' U2 R'

R' F' L' F R F' L F

4 corners / 4 esquinas

M' U' M U2' M' U' M

L' (R U R' U') L R' F R F'

Shape _I / Forma _I

L F R' F R F2 L'

F R' F' R U R U' R'

R' U' R y' x' R U' R' F R U R'

U' R U2' R' U' R U' R2 y' R' U' R U B

F (R U R' U') (R U R' U') F'

L F' L' F U2 L2 y' L F L' F

Shape I_ / Forma I_

63

U' R' U2 (R U R' U) R2 y (R U R' U') F'

r U2 R' U' R U' r'

R' U2 l R U' R' U l' U2 R

F' L' U' L U L' U' L U F

R' F R' F' R2 U2 x' U' R U R'

R' F R F' U2 R2 y R' F' R F'

Shape ¯I / Forma ¯I

R U R' y R' F R U' R' F' R

L' B' L U' R' U R L' B L

U2 r R2' U' R U' R' U2 R U' M

x' U' R U' R2' F x (R U R' U') R B2

Shape I¯ / Forma I¯

L U' y' R' U2' R' U R U' R U2 R d' L'

U2 l' L2 U L' U L U2 L' U M

R2' U R' B' R U' R2' U l U l'

r' U2 (R U R' U) r

C

R U x' R U' R' U x U' R'

(R U R' U') x D' R' U R E'

L


64

R' F R U R' F' R y L U' L'

L F' L' U' L F L' y' R' U R

L' B' L R' U' R U L' B L

R B R' L U L' U' R B' R'

P

F U R U' R' F'

R' d' L d R U' R' F' R

L d R' d' L' U L F L'

F' U' L' U L F

T

F (R U R' U') F'

(R U R' U') R' F R F'

W

L U L' U L U' L' U' y2' R' F R F'

R' U' R U' R' U R U y F R' F' R

Z

R' F (R U R' U') y L' d R

L F' L' U' L U y' R d' L'

Ilustración 44. Casos OLL

65

Ilustración 45. OLL

5.5.4. CUARTO ALGORITMO, PLL

El cuarto y último paso sigue la lógica de los anteriores. Consta de un bucle que se

ejecuta mientras que no se haya completado el PLL. Dentro contiene 21

comprobaciones. Cada una contiene uno de los 21 algoritmos que resolverían ese

estado del cubo.

Una vez fuera del bucle, el cubo tendría que estar totalmente resuelto, por lo que se

realiza una comprobación para asegurarnos de que no ha fallado nada durante todo el

proceso.

A continuación, se muestran los casos posibles [11].

A1 A2

x [(R' U R') D2] [(R U' R') D2] R2

x' [(R U' R) D2] [(R' U R) D2] R2

U1 U2

R2 U [R U R' U'] (R' U') (R' U R')

[R U'] [R U] [R U] [R U'] R' U' R2

H T

M2 U M2 U2 M2 U M2

[R U R' U'] [R' F] [R2 U' R'] U' [R U R' F']

J1 J2


66

[R' U L'] [U2 R U' R' U2] [R L U']

[R U R' F'] {[R U R' U'] [R' F] [R2 U' R'] U'}

R1 R2

[L U2' L' U2'] [L F'] [L' U' L U] [L F] L2' U

[R' U2 R U2] [R' F] [R U R' U'] [R' F'] R2 U'

V G1

[R' U R' d'] [R' F'] [R2 U' R' U] [R' F R F]

R2 u R' U R' U' R u' R2 [y' R' U R]

G2 G3

[R' U' R] y R2 u R' U R U' R u' R2

R2 u' R U' R U R' u R2 [y R U' R']

G4 F

[R U R'] y' R2 u' R U' R' U R' u R2

[R' U2 R' d'] [R' F'] [R2 U' R' U] [R' F R U' F]

Z Y

M2 U M2 U M' U2 M2 U2 M' U2

F R U' R' U' [R U R' F'] {[R U R' U'] [R' F R F']}

N1 N2

{(L U' R) U2 (L' U R')} {(L U' R) U2 (L' U R')} U

{(R' U L') U2 (R U' L)} {(R' U L') U2 (R U' L)} U'

E

67

X' (R U' R') D (R U R') u2 (R' U R) D (R' U' R)

Ilustración 46. Casos PLL

Ilustración 47. PLL

5.5.5. QUINTO ALGORITMO, OPTIMIZAR MOVIMIENTOS

En este punto se tiene toda la secuencia de movimientos que, aplicándose al cubo inicial

mezclado, se obtendría el cubo resuelto. En esta secuencia de movimientos puede haber

giros redundantes o posibilidades que se pueden optimizar. Por ejemplo, si uno de los

pasos del método Fridrich finaliza con un giro U, y el siguiente paso comienza con un

giro UPri, podríamos eliminar ambos giros y no cambiaría el proceso de resolución del

cubo.

Este paso trata de reducir al mínimo y optimizar los movimientos con los que se resuelve

el cubo.

Se ha implementado un bucle que se ejecutará hasta que en alguna de las iteraciones

no se obtenga ninguna mejora sobre la secuencia de movimientos. Dentro del bucle se

aplican secuencialmente estos tres filtros:

- El primer filtro busca 4 giros iguales consecutivos. Si aparece este caso, se eliminan

los cuatro giros.

Cubo inicial Secuencia de 4 giros U consecutivos Cubo final

Ningún giro

Ilustración 48. 4 giros iguales


68

- El segundo filtro busca 3 giros iguales consecutivos. En este caso los tres giros se

sustituyen por un giro en el sentido inverso

Cubo inicial Secuencia de 3 giros U consecutivos Cubo final

Un giro UPri

Ilustración 49. 3 giros iguales

- El tercer filtro busca un giro seguido de su giro opuesto. Se eliminarían ambos giros.

Cubo inicial Un giro U y su opuesto UPri consecutivos Cubo final

Ningún giro

Ilustración 50. Giros opuestos

Una vez aplicados los tres filtros anteriores, se realiza una última optimización. Se busca

aumentar el número de giros que el robot puede realizar de manera simultánea, al

mismo tiempo que aumentar el número de giros que se pueden eliminar con alguno de

los filtros descritos anteriormente.

El algoritmo funciona de la siguiente manera: implementa un bucle en el que analiza uno

a uno todos los movimientos, y los compara con los dos movimientos siguientes. Si el

segundo giro es igual al primer giro, y el tercer giro es un giro de la cara opuesta,

intercambia el segundo y tercer giro. Por ejemplo, si el giro que está analizando es un

giro U, el siguiente giro también es un giro U, y el siguiente es un giro D, la solución

resultante sería giro U, giro D, giro U. Una vez aplicado este algoritmo, se vuelven a

aplicar los filtros anteriores por si se pudiesen eliminar más giros. Se pueden conseguir

diversas mejoras con este método.

Por ejemplo, si tenemos la secuencia giro U, giro U, giro D, giro D, los motores harían un

giro U, posteriormente harían simultáneamente un giro U y D y finalmente harían un

giro D. Si se aplica este algoritmo, la secuencia resultante seria giro U, giro D, giro U, giro

D, por lo que los motores harían un giro U y D simultáneamente, y otro giro U y D

simultáneamente.

Otro ejemplo sería si tuviésemos la secuencia giroU, giro U, giro D, giro UPri. Sin aplicar

el algoritmo, los motores realizarían un giro U, posteriormente un giro U y giro D

69

simultáneamente y finalmente un giro UPri. Tras aplicar el algoritmo la secuencia sería

giro U, giro D, giro U, giro UPri, por lo que conseguiríamos que los dos últimos giros

finales se eliminen tras aplicar los filtros descritos anteriormente, resultando en que los

motores realizarían solamente un giro U y giro D simultáneamente.

Cubo inicial 2 giros U seguidos de un giro D Cubo final

Un giro U, un giro D, un giro U

Ilustración 51. 2 giros iguales y uno opuesto

5.5.6. RESOLVER SOBRE TODAS LAS CARAS

Una vez implementado todo el proceso de resolución del cubo, y tras observar que los

tiempos de resolución eran bastante buenos, se decidió implementar otra mejora para

obtener soluciones con menos movimientos. El método Fridrich comienza realizando el

primer algoritmo sobre la base del cubo, y en un principio escogíamos la base del cubo

físico como cara para realizar el primer algoritmo (la cruz). Elegir cualquier otra cara

como base sobre la que aplicar los algoritmos podría darnos soluciones con menos

movimientos, por lo que se implementó que probase a resolver el cubo eligiendo como

base cada una de las seis caras, y posteriormente seleccionase como solución la

ejecución que menos giros genere.

Cruz F2L OLL PLL

Resolución sobre la cara D del cubo

Resolución sobre la cara B del cubo

Resolución sobre la cara L del cubo


70

Resolución sobre la cara U del cubo

Resolución sobre la cara F del cubo

Resolución sobre la cara R del cubo

Ilustración 52. CFOP sobre todas las caras

5.5.7. GIROS DOBLES

Una vez se ha resuelto el cubo sobre cada una de sus caras, se podría seleccionar la

solución que menos giros hubiese generado, pero esto no quiere decir que dicha

solución sea en la que menos tiempo necesiten los motores para aplicarla. Los motores

son capaces de realizar dos giros al cubo simultáneamente siempre que estos giros sean

opuestos, por ejemplo, un giro U seguido de un giro D o D’ podrían realizarse

simultáneamente, por lo que estos dos giros tardarían lo mismo que un solo giro U. Por

ello, se implementó un algoritmo que calcula el número de giros dobles o giros

simultáneos que podrían realizarse sobre cada una de las soluciones. Por cada giro

doble, se le resta un movimiento a la solución en términos de tiempo, de modo que, si

tenemos una solución con 60 giros, y posee 5 giros dobles, el tiempo que tardará en

resolverlo será el tiempo que emplean los motores en realizar 55 giros.

5.5.8. ALGORITMO PATRÓN

Contiene una lista de patrones que se deben aplicar sobre el cubo resuelto. Se ha

implementado de forma que se aplique uno de los patrones de la lista elegido

aleatoriamente. Devuelve la secuencia de movimientos que realizan el patrón sobre el

cubo.

Ilustración 53. Patrones

71

5.5.9. ALGORITMO MEZCLAR

Su objetivo es devolver una secuencia de giros aleatorios para mezclar el cubo. Generará

tantos giros aleatorios como le indique el parámetro de entrada. Para conseguir que el

cubo se mezcle mejor, se ha implementado el algoritmo de forma que, si el giro

generado es un giro en el sentido contrario al anterior, este último se descarta. De este

modo, si el giro generado es un giro U, y el giro que le antecede es un giro U’, se descarta

este último giro U y se calcula otro nuevo. Así evitamos que se hagan giros que no

cambian realmente el estado del cubo, ya que como hemos mencionado anteriormente,

un giro U seguido de un giro U’ deja el cubo en el mismo estado y por lo tanto son giros

redundantes.

Ilustración 54. Cubo mezclado

5.5.10. PRUEBAS

Una vez alcanzado este punto fue indispensable afrontar una serie de pruebas para

comprobar que todo funcionaba correctamente. Hubo varias partes en las que dicha

comprobación era trivial. Un ejemplo serían las pruebas de lectura del parámetro de

entrada con el estado del cubo, o que el estado del cubo producido por los diferentes

giros era el deseado. Sin embargo, la comprobación de los algoritmos de resolución no

resultaba tan fácil.

Como se mencionó anteriormente, el cubo tiene más de 43 trillones de estados posibles,

por lo que probar a resolverlos todos sería prácticamente imposible en cuanto a tiempo,

y bastante complejo en cuanto a implementación. Realmente se podrían eliminar

muchísimos estados del cubo por cuestiones de simetría y cobertura de conjuntos,

resultando en un total de 55.882.296 estados. Pero sigue siendo un número demasiado

alto para testear todas esas posibilidades. Necesitaríamos muchos años para

comprobarlos, o bien una enorme potencia de cálculo para reducir este tiempo.

Se optó por desarrollar un bucle en el que se ejecutase el algoritmo mezclar y

posteriormente todos los algoritmos de resolución. Los resultados se recogieron en

ficheros, y también se implementaron una serie de ficheros adicionales en los que se

anotaron aquellas resoluciones que sufriesen alguna anomalía, como tiempo de


72

resolución o movimientos generados superiores a la media. Gracias a estos ficheros se

pudo depurar pequeños errores.

Se consideró que los algoritmos funcionaban correctamente después de que la

ejecución del bucle descrito anteriormente estuviese varias horas ejecutándose sin

generar ningún fichero de anomalías.

A continuación, se muestra un ejemplo del tiempo que se empleaba en calcular los

movimientos para resolver el cubo:

Ilustración 55. Tiempo prueba PC

El tiempo de resolución en el PC era bastante óptimo. Esto permitía mezclar y resolver

el cubo varias veces en un segundo. Se alcanzaban cifras de más de 20 cubos por

segundo, por lo que en un minuto podía llegar a realizar 1.200 resoluciones, y en una

hora 72.000. Estas cifras eran bastante inferiores cuando se ejecutaba el programa en

la Raspberry, pero como solo se trataba de comprobar que las resoluciones eran

correctas, se hicieron todas las pruebas en el PC.

A continuación, se muestra un ejemplo del tiempo que tarda la Raspberry en realizar

una resolución.

Ilustración 56. Tiempo prueba Raspberry

El PC en el que se realizaron las pruebas presenta las siguientes características:

- Modelo: Dell XPS L502X.

- SO: Windows 10 Home

- Procesador: Intel Core i5-2520M CPU de 4 núcleos que operan a una frecuencia de

2.50GHz y caché de 3 MB.

- RAM: 4 GB DDR3.

La Raspberry Pi presenta las siguientes características:

- Modelo: Raspberry Pi 3 modelo B+.

- SO: Raspbian GNU/Linux 9 (stretch).

- Procesador: Broadcom BCM2837B0 de 4 núcleos que operan a una frecuencia de

1.4GHz y cache de 0,5 MB.

- RAM: 1 GB LPDDR.

73

Para detectar las anomalías de las diferentes ejecuciones, se establecieron unos

márgenes inferiores y superiores de tiempo y movimientos. Para ello se calculó la media

de tiempo y movimientos de 1000 resoluciones. Posteriormente se calculó la máxima

desviación que se producía entre los tiempos y movimientos de estas 1000 ejecuciones

y la media. Esta desviación se utilizó para comprobar que estas ejecuciones eran

correctas, y calcular los márgenes que se iban a establecer. En cuanto al margen superior

de tiempo también se usó como límite de tiempo de las ejecuciones para evitar el

escenario en el que la resolución fallase y cayese en un bucle infinito. Cuando alguna

ejecución presentaba unos valores fuera de los márgenes, se detenía con el fin de no

generar más datos de los necesarios para detectar el fallo. Posteriormente se

almacenaban todos los datos de dicha ejecución en los correspondientes ficheros de

anomalías. Estos ficheros contenían todos los estados del cubo durante la ejecución, así

como los movimientos y tiempos obtenidos en cada uno de los algoritmos de resolución.

Afortunadamente no se obtuvieron demasiados fallos más allá de alguna situación poco

frecuente que hacía que la resolución entrase en un bucle infinito.

5.5.11. FICHEROS

Se han implementado dos formas de generar ficheros.

La primera sería un log general en el que se detallan todos los sucesos o eventos que

ocurren en el robot. Cada entrada del fichero constaría de la hora y fecha en la que se

produjo dicho evento y una breve descripción de este.

Ilustración 57. Log


74

La segunda se trata de un fichero realizado después de cada ejecución del robot. Este

fichero recibe como nombre la fecha y hora de la ejecución. Además, contiene un

documento con todos los detalles de la ejecución, y una carpeta con información

relacionada con las fotografías realizadas por las cámaras y la extracción de colores del

cubo.

Ilustración 58. Fichero ejecución

Ilustración 59. Fichero imágenes

75

Ilustración 60. Documento ejecución

5.5.12. SCRIPTS

Los scripts se han desarrollado en Python. La función de estos en gran medida consiste

en controlar el hardware del robot, y se podría resumir en 4 partes.

- Recibir y actuar ante las órdenes que le proporciona el usuario mediante los botones.

- Proveer los datos que necesita el programa de resolución.

- Aplicar los giros calculados por el programa de resolución al cubo.

- Calibrar ciertos aspectos del robot

Los componentes hardware que controlarían dichos scripts serían los botones, los leds,

las cámaras, los motores y el altavoz.

A continuación, se listan los scripts creados.

- Script botón pulsado: este script debe ejecutarse cuando se inicie la Raspberry Pi.

Su función será crear un evento por cada botón de control del robot. Dependiendo

del botón pulsado, se le pasará un parámetro a la aplicación Java con la operación a

realizar, o bien apagará la Raspberry Pi. Además, ejecutará un bucle en el que se

abrirán las cámaras para que capturen algunos frames cada cierto número de


76

segundos. Con esto conseguimos que cuando se pulse uno de los botones (excepto

el de apagar), las cámaras ya hayan enfocado y ajustado ciertos parámetros como el

brillo, de modo que la fotografía se tomará más rápido que si tuviese que hacer

todos esos ajustes cuando se pulse el botón. Una vez se pulse un botón, se para este

bucle para que queden libres las cámaras y puedan tomar las fotografías. Tras

finalizar la operación, se reactiva el bucle de las cámaras.

A este script se le añadió una nueva funcionalidad para solventar un desvío de los

motores cuando son conectados a la corriente. Dicho problema se detalla más

adelante. Esta nueva funcionalidad se lleva a cabo por dos botones y ocho leds. El

primer botón nos permite seleccionar el motor que se va a girar, así como el sentido

en el que lo hará, y el segundo botón aplicará el giro. Para indicar al usuario que

motor y sentido de giro ha seleccionado se usan los leds.

- Script tomar fotos: cuando se ejecuta este script, este les indica a las dos cámaras

conectadas a la Raspberry Pi que realicen una fotografía y posteriormente las

almacena en la ruta especificada. Se usan dos procesos, uno para cada cámara con

el fin de que ambas cámaras funcionen simultáneamente. Se han configurado los

siguientes parámetros para facilitar la extracción de colores.

Ilustración 61. Parámetros cámaras

A continuación, se detallan los parámetros más relevantes:

La resolución es la más alta que permiten las cámaras, que son HD, es decir

1920x1080.

Se ha configurado para que descarten los 20 primeros frames que capturen, de

modo que el obturador de la cámara esté estabilizado antes de tomar la foto.

La foto se construye a partir de los 10 frames siguientes de los 20 descartados, para

conseguir una mayor calidad.

La saturación de color se ha establecido al máximo para que se realce lo máximo

posible la tonalidad de los colores.

La compensación de luz (backlight) se ha establecido al máximo para que las fotos

no se quemen por la luminosidad que desprenden los leds.

Establecemos el balance de blancos al máximo para que los colores del cubo se vean

lo más similares posibles a cómo los ve el ojo humano en condiciones de luz natural.

- Script leer colores: este script hace uso de la biblioteca de visión artificial OpenCV.

Su función es extraer el estado del cubo a partir de las dos imágenes proporcionadas

por las cámaras. Se ha implementado para que obtenga el estado del cubo

77

independientemente de los colores que tenga este. Posteriormente genera un

fichero de texto con dicho estado, que será el que utilice el programa de resolución

del cubo.

Las siguientes imágenes simularían las fotografías que realizarían las cámaras

al cubo.

Cámara 1 Cámara 2

Ilustración 62. Vista de las cámaras

El algoritmo del script calcula la media de color de una zona de cada cuadrado.

Las siguientes imágenes mostrarían el color resultante de haber extraído la media

de color de cada cuadrado del cubo.

Cámara 1 Cámara 2

Ilustración 63. Medición de los colores


78

Posteriormente se pasarían estos colores calculados en el paso anterior por un

algoritmo de agrupación, de manera que se organizasen cada uno de los 54 colores

en seis grupos (uno por cara) de 9 componentes cada uno. Cada uno de estos grupos

o caras del cubo, se identifica con un número del 0 al 5.

Cámara 1 Cámara 2 Resultado

CaraU 1 1 5 1 0 1 5 5 0 CaraF 2 3 1 4 3 0 3 4 2 CaraR 4 0 4 2 2 1 3 5 3 CaraD 4 5 0 3 5 2 2 3 4 CaraB 1 2 0 4 1 3 5 0 5 CaraL 2 5 1 4 4 0 3 2 0

0 – Amarillo 1 – Naranja

2 – Azul 3 – Rojo

4 – Verde 5 – Blanco

Ilustración 64. Parámetros extraídos del cubo

Finalmente, estos grupos son lo que se pasan como parámetros.

- Script motores: este script es el encargado de transmitir los giros a cada uno de los

seis motores. Recibe como parámetro una lista de giros, y los va aplicando

secuencialmente a los motores. Solo funcionará un motor en cada giro que se aplica

al cubo, excepto si dos giros seguidos son de caras opuestas. En ese caso, será capaz

de hacer girar dos motores simultáneamente.

A continuación, se muestra un esquema muy general de la estructura el software:

Ilustración 65. Esquema software

5.6. ESTRUCTURA FÍSICA

Para realizar la estructura física del robot, se realizaron diferentes prototipos en papel.

Estos prototipos estaban orientados a definir la forma que tendría la estructura y

estaban basados en otros robots desarrollados previamente. Se diseñó una estructura

79

compuesta por tres anillos que encajarían formando una esfera, en cuyo centro se

situaría el cubo. Los motores se localizarían en las intersecciones de los tres anillos.

Posteriormente se cambió la forma de los anillos a cuadrados para poder situar las

cámaras más alejadas del cubo y que pudiesen fotografiarlo entero. En la parte inferior

de esta estructura que sostiene las cámaras y los motores, se colocaría una plataforma

sobre la que se montarían los diferentes componentes hardware. Esta plataforma

tendría acoplada una pequeña estructura que contendría los botones de control del

robot.

El siguiente paso fue diseñar las piezas de la estructura mediante el software de diseño

3D Tinkercad. Se planteó que las piezas encajasen mediante pestañas o ranuras, de

modo que fuese desmontable a la par que rígido y robusto. El grosor de las piezas es de

4 mm.


80

Ilustración 66. Estructura física

Finalmente se generaron las piezas que componían la estructura en formato vectorial

SVG para poder traducirlo posteriormente a G-code, que es el lenguaje que maneja la

máquina de corte láser.

5.6.1. CORTADORA LASER CNC

El corte láser es una tecnología que utiliza un láser para cortar materiales. Inicialmente

su uso estaba presente en aplicaciones de fabricación industrial, pero actualmente se

ha generalizado y está presente en pequeñas empresas y escuelas o incluso en hogares.

El modo de funcionamiento consiste en conducir el haz de un láser de alta potencia por

medio de espejos y lentes. Estas lentes y espejos junto con el CNC (control numérico por

computadora) dirigen el material o el rayo láser para cortar el material. El rayo láser

funde, quema o evapora el material de corte, dejando un acabado superficial de alta

calidad y proporcionando una precisión de corte milimétrica.

Se ha utilizado una cortadora láser CNC para obtener las piezas que forman la estructura

del robot a partir de láminas de pocos milímetros de grosor. Para ello, se diseñaron las

piezas y posteriormente se generó el G-code de estas, que es lo que la cortadora

necesita para operar.

Ilustración 67. Máquina corte laser CNC

81

Los planos de corte serían los de las siguientes imágenes.

17 piezas – Material opaco 1

Ilustración 68. Plano corte material opaco 1


82

54 piezas – Material opaco 2


83

143 piezas – Material transparente

Ilustración 70. Plano corte material transparente 1


84

16 piezas – Material transparente

Ilustración 71. Plano corte material transparente 2

Una vez construido el robot, se podía apreciar que cuando se enchufaba y los motores

recibían la corriente, estos últimos se desplazaban ligeramente hacia su posición home.

Esta desviación era muy pequeña pero lo suficiente como para que se vea a simple vista.

Los motores poseen 200 pasos por vuelta, lo que resulta en una precisión de 1,8 grados

en su configuración full step (360 grados / 200 pasos = 1,8 grados). Si el motor se

encuentra en una posición entre dos de los pasos, al recibir la corriente se moverá a

aquel que tenga más cerca, resultando en una desviación máxima de 0,9 grados (1,8

grados / 2 = 0,9 grados). Esto se debe a que cuando el pin de RESET del driver recibe

85

LOW, se resetea la lógica interna y la tabla de pasos a la posición inicial.

Desgraciadamente no se puede configurar que los motores funcionen en alguna

configuración de microstepping nada más ser enchufados, lo que nos daría una precisión

mucho mayor que 1,8 grados. Para solventar este problema se desarrolló una nueva

estructura que albergaría dos botones y ocho leds. La finalidad de esta sería poder

realizar giros muy leves con la configuración de microstepping aplicada, y de este modo

poder alinear el cubo. Por falta de tiempo no se pudo realizar esta estructura con corte

laser, que hubiese sido lo óptimo. Para construirla se utilizó el mismo material de la base

del robot, y se hicieron los cortes y perforaciones con herramientas manuales como

sierra y taladro. De todos modos, se crearon los planos para poder crear esta estructura

mediante corte laser.

6 piezas – Material opaco


5.6.2. METACRILATO Y MADERA

En cuanto al material se barajaron varias posibilidades. Tendría que ser un material

sólido, rígido, robusto, resistente al calor generado por el hardware y que fuese apto

para el corte láser. En un principio se optó por la madera, por ser un material muy

económico y que cumplía los requisitos anteriormente mencionados, pero se descartó

por el hecho de ser opaco. Construir la parte superior del robot con un material

transparente permitiría visualizar mucho mejor el proceso de resolución del cubo, por

lo que se optó por buscar un material que cumpliese los requisitos anteriores y además

fuese transparente. Finalmente se optó por el metacrilato incoloro transparente, una

opción más cara que la madera, pero que permite visualizar el interior del robot desde

cualquier ángulo. La parte inferior de la estructura donde se aloja la gran mayoría del

hardware podría ser opaca, por lo que se podría optar por madera o bien metacrilato

opaco de colores. Tras barajar diferentes materiales se optó por el contrachapado

calabó, por sus cualidades ignífugas, hidrófugas, ligereza, robustez, estética y precio

económico.

Como hemos mencionado, la estructura del robot se divide en dos partes, la superior de

metacrilato y la inferior de madera. La parte superior sería la que sostendría las cámaras,


86

los motores y por lo tanto el cubo de rubik. La parte inferior albergaría la fuente de

alimentación, la Raspberry y la circuitería.

Parte superior:

Ilustración 73. Parte superior

Parte inferior:

Ilustración 74. Parte inferior

87

Parte superior e inferior:

Ilustración 75. Parte superior e inferior

Cabe resaltar que una vez cortadas las piezas con la cortadora laser CNC surgió un gran

problema con la madera y en menor medida con el metacrilato. El problema de la

madera es que con los cambios de humedad y temperatura puede llegar a cambiar su

grosor, de manera que si absorbe humedad se hincha y si la pierde se contrae. Dicho

problema apareció cuando a la hora de ir a montar todas las piezas de contrachapado,

el grosor de estas había pasado de 4 a 4,5 milímetros, haciendo que no encajasen, por

lo que hubo que lijar a mano todas las pestañas y partes de unión que no encajaban

correctamente. En el caso del metacrilato, había algunas zonas en las que variaba

mínimamente el grosor, pero mucho menos que en el caso de la madera, por lo que

hubo que lijarlas muy ligeramente. Este proceso llevo muchas horas, y se podría haber

evitado si se hubiese construido la parte inferior del robot (la de contrachapado) con

otro tipo de madera o material, probablemente los tableros MDF se vean menos

afectados por la humedad, y el metacrilato u otros materiales derivados del plástico

erradicarían este problema por completo.


88

5.7. HARDWARE Y COMPONENTES FÍSICOS

El esquema hardware de todos los componentes del robot sería el siguiente.

Ilustración 76. Boceto hardware

5.7.1. FUENTE DE ALIMENTACIÓN

Este dispositivo convierte la corriente alterna (CA) en una o varias corrientes continuas

(CC). Se utiliza para alimentar los circuitos del dispositivo electrónico al que se conecta.

Se ha utilizado una fuente de alimentación de un PC antiguo para suministrar la

electricidad que necesitan los diferentes elementos del robot como pueden ser la

Raspberry Pi, los leds y los motores.

Cabe destacar que como solo utilizaremos la conexión ATX de la fuente de alimentación,

hemos cortado todos los otros cables que no usaremos como el PCIe, el molex, SATA…,

ya que quedarían sueltos y estorbarían a la hora de conectar todos los componentes

necesarios. Después de cortar dichos cables es muy importante aislar la punta de estos

para que nunca se lleguen a tocar entre ellos, lo que podría causar graves daños sobre

la fuente de alimentación haciendo que quede irreparable. Se pueden aislar con cinta

aislante y asegurarse de que no se va a mover ni a despegar con el paso del tiempo y el

calor generado dentro de la fuente mediante el uso de bridas.

89

Ilustración 77. Fuente de alimentación

5.7.2. MODULO ADAPTADOR DE CORRIENTE ATX

Para adaptar la corriente suministrada por el cable ATX de la fuente de alimentación se

ha utilizado un modulador de corriente, el cual al conectarlo al cable ATX nos

proporciona 4 canales de voltajes de 3,3, 5, 12 y -12 voltios. Cada canal está dotado de

un fusible de 5 amperios y de una conexión a tierra.

Ilustración 78. Adaptador de corriente ATX

Esta placa está diseñada para conectarle el cable ATX de 24 pines. Esta conexión es la

estándar en las fuentes de alimentación actuales, pero en las antiguas el estándar para

dicha conexión era de 20 pines. Esto se soluciona fácilmente con un adaptador de 20

pines hembra a 24 pines macho. Para facilitar el montaje del resto de componentes y

mejorar la estética del cableado, podemos introducir dicho adaptador en la fuente de

alimentación, ya que al haber cortado el resto de los cables innecesarios tenemos


90

espacio de sobra para almacenarlo en su interior y que simplemente salga el cabezal de

24 pines macho del adaptador.

Ilustración 79. Adaptador de 20 a 24 pines ATX

5.7.3. RASPBERRY PI

Ordenador de placa reducida o simple (SBC) desarrollado por la organización británica

Raspberry Pi Foundation. La idea original de la fundación fue estimular la enseñanza de

informática en los centros educativos, pero su inesperada popularidad hizo que se

ampliase la clientela más allá del mercado objetivo planeado inicialmente. Se ha

utilizado ampliamente en proyectos de robótica. El sistema operativo oficial es una

distribución de Debian llamada Raspberry Pi OS, aunque permite la instalación de

múltiples sistemas operativos como Windows 10, Ubuntu, Kali, Android….

El modelo elegido ha sido la Raspberry Pi 3 modelo B+, que es un ordenador de placa

reducida dotado de los siguientes componentes:

- Procesador de cuatro núcleos a 1,4 GHz de 64 bits.

- 1 GB de SDRAM

- LAN inalámbrica de 2,4 GHz y 5GHz y Bluetooth 4.2

- Cabecera GPIO extendida de 40 pines

- 4 puertos USB 2.0.

- Puerto HDMI

- Puerto CSI para conectarse a la cámara Raspberry Pi

- Puerto DSI para conectarse a la pantalla táctil de Raspberry Pi

- Puerto Micro SD para cargar el sistema operativo y almacenar datos

- Entrada de alimentación de 5V / 2,5 A DC

- Compatibilidad con alimentación por Ethernet

Los principales motivos para elegir este modelo de la Raspberry Pi son la cabecera GPIO

extendida de 40 pines, ya que se necesita un gran número de pines para conectar todos

los componentes del robot, el procesador de cuatro núcleos que ayudara a reducir los

tiempos de obtención de movimientos que resuelven el cubo, los puertos usb que

permiten conectar las cámaras, y que se adapta a todas los requisitos que se plantean.

91

Ilustración 80. Raspberry Pi 3 modelo B+

Ilustración 81. Raspberry Pi 3 modelo B+ componentes

5.7.4. CÁMARAS USB

Se necesitan dos cámaras para que cada una sea capaz de fotografiar 3 de las 6 caras del

cubo, de modo que, si realizan una fotografía simultáneamente, podamos extraer el

estado completo del cubo. Se barajo la posibilidad usar la Raspberry Pi Camera, la cual

se conecta al puerto CSI de la Raspberry Pi y tiene un precio razonable. Esta opción fue

descartada porque la Raspberry Pi solo tiene un puerto CSI y se necesitarían dos para

poder conectar dos cámaras, por lo que sería necesario utilizar algún tipo de hardware

adicional como un multiplexor, que permite conectar varias cámaras a un único puerto

CSI. El problema de usar un multiplexor es que necesita hacer uso de un gran número

de pines de la Raspberry Pi, y no quedarían libres los pines suficientes como para

conectar el resto de los componentes del proyecto, como los drivers, motores, leds o

botones. Por este motivo se planteó la alternativa de utilizar los puertos USB para

conectar un par de webcams.


92

Ilustración 82. Webcam USB

5.7.5. ALTAVOZ DE PC

Se ha implementado un altavoz integrado de un PC antiguo, que funciona igual que un

zumbador pasivo como los que se suelen usar en proyectos de Raspberry y Arduino, solo

que tiene un tamaño mayor y por lo tanto su volumen en términos de decibelios también

es mayor. Este altavoz funciona con accionamiento magnético (dinámico), hoy en día se

usan altavoces de hierro móvil o piezoeléctricos, por lo que no es fácil encontrarlos a

menos que se tenga un PC antiguo, por lo que se puede sustituir por un zumbador pasivo

sin necesidad de hacer ningún cambio en el hardware ni software. Un zumbador pasivo

es un dispositivo que permiten transformar una señal eléctrica en ondas de sonido. El

tono varía dependiendo de la corriente eléctrica que se le aplica. En los zumbadores

activos, el tono es siempre el mismo, mientras que en los pasivos encontramos un

oscilador interno que nos permiten variar el tono emitido, por lo que pueden generar

melodías. Para que estos dispositivos puedan emitir diferentes tonalidades, es necesario

el uso de señales analógicas, ya que en las digitales solo tenemos dos opciones, como

por ejemplo encender un led o apagarlo, pero no regular su intensidad. Para solucionar

este problema se usan las señales PWM (Pulse Width Modulation/Modulación por

ancho de pulsos). La Raspberry nos ofrece tres formas de crear estas señales PWM, una

de ellas requiere de un periférico especifico y las otras dos serian mediante software y

hardware. El PWM software se puede realizar en todos los pines disponibles, mientras

que el PWM hardware solo en unos pocos que están diseñados para ello, en nuestro

caso sería el GPIO 12, 13, 18 y 19. El PWM hardware es más preciso y flexible que el

software, por lo que es preferible conectar el altavoz o zumbador a estos pines.

Ilustración 83. Altavoz PC

93

5.7.6. NEMA 17

NEMA (National Electrical Manufacturers Association) define un conjunto de estándares

utilizados para definir las tolerancias de muchos productos, como pueden ser los

motores paso a paso. Según el estándar definido por NEMA, los motores paso a paso se

clasifican según el tamaño de cuadro, habiendo estándares que van desde tamaño 8

hasta 66. Un motor paso a paso de tamaño 17 se traduce en que la cara de montaje del

motor es de 1,7 pulgadas cuadradas. Estos estándares proporcionan la posibilidad de

cambiar de un fabricante a otro sin tener que cambiar significativamente los soportes

de montaje o acoplamientos, aunque hay ciertos factores como la longitud o el diámetro

del eje que sí que pueden variar entre fabricantes.

Los motores paso a paso son dispositivos electromecánicos que transforman impulsos

eléctricos en desplazamientos angulares discretos. En concreto los motores NEMA

tienen 1,8 grados por paso (200 pasos por vuelta). La gran ventaja de este tipo de motor

es la precisión y repetitividad en cuanto al posicionamiento. Poseen una gran variedad

de aplicaciones como brazos robóticos, apertura de puertas, impresoras 3D….

Ilustración 84. Nema 17

5.7.7. ACOPLADOR NEMA 17

Los acopladores flexibles sirven para eliminar el estrés entre el motor y el componente

de conducción, generalmente están fabricados en aluminio y proporcionan un agarre

firme sin dañar el eje del motor ni del componente de conducción. Para ajustarlos es

necesaria una llave Allen del tamaño adecuado.

Ilustración 85. Acopladores Nema 17


94

5.7.8. BARRAS ROSCADAS Y TUERCAS CUADRADAS

Para conectar los acopladores a las diferentes caras el cubo se ha usado barras roscadas

y tuercas cuadradas, ambas de rosca métrica M5 fabricadas en acero. La longitud de las

barras debe estar entre 10 y 11 centímetros, y las tuercas cuadradas deben ser de 15

milímetros de ancho para que encajen en las piezas centrales del cubo. Dependiendo

del diseño de la pieza central del cubo es posible que haya que lijar las esquinas de la

tuerca cuadrada. Para que la unión de la barra roscada y la tuerca se quede fija y ambas

pasen a ser una única pieza sólida, se ha utilizado soldadura metálica en frio.

Barras roscadas Tuercas cuadradas Soldadura fría

Ilustración 86. Barras, tuercas y soldadura

El resultado sería el siguiente:

Ilustración 87. Barra roscada y tuerca

5.7.9. POLOLU DRV8825

Se trata de un controlador de motores paso a paso bipolares que es ampliamente usado

por su relación calidad precio. Posee las siguientes características:

- Limitación de corriente ajustable.

- Protección contra sobreintensidad.

- Protección contra sobretemperatura.

- 6 resoluciones para microstep (hasta 1/32 por paso).

- Funciona de 8,2 V a 45 V.

- Suministra hasta 1,5 A por fase sin disipado de calor.

- Suministra hasta 2,2 A por fase si se le proporciona suficiente enfriamiento.

95

Ilustración 88. DRV8825

5.7.10. CABLES, RESISTENCIAS, CONDENSADORES, LEDS, BOTONES

Los cables eléctricos proporcionaran la electricidad a todos los componentes que la

necesiten. Es recomendable asegurarse que la resistencia de los cables soporte la

tensión eléctrica que han de conducir, sobre todo los que salen de la fuente de

alimentación que llevaran 12 voltios. también es recomendable el uso de clemas para

aportar solidez a las diferentes conexiones y aislantes eléctricos como fundas

termoretráctiles o cinta aislante.

Las resistencias protegerán diferentes elementos del circuito como leds o botones.

Utilizaremos resistencias de diversos ohmios dependiendo el voltaje que se le aplique a

los diferentes componentes.

Los condensadores aseguraran una alimentación más estable a los motores, es

importante tener en cuenta la polaridad de estos. Utilizaremos condensadores de 100

microfaradios.

Los botones indicaran la operación que debe realizar el robot, siendo el principal medio

de control del robot.

Cables Resistencias Condensador Leds Botón

Ilustración 89. Componentes electrónicos

5.7.11. PROTOBOARD

Se utiliza una placa de pruebas para realizar el circuito del robot. Sobre la placa de

pruebas se conectan los diferentes pines de la Raspberry Pi, controladores de los

motores, leds, botones, condensadores y resistencias.


96

Esta protoboard tiene 830 puntos de unión sin soldadura y está fabricada en plástico

ABS blanco. La temperatura de distorsión de dicho material es de 84 grados centígrados.

La placa resiste hasta 36 voltios y 2 amperios, por lo que podremos conectar en ella todo

el circuito a excepción de la corriente suministrada por la fuente de alimentación a los

motores, que podría dañarla ya que esta será de 12 voltios y hasta 3,4 amperios.

Ilustración 90. Protoboard

5.7.12. ENCABEZADOS APILABLES

Como se ha mencionado anteriormente, la protoboard no está diseñada para resistir el

amperaje que van a requerir los motores, por lo que tendremos que conectar todos los

pines del driver a la protoboard excepto los de VMOT y GND que recibirán una corriente

de 12 V.

Ilustración 91. Pines VMOT y GND

Para poder dejar libres esos dos pines se han usado unos encabezados apilables que se

suelen usar para la placa Arduino.

Ilustración 92. Encabezados apilables

97

De este modo conectaríamos los pines de los encabezados a la protoboard y nos

quedarían libres los pines VMOT y GND del driver para poder conectarlos directamente

a la fuente de alimentación. Conectaríamos el encabezado de 6 pines en el lateral que

contiene los pines VMOT y GND y el de 8 pines en el otro lado.

Encabezado de 6 pines Encabezado de 8 pines

Ilustración 93. DRV8825 con encabezados apilables

5.7.13. TIRAS LED Y PERFILES

Las tiras led son una buena elección frente a otro tipo de componentes a la hora de

iluminar debido a su bajo consumo eléctrico y su larga vida útil. Otra gran ventaja es la

flexibilidad de estas tiras y que se puede ajustar su longitud al tamaño deseado. Estas

tiras pueden ser de diversos tipos, variando desde el número de leds por metro, su

consumo, su color….

En nuestro caso hemos elegido una tira led de 5V y 60 leds por metro. En total se han

usado algo menos de 5 metros. En cuanto al color se optó por un blanco cálido (2800 a

3500 Kelvin), aunque lo ideal habría sido escoger un blanco neutro o frio ya que es el

que mejor resalta los colores reales. El blanco cálido produce un tono amarillento o

anaranjado sobre la superficie que se proyecta, y el blanco frio un tono azulado, siendo

el blanco neutro el que más se asemeja a la luz del día natural, y por lo tanto el que

menos distorsión produce sobre los colores del cubo. En resumen, un blanco neutro

hubiera facilitado la lectura de los colores del cubo.

Para contrarrestar este efecto anaranjado producido por los leds de color blanco cálido,

se han diseñado unos filtros que tienen una doble funcionalidad. Por un lado, cambian

la temperatura de la luz y por el otro mejoran la función del difusor. Estos filtros se han

realizado con papel celofán de color azul. En el mundo de la fotografía y el cine es muy

común el uso de filtros de iluminación CTB y CTO para equilibrar la temperatura de color.

La temperatura de color se mide en grados Kelvin y en las tiras leds puede ir desde los

2700 K (blanco cálido) a 6500 K (blanco frio). Con dichos filtros podemos cambiar la

temperatura de la luz. El filtro CTB es de color azul y aumenta la temperatura de la luz,

y el filtro CTO es de color naranja y la disminuye. Una solución muy económica para

imitar los filtros CTB y CTO es el papel celofán, ya que posee unas características muy


98

similares, por lo que se optó por imitar el filtro CTB con papel celofán de color azul. Estos

filtros además mejoran la función del difusor, haciendo que la intensidad de luz sea más

homogénea y provoque menos brillos y reflejos en la superficie del cubo, ya que las

pegatinas y materiales que se usan para su fabricación son plásticas y reflejan la luz, lo

que puede conducir a errores a la hora de extraer los colores del cubo.

En cuanto a los perfiles y difusores, se han cortado a medida con una radial para que

encajen dentro de los anillos cuadrados de metacrilato. También se han utilizado unos

conectores en forma de T con mecanismo de pestañas para conectar las distintas tiras

de led

Tira Led Perfil y difusor Conector Celofán azul

Ilustración 94. Leds

5.7.14. CUBO DE RUBIK

El cubo de Rubik será el estándar de 56 milímetros por cara, y no importaran los colores

siempre que estos no sean demasiado parecidos entre ellos. Cabe destacar que no todos

los cubos permiten girar sus caras desde la pieza central, esto depende del diseño de las

piezas que lo componen, pero hay una gran variedad de diseños que lo permiten.

Para acoplar el cubo a los motores, se debe perforar la pieza central con un grosor igual

o ligeramente superior al de la barra roscada de métrica M5 y posteriormente introducir

la barra roscada con la tuerca ya soldada.

Ilustración 95. Centros perforados

Gracias a este sistema para acoplar el cubo a los motores, la pieza central sigue

quedando visible y por lo tanto puede ser recogido su color por las cámaras. Esta ventaja

99

permite que las cámaras lean el cubo independientemente de su orientación y de los

colores que tenga el mismo. En algunos de los robots que se han desarrollado hasta la

actualidad, la pieza central queda oculta, lo que hace que el cubo deba tener unos

colores predefinidos, y que solo pueda estar orientado en una posición para su correcto

funcionamiento.

Centros no visibles Centros visibles

Ilustración 96. Centros visibles y no visibles

5.8. CONEXIONES DE LA RASPBERRY

Para realizar un prototipo de diseño hardware realista se utilizó la herramienta software

Fritzing, que posibilitó diseñar todas las conexiones de los diferentes componentes.

También permitió la asignación de los diferentes pines de la Raspberry Pi, así como los

pines de los controladores DRV8825.


100

Ilustración 97. Esquema hardware

La fuente de alimentación se conectaría a la Raspberry Pi, a las tiras led y a los motores.

El voltaje aplicado a los motores es de 12V, mientras que a las tiras led y a la Raspberry

es de 5V.

A continuación, se muestra una lista detallada de todos los componentes que se han

usado en el prototipo:

Ilustración 98. Componentes hardware

Estos materiales no coinciden exactamente con los que se han usado en el diseño físico

final por cuestiones de limitación del software Fritzing, pero se aproximan bastante. Por

ejemplo, la iluminación con tiras led se ha representado con el objeto incandescent light

bulb que es una bombilla.

El esquema de conexiones de los pines de la Raspberry Pi sería el siguiente:

101

Ilustración 99. Pines Raspberry Pi

Como se puede ver en la imagen anterior, hemos utilizado la totalidad de los pines GPIO

de la Raspberry. Estos son los encargados de controlar los leds, botones, altavoz y drivers

de los motores. Tanto los botones, como los leds y las entradas step y reset de los drivers

reciben un voltaje de 3,3 V, mientras que el registro de desplazamiento 74HC595 (GPIO

10 / 9 / 11 – Data / Latch / Clock) recibe 5 V. Dicho registro de desplazamiento permite

controlar un total de 8 leds con solo 3 pines GPIO. Sin este registro, necesitaríamos un

pin por led, resultando en 8 pines GPIO.

La notación de los motores se corresponde con la cara del cubo que tienen que girar. Es

decir, el motor U aplicará giros sobre la cara U del cubo, el motor F sobre la cara F, y así

sucesivamente. Vemos que se utilizan dos pines por cada motor, que corresponden a

step y direction, y dos pines para microstep que comparten los seis motores. Estos pines

no se conectan directamente al motor, sino que se conectan al controlador del motor,

que en nuestro caso es el DRV8825. El esquema de conexión del controlador DRV8825

sería el siguiente:


102

Ilustración 100. Conexiones DRV8825

El esquema de conexión del resto de los componentes sería el siguiente:

Ilustración 101. Conexiones componentes

103

Esta configuración de los drivers no fue la elegida en un principio, ya que en las primeras

versiones no se implementó el microstepping. Se utilizaba el pin enable, y el pin de step

usaba un único pin de la Raspberry que compartían todos los drivers. No se barajó la

opción de hacer microstepping debido a que los giros que tienen que realizar los

motores son de 90º, por lo que no hacía falta una enorme precisión para realizarlos.

Pero, sin esta opción, los motores producían muchas vibraciones y ruido, lo que hacía

que temblara toda la estructura de metacrilato produciendo todavía más ruido. Una vez

implementado el microstepping, los motores iban mucho más suaves y fluidos. En

cuanto a los pines enable y step, en principio se pensó que era mejor que los motores

compartieran la señal de step, y que se activasen mediante el pin enable. Sin embargo,

el hecho de estar encendiendo y apagando el driver mediante el pin enable producía

que tuviesen un pequeño delay, resultando en una pequeña pérdida de pasos en cada

giro. Por ello, se decidió dejarlos siempre encendidos e indicar que driver debe de

funcionar en cada momento estableciendo su correspondiente pin de step a HIGH o

LOW. En cuanto a los pines de microstepping, en un principio se utilizaban los tres que

el driver ofrece para realizarlo. En realidad, solo hay una configuración de microstepping

que necesite tres pines, el resto de las configuraciones requiere uno o dos pines, ya que

dejar el pin sin conectar equivale a enviar una señal LOW. Por esto, tras seleccionar la

configuración que íbamos a usar definitivamente, que requiere dos pines en vez de tres,

se liberó un pin de la Raspberry que podría usarse para otras finalidades.

5.8.1. CALIBRACIÓN DEL DRIVER

El driver o controlador DRV8825 debe calibrarse para un correcto funcionamiento. Esta

calibración consiste en limitar la corriente que va a pasar por el driver para que no

resulte dañado y proporcione la alimentación adecuada a los diferentes motores. Para

ello, se utiliza el pequeño tornillo llamado potenciómetro que incorpora en su superficie.

Además, se necesita un multímetro para medir la tensión existente entre GND y el

potenciómetro.

Ilustración 102. Potenciómetro DRV8825

Para realizar esta calibración, se debe conectar el controlador a la tensión de

alimentación, pero no a los motores. Posteriormente se comprueba la tensión entre

GND y el potenciómetro con el multímetro, y con un destornillador se va girando el

potenciómetro hasta obtener la tensión deseada. Una vez hecho esto, ya se puede


104

conectar el motor. Para hacerlo de manera segura debemos desenchufar la

alimentación y volver a enchufarla una vez conectado el motor. Tras realizar los pasos

anteriores, se puede hacer un ajuste más preciso del potenciómetro midiendo la

intensidad con el multímetro entre el driver y el motor. Finalmente se vuelve a

desenchufar la alimentación para conectarlo a la Raspberry Pi.

Para calcular el voltaje al que se debe ajustar el potenciómetro del controlador, se usa

la fórmula que aparece en la hoja de especificaciones del driver.

Current Limit = VREF x 2

Los NEMA 17 escogidos son de 1,7 A/fase, por lo que habría que limitar el controlador a

este valor. Para valores superiores a 1,5 A/fase se debe proporcionar algún tipo de

refrigeración al controlador, por lo que le añadiremos un disipador de aluminio para

poder manejar estos valores.

1,7 A = VREF x 2

VREF = 0.85 V

En las especificaciones del controlador también aparece una tabla para las diferentes

configuraciones de stepping.

Mode2 Mode1 Mode0 Step Mode

0 0 0 Full step 71% current

0 0 1 ½ step

0 1 0 ¼ step

0 1 1 8 microsteps/step

1 0 0 16 microsteps/step

1 0 1 32 microsteps/step Ilustración 103. Configuración stepping DRV8825

Los valores de las columnas Mode2, Mode1 y Mode0 serían el valor HIGH o LOW

proporcionado a los pines del controlador M2, M1 y M0. En nuestro caso, vamos a usar

estos pines del controlador, por lo que no utilizaremos la configuración full step. Vemos

que en la tabla indica que para esta configuración la corriente máxima debe ser del 71%.

VREF = 0,71 x 0,85 = 0,6V

Por tanto, deberíamos aplicar un voltaje máximo de 0,6 V por fase. En nuestro caso sí

que vamos a realizar microstepping por lo que utilizaríamos el 100% de la corriente y

aplicaríamos 0,85V por fase.

En cuanto a los pines del controlador se han usado los descritos a continuación:

- RESET: cuando recibe LOW, resetea la lógica interna y la tabla de pasos a la posición

inicial. La entrada STEP se ignora mientras RESET esté a LOW.

- SLEEP: cuando recibe LOW, el controlador entra en un estado de reposo de baja

potencia. En este estado, se ignoran todas las entradas hasta que se reciba HIGH.

105

Para que funcione el controlador, tanto RESET como SLEEP deben establecerse a

HIGH.

- STEP: cada pulso que recibe este pin se corresponde con un paso del motor.

- DIR: esta entrada, en función de si recibe HIGH o LOW, hará que el motor gire en un

sentido u otro.

- VMOT y GND: el driver necesita una tensión para alimentar el motor que va de 8,2

a 45 V y se conecta a través de VMOT y GND. Este suministro debe tener un

condensador adecuado para suministrar la corriente esperada por el motor,

proporcionando un voltaje continuo sin picos de corriente. En nuestro caso,

aplicaremos una tensión de 12 V y aplicaremos un condensador de 100

microfaradios entre VMOT y GND para cada uno de los drivers.

- A1, A2, B1, B2: estos pines se conectan al motor paso a paso.

- M0, M1, M2: estos pines son la entrada de tamaño de step y se usan para realizar

microstepping. Si se dejan desconectados, se utiliza el modo full-step, por lo que no

se realiza microstepping. En nuestro caso, sí que se realiza microstepping, en

concreto la configuración 1/8, por lo que solo utilizaremos los pines M0 y M1.

No se han usado los siguientes pines.

- ENABLE: este pin es el que habilita el controlador para que funcione. Ante un valor

HIGH apaga y libera el motor y ante un valor LOW lo enciende. Se puede dejar

desconectado. Si este pin recibe un valor HIGH, el motor queda libre, no ejerce

ninguna fuerza, por lo que el motor girará libremente, y podría perder su posición.

El beneficio de usar este pin es que podemos apagar el motor reduciendo el

consumo energético y previniendo que se calienten demasiado los motores. Una

desventaja seria que cada vez que apagamos (HIGH) y volvemos a encender (LOW),

se resetea la tabla de pasos a la posición inicial, por lo que el motor podría

desplazarse a una posición distinta a la que tenía antes de que se enviase el HIGH.

- FAULT: se trata de un pin de salida que transmite LOW cuando detecta

sobrecorriente o sobretempteratura. No se usa, ya que los motores no van a tener

que realizar grandes esfuerzos.

5.9. RESULTADOS

En este punto ya tenemos un robot para resolver cubos de Rubik totalmente funcional.

Vamos a comentar los resultados obtenidos en las diferentes funcionalidades que nos

ofrece el robot.

Antes de empezar con los resultados conviene recordar el proceso que lleva a cabo el

robot cuando recibe una orden.

Como hemos dicho anteriormente tenemos la opción mezclar, resolver, patrón y apagar.

Descartaremos la opción apagar ya que su función es muy simple, apagar el robot.

Aunque conviene detallar el porqué de este botón, puesto que podríamos pensar que


106

con retirar el enchufe sería suficiente. El motivo es alargar la vida útil tanto de la

Raspberry, como de la tarjeta de memoria Micro SD, que cumple la función de disco

duro de la Raspberry. Además, puede ocurrir que los datos almacenados en la Micro SD

se corrompan y tengamos que volver a reinstalar el SO y todo el software que

necesitamos. Lo más adecuado es pulsar el botón apagar, esperar unos segundos y

posteriormente desenchufar el robot.

En cuanto al resto de las opciones, todas siguen un proceso muy parecido. Como vemos

en la siguiente tabla, solo varían los algoritmos que se ejecutan en cada una de ellas:

Opción Mezclar Resolver Patrón

Realizar fotografías y extraer colores

Algoritmo mezclar

Algoritmo resolver Algoritmo patrón Girar motores

Realizar fotografías y extraer colores

Crear documento

A continuación, se muestra un ejemplo de los ficheros que generan estas operaciones

donde podemos ver el tiempo empleado en cada uno de los pasos:

Mezclar el cubo:

Ilustración 104. Imagen inicial mezclar

107

Ilustración 105. Imagen final mezclar

Ilustración 106. Resultados mezclar

Ilustración 107. Giros por segundo mezclar

Fotos iniciales y extraer colores

Aplicar algoritmos Girar motores Fotos finales y extraer colores

7,794 segundos 0,094 segundos 5,692 segundos 7,338 segundos


108

Resolver el cubo

Ilustración 108. Imagen inicial resolver

Ilustración 109. Imagen final resolver

109

Ilustración 110. Resultados resolver

Ilustración 111. Giros por segundo resolver




Aplicar patrón al cubo

Ilustración 112. Imagen inicial patrón


110

Ilustración 113. Imagen final patrón

Ilustración 114. Resultados patrón

Ilustración 115. Giros por segundo patrón




0,009 segundos 0,709 segundos

Total: 0,34 segundos

Total: 11,45 segundos

111

De los resultados anteriores podemos ver que el tiempo que se tarda en realizar las

fotografías iniciales o finales y extraer los colores del cubo oscila entre los 6 y 8

segundos. Por esto, en cada operación que realice el robot se van a emplear entre 12 y

16 segundos para hacer las fotografías y extraer los colores. Este tiempo se debe al

tiempo que necesitan las cámaras para estabilizarse y tomar las fotos con los ajustes

adecuados. El mismo se podría reducir si se instalasen unas cámaras con mejores

prestaciones, y por lo tanto más caras. Existen cámaras para la detección de colores

diseñadas para entornos industriales como clasificadores de alimentos o paquetes, pero

tienen un precio muy elevado.

A diferencia del caso anterior, el tiempo que emplean los motores depende del número

de movimientos que hayan generado los algoritmos. Podemos ver que en el peor de los

casos este tiempo es similar al de la extracción de colores. Este tiempo se podría reducir

si se mejoran los algoritmos de resolución para que generen menos movimientos.

También se puede apreciar que si hay muchos dobles giros simultáneos el tiempo se

reduce. En cuanto a la velocidad a la que se realizan los giros es bastante aceptable. De

media se obtienen unos 6 giros por segundo, que serían 12 en el hipotético caso de que

fuesen giros dobles.

El tiempo empleado por los algoritmos para calcular los giros es el más pequeño, siendo

inferior a un segundo en cualquier situación.

En general el tiempo total que tarda en realizar cualquiera de las operaciones estaría

entre los 20 y los 28 segundos, dependiendo de los factores comentados anteriormente.


112

113

6. PROYECTOS RELACIONADOS

6.1. GAN ROBOT

Este robot desarrollado por la empresa GAN se encuentra a la venta por un precio de 80

$. Para su funcionamiento, requiere de un cubo electrónico fabricado por la misma

marca que dependiendo del modelo podemos encontrar por precios que van desde los

55 a los 75 $. Este robot consta de 5 motores por lo que puede girar todas las caras del

cubo menos la superior. Es capaz de resolver la gran mayoría de los posibles estados del

cubo en menos de 15 segundos. El robot se puede controlar mediante un botón físico o

mediante una app disponible para IOS y Android. Además, esta app se puede sincronizar

con el cubo electrónico que necesita el robot para funcionar, de modo que queden

registrados todos los estados del cubo, así como los giros realizados y el tiempo

transcurrido.

El robot tiene 3 funcionalidades:

- Resolver el cubo en menos de 15 segundos para la mayoría de los casos.

- Mezclar el cubo aleatoriamente.

- Enseñar a resolver el cubo en cooperación con la app.

Ilustración 116. Robot GAN


114

6.2. SUB 1 RELOADED

Este robot ostenta el Guinness World Record al robot más rápido en resolver un cubo

de Rubik, con un tiempo de 0,637 segundos. Fue construido por Albert Beer (Alemania)

y obtuvo este título en la feria de electrónica de Munich, Alemania, el 9 de noviembre

de 2016.

Para llevar a cabo su función, consta de un par de cámaras que fotografían el cubo para

extraer los colores de este. Posteriormente, calcula la secuencia de movimientos

mediante una implementación del algoritmo de dos fases de Herbert Kociemba. Esta

secuencia de movimientos se transmite a los 6 motores paso a paso mediante una placa

de microcontrolador Infineon AURIX compatible con Arduino.

Ilustración 117. Robot SUB 1 RELOADED

6.3. LEGO CUBESTORMER 3

Este robot está construido principalmente con piezas de Lego Mindstorms y un Samsung

Galaxy S4. Lego Mindstorms es una estructura de hardware y software cuyo objetivo es

el desarrollo de robots programables basados en bloques de construcción de Lego. Se

trata de la tercera generación del robot Cubestormer, desarrollada por David Gilday y

Mike Dobson, y su objetivo es resolver el cubo lo más rápido posible.

Para cumplir esta meta, el smartphone cuenta con una app que se encarga de captar el

estado del cubo mediante la cámara trasera y posteriormente calcula los movimientos

para resolverlo. Después los procesadores ARM mueven las diferentes piezas del Lego

Mindstorm.

115

Tanto este robot como su predecesor (CUBESTORMER 2) han conseguido el Guinness

World Record al robot más rápido en resolver un cubo de Rubik, aunque actualmente el

título le pertenece al Sub1 Reloaded.

Ilustración 118. Robot Lego Cubestormer 3

6.4. RUBOT II THE CUBINATOR

Robot desarrollado por el inventor e ingeniero irlandés Pete Redmond. La función

principal de este robot es la capacidad de coger un cubo desde una plataforma donde el

usuario colocaría el cubo mezclado, posteriormente eleva el cubo para posicionarlo en

frente de la cámara, que se encuentra en uno de sus ojos. La cámara escanea todas las

caras del cubo y el robot encuentra la solución al cubo en un tiempo medio de menos

de un segundo. Es capaz de resolver cualquier cubo de Rubik en menos de 50 segundos,

y su récord son 21 segundos. Una característica de este robot es que se le han otorgado

algunas cualidades humanas, como la capacidad de conversar.


116

Ilustración 119. Robot Rubot II

117

7. CONCLUSIONES

Esta memoria recoge el proceso de creación del robot Rubok, describiendo cada paso

del proceso detalladamente, desde la idea, la plataforma, los actuadores, … hasta el

software de resolución del cubo.

Este documento junto con los anexos constituye la documentación técnica del proyecto.

En general podríamos decir que el objetivo principal del proyecto ha sido alcanzado.

Dicho objetivo era que cualquier persona pudiese resolver un cubo de rubik pulsando

un botón. La idea era que lo hiciese sin necesidad de tener ningún tipo de conocimiento

más allá que saber o deducir cual es el botón de resolver, y con el único requisito de

disponer de un enchufe que proporcione 230 V, el voltaje común en España.

Además de este objetivo principal había algunos más, tanto técnicos como personales.

- Entrada de datos: este objetivo se ha cumplido ya que el robot es capaz de

fotografiar el cubo completo mediante dos webcams. No obstante, los resultados

obtenidos dependen en gran medida de la inversión económica realizada en las

cámaras. Esta mejoras irían desde el tiempo de estabilización del obturador a la

independencia de fuentes externas de iluminación.

- Desarrollo de algoritmos de lectura de imágenes: este objetivo consiste en extraer

el estado del cubo a partir de fotografías. Podemos decir que se ha alcanzado

satisfactoriamente siempre que las fotografías proporcionadas sean adecuadas, y las

coordenadas proporcionadas para extraer cada pieza del cubo sean correctas.

- Creación y controles del cubo: este objetivo era de vital importancia para poder

aplicar toda la resolución. Se ha desarrollado con éxito ya que la representación del

cubo virtual, así como la aplicación de los diferentes giros es idéntica a la que

produciría un cubo físico.

- Desarrollo de algoritmo para mezclar el cubo: objetivo cumplido ya que el algoritmo

es capaz de producir combinaciones de giros que aseguran que el cubo se mezclara

de una manera totalmente aleatoria.

- Desarrollo de algoritmos de resolución del cubo: objetivo alcanzado ya que los

algoritmos desarrollados proporcionan una secuencia de giros que resuelve el cubo.

Si bien el resultado obtenido está lejos del número de Dios, los resultados son

bastante aceptables, obteniéndose entre 60 y 80 giros en la mayoría de los casos.

- Desarrollo de algoritmo de patrones: objetivo cumplido, el algoritmo proporcionan

los giros necesarios para aplicar un patrón a un cubo resuelto. Estos patrones son

elegidos aleatoriamente de una lista de patrones.

- Desarrollo de algoritmo de giro de motores: se pretendía desarrollar un algoritmo

que permitiese sincronizar los giros de los diferentes motores. Dicho algoritmo les

indica la velocidad y el sentido de giro, además permite que dos motores giren

simultáneamente siempre que sea posible. Este objetivo se ha alcanzado

exitosamente.


118

- Desarrollo de hardware: este objetivo englobaba la selección e interconexión de

todo el hardware necesario para desempeñar las funciones del robot.

7.1. LÍNEAS FUTURAS DE TRABAJO

En el transcurso del desarrollo del proyecto se han adquirido nuevos conocimientos y

han surgido ideas de ampliación o modificación del proyecto. Se planea que el proyecto

siga evolucionando tanto en la parte hardware como software.

- Simplificar planos de corte: simplificar la estructura del robot de modo que se

requieran menos piezas, lo que facilitaría el proceso de montado del robot. El diseño

de la estructura del robot es bastante complejo, consta de una gran cantidad de

piezas, y algunas de ellas son muy pequeñas y parecidas. Esta complejidad se debe

en gran parte a tener que crear una estructura 3D a partir de tableros o láminas.

- Mejorar estructura: Otro factor que mejorar sería el grosor del material elegido para

su construcción, que es 4 milímetros. Encontrar tableros de este grosor resulta un

poco complicado, debido a que los estándares de los tableros suelen ser 3 o 5

milímetros, por lo que muy pocos proveedores trabajan con este grosor.

También sería buena idea barajar la opción de realizar un prototipo de estructura

del robot mediante una impresora 3D, ya que el hecho de poder construir piezas

tridimensionales puede reducir mucho el número de piezas que forman la

estructura.

Un inconveniente que podría surgir para la impresión 3D son las dimensiones del

robot. Habría que plantear un nuevo diseño en el que se dividan las piezas más

grandes en piezas de menor tamaño ya que el área de impresión de la mayoría de

las impresoras 3D de uso doméstico no sería lo suficientemente grande para

imprimir el diseño actual.

- Facilitar la extracción del cubo: diseñar algún tipo de modificación de la estructura

para facilitar la extracción y posterior inserción del cubo en los ejes de los motores,

evitando tener que remover piezas o alterar demasiado la estructura del robot para

conseguirlo. Esta mejora le daría más sentido a la función de mezclar el cubo que

posee el robot, ya que, si el usuario quiere resolver el cubo manualmente, podría

insertar el cubo en la estructura del robot, pulsar el botón de mezclar, y extraer el

cubo para resolverlo. Esta opción tiene un interés añadido, ya que a la hora de

mezclar el cubo manualmente, se pueden llegar a crear patrones o hábitos de giro

que hacen que muchas veces mezclemos el cubo de una manera muy similar. Esto

tampoco es un gran problema. Con la enorme cantidad de posibles estados del cubo,

es muy difícil conseguir dos cubos iguales, aunque tengamos estos hábitos. La

función de mezclar del robot es totalmente aleatoria, por lo que se eliminaría este

defecto al mezclar manualmente el cubo.

- Implementar un modo de resolución lento: desarrollar una nueva funcionalidad que

consista en que las resoluciones del cubo se realicen a menor velocidad para que el

usuario pueda observar más fácilmente los pasos que sigue el robot.

119

- Implementar app: desarrollar una app que permita controlar el robot, de modo que

se puedan realizar todas las funciones que permiten los botones del robot más

nuevas funcionalidades. Podría añadirse la opción de controlar los motores de

manera individual o permitir que el usuario introduzca una secuencia de giros desde

el teclado y posteriormente el robot la realice. También se podría añadir una función

para que almacenasen las resoluciones realizadas por el robot con sus atributos

correspondientes. Por ejemplo, el tiempo o el número de giros empleados en el

proceso.


120

121

8. BIBLIOGRAFÍA

[1] Lee Adams, W. (2009, 28 enero). The Rubik’s Cube: A Puzzling Success. Time.

https://web.archive.org/web/20090201200141/http://www.time.com/time/m

agazine/article/0,9171,1874509,00.html

[2] Vaughen, S. Counting the Permutations of the Rubik’s Cube [Diapositivas]. ppt.

https://slideplayer.com/slide/14128061/

[3] Castella, T. (2014, 28 abril). The people who are still addicted to the Rubik’s Cube.

BBC News. https://www.bbc.com/news/magazine-27186297

[4] The Perplexing Life of Erno Rubik. (1986). Discover, 7, 81.

http://www.puzzlesolver.com/puzzle.php?id=29;page=15

[5] Cubo de Rubik: los secretos del rompecabezas que nos propone Google. (2014,

19 mayo). ABC. https://www.abc.es/ciencia/20140519/abci-cubo-rubik-doodle-

google-201405190009.html

[6] Singmaster, D. (1981). Notes on Rubik’s Magic Cube. Macmillan Publishers.

[7] Rokicki, T., Kociemba, H., Davidson, M., & Dethridge, J. (2010). God’s Number is

20. https://www.cube20.org/

[8] Ross, D. (2017). Rubik’s Cube Best Algorithms. Amazon Digital Services LLC - KDP

Print US.

[9] Advanced Rubik’s Cube: Fridrich First two layers - F2L. (2014). Ruwix.

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/first-two-layers-f2l/

[10] Rubik’s Cube advanced Fridrich - Orient last layer OLL. (2014). Ruwix.

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/orient-the-last-

layer-oll/

[11] Advanced Fridrich CFOP method: Permutate the last layer - PLL. (2014). Ruwix.

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/permutate-the-last-

layer-pll/

8.1. MANUALES, GUIAS Y CONSULTAS

- Castañon Jimenez, C. (2017, 1 septiembre). Manejar un motor stepper con un driver

DRV8825 y una Raspberry Pi. Carlini’s Blog.

- http://carlini.es/manejar-un-motor-stepper-con-un-driver-drv8825-y-una-

raspberry-pi/

- Douglas Warren, J. (1995). Control of Stepping Motors. uiowa.

http://homepage.divms.uiowa.edu/%7Ejones/step/

https://web.archive.org/web/20090201200141/http:/www.time.com/time/magazine/article/0,9171,1874509,00.html

https://web.archive.org/web/20090201200141/http:/www.time.com/time/magazine/article/0,9171,1874509,00.html

https://slideplayer.com/slide/14128061/

https://www.bbc.com/news/magazine-27186297

http://www.puzzlesolver.com/puzzle.php?id=29;page=15

https://www.abc.es/ciencia/20140519/abci-cubo-rubik-doodle-google-201405190009.html

https://www.abc.es/ciencia/20140519/abci-cubo-rubik-doodle-google-201405190009.html

https://www.cube20.org/

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/first-two-layers-f2l/

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/orient-the-last-layer-oll/

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/orient-the-last-layer-oll/

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/permutate-the-last-layer-pll/

https://ruwix.com/the-rubiks-cube/advanced-cfop-fridrich/permutate-the-last-layer-pll/

http://carlini.es/manejar-un-motor-stepper-con-un-driver-drv8825-y-una-raspberry-pi/

http://carlini.es/manejar-un-motor-stepper-con-un-driver-drv8825-y-una-raspberry-pi/

http://homepage.divms.uiowa.edu/~jones/step/


122

- Five Ways to Run a Program On Your Raspberry Pi At Startup. (2016). Dexter

Industries. https://www.dexterindustries.com/howto/run-a-program-on-your-

raspberry-pi-at-startup/

- Kiourtzoglou, B. (2012, 11 noviembre). Create image file from graphics object |

Examples Java Code Geeks - 2021. Java Code Geeks.

https://examples.javacodegeeks.com/desktop-java/imageio/create-image-file-

from-graphics-object/

- Kostoski, S. (2019, 7 enero). From zero to Rubik’s cube solving robot. Noteworthy -

The Journal Blog. https://blog.usejournal.com/from-zero-to-rubiks-cube-solving-

robot-ad3a2838cd

- Pysource. (2018, 25 septiembre). Simple shape detection – Opencv with Python 3

[Vídeo]. YouTube. https://www.youtube.com/watch?v=43pCXboZ5hE

- rdagger68. (2017, 4 junio). Raspberry Pi Stepper Motor Tutorial [Vídeo]. YouTube.

https://www.youtube.com/watch?v=LUbhPKBL_IU

- Rubik’s Cube and Twisty Puzzle Wiki. (2014). Ruwix. https://ruwix.com/

- Rubik’s Cube Solver. (2016). [Solucionador del Cubo de Rubik online]. Ruwix.

https://rubiks-cube-solver.com/es/

- Souza, E. (2019, 15 octubre). Tableros de madera: diferencias entre MDF, MDP,

Contrachapado y OSB. Plataforma Arquitectura.

https://www.plataformaarquitectura.cl/cl/926463/tableros-de-madera-

diferencias-entre-mdf-mdp-contrachapado-y-osb

- SpeedSolving the Rubik’s Cube - Speedsolving.com Wiki. (2006). Speedsolving.

https://www.speedsolving.com/wiki/index.php/Main_Page

- The Pi4J Project – Pin Numbering - Raspberry Pi Model A+. (2014). Pi4J.

https://pi4j.com/1.2/pins/model-a-plus.html

- The Python Standard Library — Python 3.3.7 documentation. (2017). Python.

https://docs.python.org/3.3/library/index.html

- Using a push button with Raspberry Pi GPIO. (2018, 9 febrero). Raspberry Pi HQ.

https://raspberrypihq.com/use-a-push-button-with-raspberry-pi-gpio/

8.2. SOFTWARE

- Fritzing (0.9.3b). (2016). [Iniciativa de código abierto para desarrollar software CAD].

https://fritzing.org/

- Inkscape (1.1). (2021). [Editor de gráficos vectoriales libre y de código abierto].

https://inkscape.org/

- Java (jdk 1.8). (2014). [Entorno de desarrollo para crear aplicaciones y componentes

utilizando el lenguaje de programación Java]. Oracle.

https://www.oracle.com/es/java/technologies/javase/javase-jdk8-downloads.html

- Lucidchart. (2010). [Herramienta de diagramación basada en la web]. Lucid

Software. https://www.lucidchart.com/pages/es

- Microsoft Word (Microsoft 365). (2011). [Software de procesamiento de texto].

Microsoft. https://www.office.com/

https://www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup/

https://www.dexterindustries.com/howto/run-a-program-on-your-raspberry-pi-at-startup/

https://examples.javacodegeeks.com/desktop-java/imageio/create-image-file-from-graphics-object/

https://examples.javacodegeeks.com/desktop-java/imageio/create-image-file-from-graphics-object/

https://blog.usejournal.com/from-zero-to-rubiks-cube-solving-robot-ad3a2838cd

https://blog.usejournal.com/from-zero-to-rubiks-cube-solving-robot-ad3a2838cd

https://www.youtube.com/watch?v=43pCXboZ5hE

https://www.youtube.com/watch?v=LUbhPKBL_IU

https://ruwix.com/

https://rubiks-cube-solver.com/es/

https://www.plataformaarquitectura.cl/cl/926463/tableros-de-madera-diferencias-entre-mdf-mdp-contrachapado-y-osb

https://www.plataformaarquitectura.cl/cl/926463/tableros-de-madera-diferencias-entre-mdf-mdp-contrachapado-y-osb

https://www.speedsolving.com/wiki/index.php/Main_Page

https://pi4j.com/1.2/pins/model-a-plus.html

https://docs.python.org/3.3/library/index.html

https://raspberrypihq.com/use-a-push-button-with-raspberry-pi-gpio/

https://fritzing.org/

https://inkscape.org/

https://www.oracle.com/es/java/technologies/javase/javase-jdk8-downloads.html

https://www.lucidchart.com/pages/es

https://www.office.com/

123

- NetBeans (8.2). (2016). [Entorno de desarrollo integrado libre, hecho principalmente

para el lenguaje de programación Java]. Oracle.

https://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-

3413139-esa.html

- OpenCV (3.3). (2017). [Biblioteca de funciones de programación destinadas

principalmente a la visión por computadora en tiempo real]. Open Source Vision

Foundation. https://opencv.org/

- Paint.NET (4.2.16). (2021). [Software de edición de imágenes y fotos para Windows].

dotPDN LLC, Rick Brewster. https://www.getpaint.net/

- Python (2.7). (2010). [Lenguaje de programación interpretado, orientado a objetos

y de alto nivel con semántica dinámica]. Python Software Foundation.

https://www.python.org/

- Raspberry Pi OS (Raspbian GNU/Linux 9 (stretch)). (2020). [Distribución del sistema

operativo GNU/Linux basado en Debian]. Raspberry Pi Foundation.

https://www.raspberrypi.org/software/operating-systems/

- Tinkercad. (2011). [Programa de modelado 3D en línea gratuito]. Autodesk.

https://www.tinkercad.com/

- VNC Viewer (6.21.406). (2021). [Sistema gráfico para compartir escritorio]. RealVNC.

https://www.realvnc.com/es/connect/download/viewer/

8.3. REFERENCIAS DE IMÁGENES

- CubeStormer 3. (s. f.). [Fotografía]. El correo.

https://static.elcorreo.com/www/pre2017/multimedia/RC/201404/14/media/cort

adas/robotrubik3--490x490.JPG

- Driver DRV8825. (s. f.). [Fotografía]. Naylamp Mechatronics.

http://www.naylampmechatronics.com/img/cms/0J4232-600.png

- Fuente de alimentación. (s. f.). [Fotografía]. Ace Electronics.

https://i1.wp.com/www.aceelectronics.com/commercial/files/2016/06/power-

distribution-unit-1.jpg?fit=700%2C450&ssl=1

- GAN robot. (s. f.). [Fotografía]. Gancube. https://shop.gancube.com/wp-

content/uploads/2019/09/%E6%99%BA%E8%83%BD%E5%A5%97%E8%A3%85.png

- Nema 17. (s. f.). [Fotografía]. e-ika. https://www.e-

ika.com/images/thumbs/0003897_motor-paso-a-paso-nema-17-133a_600.jpeg

- Protoboard. (s. f.). [Fotografía]. Electronica Made.

https://electronicamade.com/wp-content/uploads/2020/04/Protoboard.jpg

- Raspberry pi 3 modelo b+. (s. f.-a). [Fotografía]. Raspberry Pi.

https://raspberrypi.dk/wp-content/uploads/2018/03/Raspberry-Pi-3-Model-

BPlus.jpg

- Raspberry pi 3 modelo b+. (s. f.-b). [Fotografía]. Amazon. https://images-na.ssl-

images-amazon.com/images/I/81hyqDgm8vL._AC_SL1500_.jpg

https://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-3413139-esa.html

https://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-3413139-esa.html

https://opencv.org/

https://www.getpaint.net/

https://www.python.org/

https://www.raspberrypi.org/software/operating-systems/

https://www.tinkercad.com/

https://www.realvnc.com/es/connect/download/viewer/

https://static.elcorreo.com/www/pre2017/multimedia/RC/201404/14/media/cortadas/robotrubik3--490x490.JPG

https://static.elcorreo.com/www/pre2017/multimedia/RC/201404/14/media/cortadas/robotrubik3--490x490.JPG

http://www.naylampmechatronics.com/img/cms/0J4232-600.png

https://i1.wp.com/www.aceelectronics.com/commercial/files/2016/06/power-distribution-unit-1.jpg?fit=700%2C450&ssl=1

https://i1.wp.com/www.aceelectronics.com/commercial/files/2016/06/power-distribution-unit-1.jpg?fit=700%2C450&ssl=1

https://shop.gancube.com/wp-content/uploads/2019/09/%E6%99%BA%E8%83%BD%E5%A5%97%E8%A3%85.png

https://shop.gancube.com/wp-content/uploads/2019/09/%E6%99%BA%E8%83%BD%E5%A5%97%E8%A3%85.png

https://www.e-ika.com/images/thumbs/0003897_motor-paso-a-paso-nema-17-133a_600.jpeg

https://www.e-ika.com/images/thumbs/0003897_motor-paso-a-paso-nema-17-133a_600.jpeg

https://electronicamade.com/wp-content/uploads/2020/04/Protoboard.jpg

https://raspberrypi.dk/wp-content/uploads/2018/03/Raspberry-Pi-3-Model-BPlus.jpg

https://raspberrypi.dk/wp-content/uploads/2018/03/Raspberry-Pi-3-Model-BPlus.jpg

https://images-na.ssl-images-amazon.com/images/I/81hyqDgm8vL._AC_SL1500_.jpg

https://images-na.ssl-images-amazon.com/images/I/81hyqDgm8vL._AC_SL1500_.jpg


124

- Robotec RTJ-1390. Máquina de corte laser. (s. f.). [Fotografía]. robotecnc.

https://lh3.googleusercontent.com/proxy/dW2K1_IyKbIZ4nMZ3oJz6B7QxMTxbcn

mmlZx1aTejyFPcMWF9CczTmOOJKIyv7rHjbdm2oxASNTSHv_efM6uf03mCN0LXJian

pK2bzPH9vMscfknh64B8kze

- Rubot II. (s. f.). [Fotografía]. Facebook.

https://www.facebook.com/RuBotII/photos/10154693673236256

- Sub1 Reloaded. (s. f.). [Fotografía]. Vanguardia MX.

https://vanguardia.com.mx/sites/default/files/robot-rubik-cube.jpg

https://lh3.googleusercontent.com/proxy/dW2K1_IyKbIZ4nMZ3oJz6B7QxMTxbcnmmlZx1aTejyFPcMWF9CczTmOOJKIyv7rHjbdm2oxASNTSHv_efM6uf03mCN0LXJianpK2bzPH9vMscfknh64B8kze



https://www.facebook.com/RuBotII/photos/10154693673236256

https://vanguardia.com.mx/sites/default/files/robot-rubik-cube.jpg

ROBOT PARA RESOLVER EL CUBO DE RUBIK RUBOK

Documents