Embed Size (px)
Citation preview
Rubik’s Cube Solving RobotDaniel Truesdell1, Corey Holsey2, Tony Verbano3
Department of Engineering and Computer ScienceUniversity of Central Florida
Orlando, Fl.Email: [email protected],[email protected],[email protected]
Abstract—In this paper we present the design andimplementation of a robotic system that is capable ofautonomously solving a Rubik’s Cube puzzle. The fourmain components of our system are an integrated imagesensing device, a custom embedded processing platform,a PC-based software application, and a physical roboticstructure. These components function together to accu-rately decode and solve the Rubik’s Cube puzzle in a timelymanner.
I. INTRODUCTION
The Rubik’s Cube is a timeless puzzle that haschallenged people since its creation in 1974. Significantmathematical investigations of the Rubik’s Cube overthe past decades have provided many frameworks andalgorithms for systematically decoding and solving it. Inrecent years, cube enthusiasts have leveraged the powerand speed of modern computers to analyze scrambledcubes in real time and determine what manipulationsare necessary to solve them. The computerization of thisprocess has prompted the creation of robotic devicesthat are capable of carrying out the computer-generatedmanipulation sequences in order to physically solve acube from start to finish. The speed and accuracy of thesesystems showcase the power of engineering to performtasks far beyond human capability.
Existing implementations of these systems range incomplexity from simple hobbyist weekend projects tohigh-level university projects such as the present work.Some systems take minutes to solve a cube whileothers are finished in under a second, and some systemsare hardware-oriented while others place emphasis onelaborate software programming. Each project contributesa unique solution to a growing pool of knowledge andresources that collectively advance our ability to solvethe challenge. To this end, we herein present the designand implementation of a robotic system that is capableof autonomously solving a Rubik’s Cube puzzle.
II. SYSTEM OVERVIEW
The robotic system, shown in Figure 1, consists of fourmain functional components: An image sensing device, asoftware application, an embedded system, and a physicalstructure. The following subsections briefly describe thesecomponents and their functionality within the system.
Stepper
Motors
Embedded System
MSP430
Stepper
Drivers
CMUcam5
Pixy
Software Application
Image
Processing
Algorithms
GUI
Physical Structure Image Sensing
Fig. 1: Functional System Block Diagram
A. Image Sensing
This project implements the CMUcam5 Pixy as anintegrated image sensing solution. The Pixy is a palm-sized camera with an on-board 204MHz NSP LPC4330processor that allows it to perform image processingon raw data before it is sent over USB to our softwareapplication. Pixy’s convenient libraries can be used toidentify the colors of the cube as well as their positionsso that the software can determine how the cube needsto be manipulated.
B. Software Application
Our robot software consists of several components forimage processing and visualization, cube deciphering, a
solving algorithm, a GUI, and physical structure control.This software is collectively responsible for detecting thecurrent state of the cube, deciphering the cube positions,applying the solving algorithm, and sending a string ofinformation to the embedded system that tells it how itneeds to manipulate the cube.
C. Physical Structure
The physical structure, shown in Figure 2, is whatholds and manipulates the cube. The frame was designedusing Autodesk Inventor and is intended to be laser cutfrom a variety of materials. The design of the structureallows any face of the cube to be turned with a dedicatedstepper motor, which allows the cube to be manipulatedin any way without needing any prior reorientation. Thisdecreases the number of instructions needed to solve thecube which in turn reduces the amount of time it takesto do so.
Fig. 2: Robot Structure
D. Embedded System
The embedded system, shown in Figure 3, is de-signed with a Texas Instruments (TI) MSP430F6659microcontroller that is interfaced with six TI DRV8825stepper driver integrated circuits (IC’s). The device isdesigned to receive a string of commands from thesoftware application over a serial connection that will bedecoded and used to actuate the stepper motors in orderto manipulate the cube.
III. SOFTWARE DESIGN
A. Image Processing
One of the main components of our project is takingin the image of the cube from its mixed up state and
Fig. 3: Embedded System with MSP430F6659
placing its orientation into an array. We initially start thisby with our Pixy CMU5 camera. This camera is set upto have a set of 7 signature colors that are recognizeseasily. Luckily we will only need 6 signature colors forour cube leaving one value unknown. Each color will begiven a signature color number as its initial value andthat will be used to make our cube array. The camerais positioned to look at the bottom row of the top faceand the top row of the front face. We have determinedthat from this position the whole cube can be viewedand oriented back to its initial state in 11 move sets. Thecamera takes a picture of the state of these rows at thisposition than rotates one face at a time till the wholecube is recognized.
After each initial picture is taken and before the cubeis rotated, the image is the deciphered for the significantcolors which are then placed into a string correspondingwith their position on the cube. The image is than replacedwith the next image after the rotation of the cube andthe process of deciphering the state of the cube startsover until the whole cube is processed. After the wholecube is processed and the total cube is laid out into astring, our string is sent to our main program where it isplaced into a matrix. The matrix is used with our GUIand our algorithm to help visualize and solve for thecubes correct orientation.
B. Kociemba’s Algorithm
The algorithm we chose was Kociembas algorithmwhich is also known as Gods algorithm because it cansolve the cube optimally. It is a two-phase algorithmthat solves the cube in at most twenty moves when usedoptimally. It was founded in 2010 by Herbert Kociembaand was basically a refinement of another Rubiks cubealgorithm [1]. Rather than using five groups it was cutdown to merely three groups. The groups were identified
as G0, G1, and G2. The G0 group identified the initialstate of the cube. The algorithm also utilizes symmetriesand by reducing the number of symmetries that areavailable on the cube decreases the number of possiblemoves.
The Rubiks cube has billions of different symmetries164,604,041,664 to be exact. Reducing those possiblesymmetries by finding correlation between symmetry, anti-symmetry, and conjugations greatly reduces the number ofrelevant symmetries to a little over a million. Once twentyturns have been completed utilizing the algorithm thenexactly 32,625 different symmetric cubes can be solvedusing the twenty move algorithm by Herbert Kociemba.
The G1 state has a goal state which utilizes conjuga-tions. The conjugation to move the edges of the middlecube in a way that once three moves are done it willresult in the opposite of those three moves being done.It does not allow for the edges or corners to changeorientation once in this state. The conjugate is soughtby having millions of lookup tables that are generatedand then pruned to find a solution to the cube. Pruningthe cube while in this state is very important as to makethe solution much faster on solving the cube. Decidingwhen to prune made the biggest difference in speed forour application. Then, that completes the phase 1 and itmoves on to phase 2 of the algorithm.
While in phase 2 the corners and edges of the cube arepermutated. Finally, once one solution to the cube is foundthen another solution is sought out that does not conflictwith any of the possibilities that were discovered from thefirst solution. The second solution only goal is to makethe first solution shorter. When phase 2 finally gets to zerothen an optimal solution has been found and the algorithmis complete. A problem we had with this algorithm wasthere being so many lookup tables is the reason it was notpossible to implement Kociembas algorithm directly onour microcontroller. It abuses entirely too much RAM forour MCU to handle. The easiest solution to this problembecause RAM cannot be added to our MCU was to makea desktop application. A desktop computer (laptop) canhandle a significant amount of RAM and still talk to ourMCU by sending the solution string over UART.
Another difficulty is where to prune for the millionsof lookup tables that are stored utilizing this algorithm.Pruning the tables in certain places can be the differencebetween these algorithm taking seconds or it taking aquarter hour. The prune tables could be loaded automati-cally when they are called upon which would make thetime significantly longer. However, we chose to manuallyload the prune tables from the beginning of the program.
Manually loading the prune tables is a bit more inefficient,but it is much faster which we were more concernedabout.
Our software application will not look for solution thatare completely optimal which would mean be done in20 moves. This is because it increases the time for thesolution to be found and having it solve in a consistenttime was important to us. Therefore, we only look tosolve the cube in approximately 24 moves.
C. Graphical User Interface
Fig. 4: Graphical User Interface
The software application will have a Graphical UserInterface that will have a display of the cube. The displayof the cube will be a 2D display that shows the differentfaces of the cube. The faces shown will be mappedappropriately once the initial string is interpreted todisplay the state of the cube. Each color of the cubeis denoted by the center face that it is on. For example,the Green face is on the front face therefore it will bedenoted as F rather than Green.
The Graphical User Interface will also consist ofmultiple buttons. One button that will made availableis a solution button. The solution button will solve thecube at its current state by generating a solution stringand sending it over to the robot over UART. The nextbutton that is made available is that randomize button.The randomize button will change the state of the cubefrom its current state without looking to solve the cube.It will manipulate the array position in valid ways togive the cube a different state. In Figure 5 the randomizebutton is denoted by Scramble. While in the same figurethe solution button is denoted by Solve. Other buttons ortext may be added if we have time such as a timer or a
stop button. However, that is only if we have time in theend will we look to add additional functionality to theGraphical User Interface.
We chose to use java programming language to makethe Graphical User Interface because it is friendlier touse for a Graphical User Interface than C programminglanguage is. Java has libraries built in to make this processas seamless as possible. Visually the buttons are likely tosimply be j-buttons from the standard java library. Bothbutton will generate a solution string then convert thatso that the our MCU can understand it and move therobotic arms appropriately.
In Figure 4 is an example of what our Graphical UserInterface should look similar to once completed. We arestill working on the Graphical User Interface because thefront end it not as important nor difficult as the backendand actual assembly of the robot. Also, keeping thingssimple usually helps to generate as few errors as possiblewhich is what we are seeking.
IV. HARDWARE DESIGN
A. Processor
The block diagram for the embedded system is shownin Figure 5. The on-board MSP430F6659 offers con-nectivity and I/O through a micro-USB port with ESDprotection, 4-wire JTAG pins, 16 GPIO pins that aremappable to various serial modules, 2 pushbuttons, and2 LEDs. An additional 14 GPIO pins on the MSP430are interfaced with the six DRV8824 stepper drivers.
16
DRV8825
Stepper
Motor Drivers
12VDC
Stepper
Motors
MSP430F6659
UA78M05 TPS715A 5VDC
3.3VDC
USB
JTAG, SBW
GPIO
CMUcam5 Pixy
2x UART
2x I2C
4x SPI
Push
button LED
2 2
14
4x6
Fig. 5: Embedded System Block Diagram
B. Power
The board is intended to be supplied with 12Vdc viaa 2.1mm barrel jack. This voltage is needed by theDRV8825 IC’s to power the connected stepper motors,
but it is too high for the MSP, so it is stepped downto 5Vdc by the UA78M05 and again to 3.3Vdc by theTSP715. A power LED indicates that the MSP430 isreceiving the necessary 3.3Vdc. If the 12Vdc connectionis not used, the MSP430 can still be powered via the5Vdc header pin, the USB port, or the JTAG Vcc pin.
C. Stepper Drivers
Dedicated stepper driver IC’s are vital to the operationof the embedded system. Figure 6 shows the schematicfor the DRV8825 stepper driver IC. The motors used inthis system require 12V for maximum torque which isfar beyond what the MSP430 can provide [2][3]. TheDRV8825 solves this problem as it can be interfaced withan external motor supply voltage of up to 45V whilestill accepting the low-voltage control signals from theMSP430 [4]. It also protects the MSP430 from potentiallyharmful back-EMF from the large inductive loads of thestepper motors. The maximum full-scale motor current(IFS) for this application was limited to 300mA to staywithin the limits of the PCB traces as well as the 350mAcurrent limit of the motors. The voltage divider calculationfor IFS is adapted from the device datasheet and shownbelow in equation 1:
300mA = IFS(A) =xV REF (V )
AV ×RSENSE(Ω)(1)
Where the gain AV = 5, RSENSE = 0.2Ω, and thevoltage reference xV REF is given in equation 2 as
xV REF (V ) =V 3P3OUT (V ) ×R17(Ω)
R17(Ω) + R18(Ω)(2)
Where V 3P3OUT = 3.3V . Equation 1 yieldsxV REF = 0.3V . Using this value in equation 2, R17and R18 are selected as 20 kΩ and 220 kΩ, respectively.
Another benefit of the DRV8825 is that it offers amicrocontroller-friendly control interface. Bipolar steppermotors such as the ones in this project rely on bidirec-tional current control on four separate motor coil wires.Complex, high-precision drive patterns are required onthese four wires in order to achieve smooth rotation ofthe motor shaft. The DRV8825 is used to handle all of thetiming and current control on these wires by accepting1-bit step and direction inputs from the MSP430. A chipenable signal allows the device to be disabled whichcauses it to ignore input signals and consume essentiallyzero power. The embedded system design takes advantageof this by using a single step signal to control all sixDRV8825s but having multiple enable signals to enable
7/14/2016 2:56 PM C:\Users\Daniel Truesdell\Documents\eagle\SD1\schematic2.sch (Sheet: 1/1)
Spic
eOrd
er 1
Spic
eOrd
er 2
GND
DRV8825_PWP_28
0.1uF
0.01
uF
GND
100uF
GND
0.1uF
GND
1M
0.1uF
GND
0.47uF
GND
20k 220k
GND
0.2
0.2
GND
GND
Value
Value
MIN
I-U
SB-S
HIE
LD-U
X60-
MB-
5ST
CGRM
4001
-G
4.7u
F,10
V
GN
D
27
27
GND10pF,6V
10pF,6V
GND
GND
1M
GND
220n
F,10
V
220n
F,10
V
GND
GN
D GND
CSTCR6M00G53Z
GN
D
GND
1.4k
TPD
2E00
1_D
RL_
5
GNDGND
47k
1nF
GND
TPS715A01_DRV_6
GND
0.1uF0.47uF
GND
VCC
VCC
VCC
10uF100n
470
470
GND
470
GND
DRV8825_PWP_28
0.1uF
0.01
uF
GND
100uF
GND
0.1uF
GND
1M
0.1uF
GND
0.47uF
GND
20k 220k
GND
0.2
0.2
GND
GND
GND
DRV8825_PWP_28
0.1uF
0.01
uF
GND
100uF
GND
0.1uF
GND
1M
0.1uF
GND
0.47uF
GND
20k 220k
GND
0.2
0.2
GND
GND
GND
DRV8825_PWP_28
0.1uF
0.01
uF
GND
100uF
GND
0.1uF
GND
1M
0.1uF
GND
0.47uF
GND
20k 220k
GND
0.2
0.2
GND
GND
GND
DRV8825_PWP_28
0.1uF
0.01
uF
GND
100uF
GND
0.1uF
GND
1M
0.1uF
GND
0.47uF
GND
20k 220k
GND
0.2
0.2
GND
GND
GND
DRV8825_PWP_28
0.1uF
0.01
uF
GND
100uF
GND
0.1uF
GND
1M
0.1uF
GND
0.47uF
GND
20k 220k
GND
0.2
0.2
GND
GND
GND
100n100n100n
Value
0.33uF
GND
0.1uF
GND
470n
FGN
D
X11
23
CP11
CP22
VCP3
VMA4
AOUT15
ISENA6
AOUT27
BOUT28
ISENB9
BOUT110
VMB11
AVREF12
BVREF13
GND_214
V3P3OUT 15NRESET 16NSLEEP 17NFAULT 18DECAY 19
DIR 20NENBL 21
STEP 22NC 23
MODE0 24MODE1 25MODE2 26NHOME 27
GND 28EPAD GND
U5
C19
C20
JP4
1234
C21
C22
R16
C23
C24R17 R18
R19
R20
P6.4_CB4_A4 1
P6.5_CB5_A5 2
P6.6_CB6_A6_DAC0 3
P6.7_CB7_A7_DAC1 4
P7.4_CB8_A12 5
P7.5_CB9_A13 6
P7.6_CB10_A14_DAC0 7
P7.7_CB11_A15_DAC1 8
P5.0_VREF+_VEREF+9
P5.1_VREF-_VEREF-10
XIN13
XOUT14
P5.6_ADC12CLK_DMAE016
P2.0_P2MAP017
P2.1_P2MAP118
P2.2_P2MAP219
P2.3_P2MAP320
P2.4_P2MAP421
P2.5_P2MAP522
P2.6_P2MAP6_R0323
P2.7_P2MAP7_LCDREF_R1324
P5.2_R2328
LCDCAP_R3329
COM0 30
P5.3_COM1_S4231
P5.4_COM2_S4132
P5.5_COM3_S4033
P1.0_TA0CLK_ACLK_S3934
P1.1_TA0.0_S3835
P1.2_TA0.1_S3736
P1.3_TA0.2_S3637
P1.4_TA0.3_S3538
P1.5_TA0.4_S3439
P1.6_TA0.1_S3340
P1.7_TA0.2_S3241
P3.0_TA1CLK_CBOUT_S3142
P3.1_TA1.0_S3043
P3.2_TA1.1_S2944
P3.3_TA1.2_S2845
P3.4_TA2CLK_SMCLK_S2746
P3.5_TA2.0_S2647
P3.6_TA2.1_S2548
P3.7_TA2.2_S2449
P4.0_TB0.0_S2350
P4.1_TB0.1_S2251
P4.2_TB0.2_S2152
P4.3_TB0.3_S2053
P4.4_TB0.4_S1954
P4.5_TB0.5_S1855
P4.6_TB0.6_S1756
P4.7_TB0OUTH_SVMOUT_S1657
P8.0_TB0CLK_S15 58
P8.1_UCB1STE_UCA1CLK_S14 59
P8.2_UCA1TXD_UCA1SIMO_S13 60
P8.3_UCA1RXD_UCA1SOMI_S12 61
P8.4_UCB1CLK_UCA1STE_S11 62
P8.5_UCB1SIMO_UCB1SDA_S10 65
P8.6_UCB1SOMI_UCB1SCL_S9 66
P8.7_S8 67
P9.0_S7 68
P9.1_UCB2STE_UCA2CLK_S6 69
P9.2_UCA2TXD_UCA2SIMO_S5 70
P9.3_UCA2RXD_UCA2SOMI_S4 71
P9.4_UCB2CLK_UCA2STE_S3 72
P9.5_UCB2SIMO_UCB2SDA_S2 73
P9.6_UCB2SOMI_UCB2SCL_S1 74
P9.7_S0 75
PU.0_DP 77
PUR 78
PU.1_DM 79
P7.2_XT2IN 84
P7.3_XT2OUT 85
VBAK 86
P5.7_RTCCLK88
TEST_SBWTCK 91
PJ.0_TDO 92
PJ.1_TDI_TCLK 93
PJ.2_TMS 94
PJ.3_TCK 95
RST_NMI_SBWTDIO_N 96
P6.0_CB0_A0 97
P6.1_CB1_A1 98
P6.2_CB2_A2 99
P6.3_CB3_A3 100
U2A
AVCC111
AVSS1 12
AVSS2 15
DVCC125
DVSS1 26
VCORE27
DVSS2 63
DVCC264
VSSU 76VBUS80
VUSB81
V1882 AVSS3 83
VBAT87
DVCC389
DVSS3 90
U2B
X2
12345
D1_
5VC3
7
R31
R32
C38
C39
R33
C40
C41
Q11
2
3
R35
VCC
1N
C2
IO1
3
GN
D4
IO2
5
U8
SV2
135
246
7911
8101214 13
SV1
135
246
79
810
111315
121416
R34
C42
IN1
NC_22
GND3
FB/NC 4NC 5
OUT 6EPAD GND
U9
C43C44
C45C46
LED2
LED1
R36
R37
LED
3R1
CP11
CP22
VCP3
VMA4
AOUT15
ISENA6
AOUT27
BOUT28
ISENB9
BOUT110
VMB11
AVREF12
BVREF13
GND_214
V3P3OUT 15NRESET 16NSLEEP 17NFAULT 18DECAY 19
DIR 20NENBL 21
STEP 22NC 23
MODE0 24MODE1 25MODE2 26NHOME 27
GND 28EPAD GND
U3
C1
C2
JP1
1234
C3
C4
R2
C5
C6R3 R4
R5
R6
CP11
CP22
VCP3
VMA4
AOUT15
ISENA6
AOUT27
BOUT28
ISENB9
BOUT110
VMB11
AVREF12
BVREF13
GND_214
V3P3OUT 15NRESET 16NSLEEP 17NFAULT 18DECAY 19
DIR 20NENBL 21
STEP 22NC 23
MODE0 24MODE1 25MODE2 26NHOME 27
GND 28EPAD GND
U4
C7
C8
JP2
1234
C9
C10
R7
C11
C12R8 R9
R10
R11
CP11
CP22
VCP3
VMA4
AOUT15
ISENA6
AOUT27
BOUT28
ISENB9
BOUT110
VMB11
AVREF12
BVREF13
GND_214
V3P3OUT 15NRESET 16NSLEEP 17NFAULT 18DECAY 19
DIR 20NENBL 21
STEP 22NC 23
MODE0 24MODE1 25MODE2 26NHOME 27
GND 28EPAD GND
U6
C13
C14
JP3
1234
C15
C16
R12
C17
C18R13 R14
R15
R21
CP11
CP22
VCP3
VMA4
AOUT15
ISENA6
AOUT27
BOUT28
ISENB9
BOUT110
VMB11
AVREF12
BVREF13
GND_214
V3P3OUT 15NRESET 16NSLEEP 17NFAULT 18DECAY 19
DIR 20NENBL 21
STEP 22NC 23
MODE0 24MODE1 25MODE2 26NHOME 27
GND 28EPAD GND
U7
C25
C26
JP5
1234
C27
C28
R22
C29
C30R23 R24
R25
R26
CP11
CP22
VCP3
VMA4
AOUT15
ISENA6
AOUT27
BOUT28
ISENB9
BOUT110
VMB11
AVREF12
BVREF13
GND_214
V3P3OUT 15NRESET 16NSLEEP 17NFAULT 18DECAY 19
DIR 20NENBL 21
STEP 22NC 23
MODE0 24MODE1 25MODE2 26NHOME 27
GND 28EPAD GND
U10
C31
C32
JP6
1234
C33
C34
R27
C35
C36R28 R29
R30
R38
SV3
1 2 3
S2
3 124
S1
3 124
C47C48C49
INPUT1
COMMON_2 2
OUTPUT 3
COMMON 4
U11C50
C51
C52
GN
D
DM
DM
DPDP
MODE0
MODE0
MODE0
MODE0
MODE0
MODE0
MODE0
N$45
N$45
LED2LED2
MODE1
MODE1
MODE1
MODE1
MODE1
MODE1
MODE1
MODE2
MODE2
MODE2
MODE2
MODE2
MODE2
MODE2
STEP
STEP
STEP
STEP
STEP
STEP
STEP
DIR
DIR
DIR
DIR
DIR
DIR
DIR
NENBL_0
NENBL_0
DECAY
DECAY
DECAY
DECAY
DECAY
DECAY
DECAY
NRESET
NRESET
NRESET
NRESET
NRESET
NRESET
NRESET
NSLEEP
NSLEEP
NSLEEP
NSLEEP
NSLEEP
NSLEEP
NSLEEP
NENBL_1
NENBL_1
NENBL_2
NENBL_2
NENBL_3
NENBL_3
NENBL_4
NENBL_4
NENBL_5
NENBL_5
N$46
N$46LED1
LED1
PURPUR
5V
5V
5V
VBUS
VBUS
VBUS
12V 12V
12V
12V
12V
12V
12V
12V
12V
Serial I/O
JTAG
ESD
pro
tect
ion
USE CSTCR4M00G15L99-R0
MSP430F6659
5.1V
Zen
er
Fig. 6: Stepper Driver Circuit
the chips separately. This is shown in a simplified versionof the interface in Figure 7. The result is the same ashaving a different step signal for each DRV8825 exceptthat there is far less power consumption due to only onedevice being enabled at a time instead of all six.
MSP430
DRV8825
DRV8825
x6
STEP
DIRECTION
ENABLE[5:0] 6
Fig. 7: Stepper Control Interface
D. Physical Structure
The physical structure of the robot is shown in Figure 2.The primary goal of the design was to allow any face ofthe cube to be turned without having to reorient the cubeitself. The advantage of doing this is that it minimizesthe number of commands that are needed to solve thecube. To implement this design, a motor is attached tothe center tile of each face. Rotating the center tile willcause the entire face to be rotated. Because the cube isinternally connected by the center tiles of each face, thepositions of these tiles do not move relative to each otherand thus the cube can be help stationary this way withoutlimiting the ability to manipulate it.
The structure is divided into six separate pieces thatare meant to hold each of the six motors. As shown in
Figure 2, one of the motor supports will support the Pixycamera so that it can capture the colors of the tiles onone edge of the cube. Although the robot will be ableto scramble a cube on its own, the modular assembly ofthe robot allows it to be easily detached from the cubeso that a human can remove it and scramble it manually.
The Rubik’s Cube is connected to the stepper motorsby a 3D-printed motor shaft attachment that is designed toreplace the center tiles of the cube. It is nearly identical tothe original cube tile except that it has an outward-facingfemale connector for the motor shaft. To ensure that theconnection is tight, the plastic connector is heat-fitted tothe motor shaft once it is in place.
V. SYSTEM OPERATION
The operation of our system depends on all individualhardware and software components working togethercorrectly. This section discusses the integration of oursystem components and reviews the flow of operationfor the system to complete its task of solving a Rubik’sCube.
A. Determining Cube State
The system operation begins with a scrambled Rubik’sCube being present within the physical structure. If thecube is not already scrambled, the GUI can be used toinstruct the robot to automatically scramble the cube.Following this, the first goal of the system is to use thePixy camera to detect the signature colors of the cube.Because the Pixy is stationary and has a limited view ofthe cube, it is necessary to rotate the cube several times inorder for the Pixy to gather all the necessary information.The software keeps track of the transformations that aremade and will returm the cube to its original scrambledstate after all the cube data is collected. The informationgathered is sent to the software application over a USBconnection and is used to form a data structure thatrepresents the positions and colors of the tiles of thescrambled cube.
B. Determining Cube Solution
Once a data structure has been formed within thesoftware, The user can use the GUI to instruct the robotto solve the cube. Here, Kociemba’s algorithm is appliedto determine the shortest possible series of manipulationsnecessary to solve the cube. The output from this solvingalgorithm exists as a string of characters that indicatesthe order and direction that the faces of the cube needto be turned. An example of this string is shown below:
DLD′L′F ′UL′RRU ′BD′UL′UR′BBR′F
Where the letters correspond with the faces of the cube,and a tick mark (′) indicates a counter-clockwise directionof rotation. Clockwise direction is the default directionof rotation. This string of characters is sent over a UARTconnection to the embedded system.
C. Performing Cube Manipulation
Once the embedded system receives the solving se-quence from the software application, it deciphers theinformation to determine which motors need to be turnedas well as the directions of rotation. The timing ofthe motor actuation is optimized to perform the cubemanipulation as fast as possible.
D. Assessment of Completion
The embedded system will communicate to the soft-ware when the prescribed manipulations have beencompleted. At this time, our software can instruct thePixy to assess the cube once again to verify that the Cubehas been solved correctly. If it is necessary, the solvingprocess can be automatically initiated again to attemptto solve the cube to completion.
VI. CONCLUSION
In this paper we present the design of a robotic systemfor autonomously solving a Rubik’s Cube puzzle. Ourunique implementation demonstrates application-specifichardware and software design for a high-level solutionto this challenge. The contributions of our work supportthe ongoing quest to solve a Rubik’s Cube puzzle inthe fastest time possible. As a result of this project, wehave gained hands-on experience with engineering design,prototyping, and production.
ACKNOWLEDGMENTS
The authors would like to thank Dr. Samuel Richieand Dr. Lei Wei for their guidance in Senior Design Iand Senior Design II.
REFERENCES
[1] H. Kociemba. Cube explorer 5.12 htm and qtm. [Online].Available: “http://kociemba.org/cube.htm”
[2] Adafruit NEMA-17 Stepper Motor, Adafruit. [Online]. Available:“https://www.adafruit.com/product/324”
[3] MSP430F665x, MSP430F645x, MSP430F565x, MSP430F535xMixed Signal Microcontrollers, Texas Instruments. [Online].Available: “http://www.ti.com/lit/ds/symlink/msp430f5659.pdf”
[4] DRV8825 Stepper Motor Controller IC, Texas Instruments. [On-line]. Available: “http://www.ti.com/lit/ds/symlink/drv8825.pdf”
[5] sample author, “sample title,” Proceedings of the IEEE, vol. 103,no. 4, pp. 665–681, 2015.
