Registration number 100047218

2016

Final Project

Supervised by Dr Graeme Richards

University of East Anglia

Faculty of Science

School of Computing Sciences

Abstract

The main goal of this project is to create a system made out of Lego that can physically

solve a 3x3 Rubik’s Cube. The final system should be able to take any scrambled cube,

scan and solve it.

Acknowledgements

I would like to thank my supervisor, Dr. Graeme Richards for his advice and suggestions

throughout the project. I would also like to thank parents for their unending support that

motivated me to complete this project.

CMP-6013Y

Contents

1 Introduction 5

1.1 Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Areas of Knowledge Required . . . . . . . . . . . . . . . . . . . . . . 5

2 Related Work and Context 6

2.1 General Robotics Research . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 About the Cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Lego Rubik’s Cube Solver Systems . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Simple Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2 Mixed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Solving Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Design Methodology and Roadmap 19

3.1 Key Points When Creating and Updating the Roadmap . . . . . . . . . 20

4 Programming, Engineering and Design 21

4.1 Platform and Language . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Methods and Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3.1 Scanning with the RGB Sensor . . . . . . . . . . . . . . . . . 24

4.3.2 Scanning with the Web-Cam . . . . . . . . . . . . . . . . . . . 24

4.4 Cube Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Translating to Robot Movements . . . . . . . . . . . . . . . . . . . . . 30

5 Outcome, Analysis and Results 35

5.1 Analysed Test Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Timing Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.2 Success Rate Analysis . . . . . . . . . . . . . . . . . . . . . . 40

5.1.3 Move Count Analysis . . . . . . . . . . . . . . . . . . . . . . . 40

Reg: 100047218 iii

CMP-6013Y

6 Project Evaluation 40

6.1 Project Aims Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Future Research Topics . . . . . . . . . . . . . . . . . . . . . . . . . . 41

References 42

Reg: 100047218 iv

CMP-6013Y

1 Introduction

This document involves the research, methodologies and test data of the work that has

been done in order to create a system that can solve a 3x3 Rubik’s Cube.

1.1 Aims

Main aim is to create a robot made out of LEGO and programmed to solve a 3x3 Rubik’s

Cube. There are many possible design approaches, which affect the programming at the

same time, therefore secondary aims include:

• To make and a robot made out of LEGO and programmed to solve a 3x3 Rubik’s

Cube while using the RGB scanner sensor. This robot is the MindCuber model

and it uses the default software.

• To create a robot made out of LEGO and programmed to solve a 3x3 Rubik’s

Cube while using a web-cam as the scanner. This robot is the modified version of

the MindCuber model and it is programmed from scratch using Matlab.

1.2 Areas of Knowledge Required

• Engineering

The engineering aspect of the project consists of manufacturing the system that

will interact with the cube. That means all the physical movements and rotations

along with the method of scanning.

The NXT EV3 version that is being used on this project has three motors and

two sensors. Sensors being, the Ultrasonic Sensor and the RGB sensor. Different

engineering methods can be used to utilize these sensors and motors.

Reg: 100047218 5

CMP-6013Y

• Programming

In terms of programming, the robot has to perform given tasks such as moving

the motors to interact with the cube. It also has to perform calculations and store

data in order to solve the cube. Since the robot cannot perform cube rotations

like human hands there are additional steps involved in addition to the traditional

Rubik’s Cube solving algorithms.

2 Related Work and Context

2.1 General Robotics Research

“Robotics is the branch of mechanical engineering, electrical engineering, electronic

engineering and computer science that create reprogrammable, multifunctional manip-

ulator designed to move material, parts, tools, or specialized devices through various

programmed motions for the performance of a variety of tasks.” (6)

Figure 1: Lingodroids

Figure 2:

Reg: 100047218 6

CMP-6013Y

“Artificial intelligence (AI) is the intelligence exhibited by machines or software”. “I

believe that at the end of the century the use of words and general educated opinion

will have altered so much that one will be able to speak of machines thinking without

expecting to be contradicted” - Alan Turing. (4)

The Lingodroid are robots that can generate random sounds according to their sur-

roundings, then they create “words” and signal to other robots.(14) When the robots are

in an environment that they are not familiar with they create these words to name the

places. In an experiment the robots generated place names such as “kuzo”, “jaro” and

“fexo”. The Lingodroid s ability to find a way to understand name the locations lead

to the development of a similar concept in this project when scanning the cube. This

concept involves clustering methods to classify the data.

It would be impossible to upload all the locations names to the The Lingodroid so

they found a way to let the robots do it on their own. Similarly this project involves

recognition of the colours on the cube in order to solve the cube. The light intensity of

the environment and the colour of the cube can vary significantly, therefore hard coding

default threshold values for each colour proves very non-effective. The solution to this

is letting the robot “learn” the difference between the colours which is explained in the

report.4.3

2.2 About the Cube

The Rubik’s Cube, the worlds best selling toy, was invented by Erno Rubik in 1974.

Erno was a Professor of architecture at the time. When he realized the potential of this

object he invented he decided to get it manufactured. It soon become a huge success in

Hungary, but any imports and exports were tightly controlled. Erno asked mathemati-

cians to take the cubes with them to any conferences they attend, to make the cube more

famous. A Hungarian entrepreneur took the cube to a Toy Fair in 1979 where he met

Tom Kremer who agreed to sell it to the rest of the world.

Since its international launch in 1980 approximately 350 million Rubik’s Cubes have

been sold. “If you are curious, you’ll find the puzzles around you. If you are determined,

you will solve them.”-Erno Rubik (13)

Reg: 100047218 7

CMP-6013Y

• Corner Pieces

There are eight corner pieces on a standard 3 x 3 Rubik’s Cube. These pieces have

three sides with three different colours

• Edge Pieces

Edge pieces are the pieces that connect two corner pieces with the center piece.

There are a total of twelve edge pieces on a standard 3 x 3 Rubik’s Cube. These

pieces have two sides with two different colours

• Center Pieces

These pieces can not be moved, can only be rotated and therefore represent the

color of the side of the cube they are on. All of the center pieces are actually

connected from the inside of the cube. Even though there is only one piece in

reality, six of them can are visible from the outside of a standard 3 x 3 Rubik’s

Cube.

Reg: 100047218 8

CMP-6013Y

2.3 Lego Rubik’s Cube Solver Systems

2.3.1 Simple Systems

The similar systems analysis conducted helped find two robots named ’Tilted Twister’

and “Tilted Twister 2.0” (3). These robots had no extra parts other than the very first

Lego Robot NXT and it’s predecessor NXT 2.0 kits and were able to solve 3x3x3 Ru-

bik’s Cubes quite fast. Further investigation lead to the discovery of the newest version

of the kit Lego released which was the Lego EV3.“CubeThunder” system, is the first

system to use the EV3 kit, unfortunately this system did not have much research mate-

rial on-line (2). “MindCuber” EV3 version, was a valuable research subject and a great

starting point, it had decent structural integrity and stable cube interaction compared to

other models.“MindCuber” also had a system that can be built with the NXT version

even though “MindCuber” is mainly popular for its EV3 kit version. (5)

Reg: 100047218 9

CMP-6013Y

2.3.2 Mixed Systems

Finally, The ’Mixed Systems’ which use different materials other than Lego s were re-

searched. These systems had more processing power and faster scanning techniques but

relied on other devices to work with the “Brick”. Most systems used web-cams and

image processing techniques which provided research material about scanning. There

were many similar systems that used ARM Processors and phone cameras but one sys-

tem stood out among the others which was the ’CubeStorm3r’. This robot’s latest ver-

sion currently holds the Guinness World Record for the Fastest LEGO Robot to Solve

a Rubik’s Cube with only 3.253 seconds. (7) This system uses a phone application and

multiple “Bricks”. (Knapp)

Reg: 100047218 10

CMP-6013Y

2.4 Solving Algorithms

There are many ways to solve a 3x3 Rubik’s Cube and these are done by executing

algorithms. The God’s Number is the number of moves required to solve any scrambled

Rubik’s Cube. An experiment that took 35 CPU-years of idle computer time by the

Google Computers solved the Rubik’s Cube for every position possible and concluded

that 20 is the God’s Number. The most efficient algorithm for a given scramble is called

the God’s Algorithm, number of moves in this algorithm is the God’s Number.(16)

The default notation used in the algorithm is shown below:

Reg: 100047218 11

CMP-6013Y

The most famous solving algorithms are:

• F2L Short for First Two Layers. This algorithms is used to solve the first two

layers at the same time, rather than the corners first then the edges.

• OLL Short for Orienting the last layer. Getting all the remaining layers pieces on

the top. This colour depends on which two colours you solved in the F2L stage.

• PLL Short for Permuting the last layer. Switching all the top pieces to finish

solving the cube.

These algorithms are easy to comprehend by humans and therefore very simple. Since

this project involves computers calculating the steps to solve the cube, more difficult

algorithms can be used. In fact the following T45 algorithm is very difficult for a human-

being. (rub)

Thistlethwaite’s AlgorithmThistlethwaite’s Algorithm is an algorithm that solves the cube in a maximum of 45

moves. The algorithm uses a divide and conquer method that divides the problem into

four sub-problems by using the following groups:

• G0 = < F, R, U, B, L, D >

• G1 = < F, U, B, D, R2, L2 >

• G2 = < U, D, R2, L2, F2, B2 >

• G3 = < F2, R2, U2, B2, L2, D2 >

The idea behind this algorithm is to change the state of the cube until it becomes

solvable only by using moves from one of these four groups. This state is reached by

using these four groups as well.

Reg: 100047218 12

CMP-6013Y

These groups are also called corset spaces. Starting from G1 these corset spaces

show different cube states. G1 contains all the cube states where the edge orientation is

insignificant.

G2 only contains states where no corner orientations can be altered, which means

some positions can be ignored. Other states can also be ignored since the edge pieces

can not be transported to or from the middle layer.

G3 only contains states where cubes L and R layers can not be transferred to another

layer.

There is another state G4 which is the solved state. In the last state transfer from G3

to G4 there are G3 possible states to be calculated in order to solve the cube.(12)

Reg: 100047218 13

CMP-6013Y

The only drawback of this algorithm comes from the divide and conquer nature of it.

Even if the solution is very simple, algorithm goes through all the steps. This prevents

the algorithm to come up with the shortest solution. This is an algorithm popular for

Reg: 100047218 14

CMP-6013Y

its worst case performance. It is highly stable when the complexity of the scramble

increases as seen on the figure below 2.4. This test is done by a random move generator

created on Matlab. The method creates a cube with given number of random rotations

applied to it. The solving algorithm is then applied to get the move array. The length of

the array shows the amount of rotations that have to be applied to the cube in order to

solve it.

Layer by Layer

Reg: 100047218 15

CMP-6013Y

Reg: 100047218 16

CMP-6013Y

This is the standard solution for beginners. This method has seven stages. The idea

is to solve the cube one layer at a time.(9)

• Solving the white cross

To create a white cross pattern on the white side of the cube, solver needs to align

the edges and apply the following sequence of moves.

moveset = R’,U’,F’,U’

• Solving the white corners

In order to finish the white side, corners need to be placed correctly. Corner pieces

need to be correctly aligned for all of the three colours they have. The following

sequence is repeated until the corner is in the correct orientation and position.

moveset = R’,D’,R, D

or

moveset = R’, D’, R if the piece is on the top face.

• Solving the middle layer

The middle layer is completed by moving the edge pieces to the middle layer

either on the left or right of the middle piece. Two move sequences below are

applied to the cube to be able to do this.

RIGHT:

moveset = U’, R, U’, R’, U’, F’, U, F

LEFT:

moveset = U, L’, U, L, U, F, U’, F’

• Solving the top layer cross

Just like the white cross, the next step is to solve the yellow cross. However, the

moves are different since the algorithm needs to maintain the position of the other

layers. The sequence below is applied to the cube until the cross is completed.

moveset = F, U, R, U’, R’, F’

Reg: 100047218 17

CMP-6013Y

• Solving the top layer

After holding the cube in the correct orientation, following moveset is applied to

the cube until all the corners are yellow and facing up.

moveset = R,U,R’,U,R,U,U,R’

• Positioning the yellow corners correctly

The position of yellow corners are corrected by the sequence.

moveset = R’, F, R’, B, B, R, F’, R’, B, B, R, R, U’

• Positioning yellow edges correctly

If the top face has four incorrectly positioned edges moveset1 should be applied,

if there are three incorrectly positioned edges moveset2 should be applied.

moveset1 = F, F, L, R’, F, F, L’, R, U, F, F

moveset2 = F, F, U’, L, R’, F, F, L’, R, U’, F, F

Reg: 100047218 18

CMP-6013Y

3 Design Methodology and Roadmap

A roadmap is created to show the path taken in order to complete the project. The

roadmap has been updated for various reasons throughout the project. The figure below

shows the steps involved. An initial system that successfully interacts with the cube is

built. The system is then tested before the scanners are added. Two optional scanners

are added to the system and tested for consistency. Final stage is the solving stage that

involves the algorithms.

Reg: 100047218 19

CMP-6013Y

3.1 Key Points When Creating and Updating the Roadmap

After looking at different systems and building them, problems with the physical sys-

tem became more obvious. Mechanically Lego’s are not the best building materials

for a robot, and the moving joints with the motors have to be quite precise. There

are robots on-line which are glued together that can possibly provide a solution to this

problem. There were instances where the robot arm failed to grasp the cube after mul-

tiple runs.This is the reason an additional step “Consistency” was added to the map. A

consistent system is vital to the success of the project.

Figure 3: Road Map

Figure 4:

Reg: 100047218 20

CMP-6013Y

4 Programming, Engineering and Design

4.1 Platform and Language

Many potential platforms and languages were investigated throughout the project, how-

ever most were immediately eliminated for various reasons. These reasons included

past experience, lack of practicality, and lack of readability of the API syntax. C like

languages were also avoided as a matter of personal preference.

Lego s own drag and drop style coding software was tested first. It was found easy

to use but ultimately inadequate. However, it allowed for a fast and easy start to test the

motors to observe how they operated. The project blog (8) was updated in light of these

experiments for further reference. For a project that is extremely complicated in terms

of data structures and operations, it was not very sensible to keep using this software.

In order to scan the cube with the web-cam an image processing software had to be

used along with the system. Matlab proved to be a very useful tool since it supported

both image processing and LegoEv3 toolboxes. All of the coding has been done on

Matlab after the initial tests.

4.2 Methods and Libraries

List of the methods:

• TranslateSolution

This method takes in the solution on the normal notation form and translates it to

robot notation2.4 as explained in the “Translating to Robot Movements” section

4.4 .

• TranslateCube

This is a method that takes in the cell array that represents the cube and translates

it into a more easily readable data structure. The output data is R(3,3,6) while the

input is Cube(6,9). Appropriate indexing and array rotations are applied to the

input matrix to produce the output.

Reg: 100047218 21

CMP-6013Y

• SavecoloursWithDifference

This method takes in an array of average RGB values. Loops through all the

values and normalises them as explained here 4.3.2. The output of this method is

the normalised array. It is also possible to take the six unique colours from the

cube as RGB values.

• ReadValues

This method is called when scanning. It takes a web-cam object as input, takes

a snapshot with it, lays a grid and records the RGB values to get an average

value from the pixels in that grid. The code in this method is highly flexible, it is

extremely easy to change the size and the length of the grid squares. This can be

used in the future for scanning different sized cubes.

• getcolours

This method takes in an array of values, output of SavecoloursWithDifference,

and compares them to the pieces that represent the colours as explained here 4.3.2.

The output is a cube array in the form of Cube(6,9).

• compare

This is a simple method that takes in two color arrays, calculates the euclidean

distance between each color space element(r,g,b). Adds them up and returns the

value.

• rubplot

This method is a method that belongs in the Rubik’s Cube Simulator and Solver

Solution library. It shows a graphical representation of the scanned cube.

• Solve45

This method is a method that belongs in the Rubik’s Cube Simulator and Solver

Solution library. It takes in a Rubiks Cube object and returns the solution in a cell

array format.

Reg: 100047218 22

CMP-6013Y

• Tumble

Takes in the robot object and a number that indicates the number of times the

motion will be executed. If the number is negative the motion is executed number

* -1 times in the opposite direction.

• NoLockRotateB

Takes in the robot object and a number that indicates the number of times the

motion will be executed. If the number is negative the motion is executed number

* -1 times in the opposite direction.

• MoveMotorA and MoveMotorB

Takes in the speed and the finish rotation variables, starts the relevant Motor with

these parameters. A variable called margin is used to give the robot a room for

error, since it is not very precise. The rotation is checked after the rotation and if

the rotation angle does not fall in the given margin, a reverse rotation is applied.

The rotation gets inverted until the desired margin is reached.

• LetGo

Simply takes in the robot object to lift the arm.

• Hold

Simply takes in the robot object to lower the arm.

• ExecuteRobotMovements

Takes in the robot object and the translated robot solution. Loops through the

instructions and calls the appropriate robot movement method. 2.4

Rubik’s Cube Simulator and Solver Solution by Joren Heit(15)

A library has been used used for the Thistlethwaite 45 Rubik’s cube solver algorithm

implementation as well as the rubplot function which plots the scanned cube. The solver

function requires the data to be in a very specific format. The colours are represented

by numbers because of this 2.2.

Reg: 100047218 23

CMP-6013Y

4.3 Scanning

4.3.1 Scanning with the RGB Sensor

The RGB sensor is used to send light to the pieces on the Rubik’s Cube and measure

the light intensity that reflects from the piece. The Red, Green and Blue values are

then extracted from the reflected light value. These values are then compared with the

pre defined values that represent the colours on a standard Rubik’s Cube; red, white,

green, blue, orange and yellow. If the RGB values are within a certain range of these

predefined values, that piece is added to the array with the matching color index. Al-

though this scanning method requires almost no processing it is highly unreliable. The

predefined(hard-coded) values can cause problems when the Cube reflects more light

than it should when put into an environment with more background light. This will alter

the RGB values received from the pieces of the cube.

For example, when exposed to a light with higher intensity, red can be observed as

orange which can confuse the scanner.

When it comes to speed, the scanner has to scan every piece on the cube which means

54 scans. To be able to do this, the arm that holds the sensor has to move between the

center piece and the edge pieces. The platform under the cube has to rotate and the arm

that creates the tumble motion has to move.

4.3.2 Scanning with the Web-Cam

Data Mining and Computer Vision techniques have been used while scanning with the

web-cam. (Kovesi) The process includes taking a snapshot of each side of the cube and

processing the images. A grid is then applied to the image which perfectly partitions

the pieces of the cube. Every pixel in each piece of the grid is scanned to get an average

RGB value. This is done because certain areas of the piece can be lighter than others,

the collected data can be false if it is taken from a single pixel. Since the center pieces

can never be moved they show the color of the side they are on. The scanning can be

done in a specific order if the user wants to know which value represents which color;

for example :red, blue, orange, green, white, yellow.

Reg: 100047218 24

CMP-6013Y

The scanning can also be done in any order but for the purpose of this assignment the

scanning will be done in a specific order. Finally, the program scans the middle piece

and assigns the RGB value to a color.

After all the RGB values are stored, an euclidean distance function is used to measure

the difference between the RGB values. If the difference is minimal the values are

normalized. For instance, if the difference between the RGB value of the piece x = 1, y

= 1 and RGB value of the piece x = 3, y = 3 is less than 0.1, the program decides that

these are the same color and assigns the RGB value of the first piece to the second.

The final step is comparing all the normalized RGB values against the middle-piece

values that represent different colours. The euclidean distance function is used here once

more to measure the difference of the pieces and colours. If the difference is minimal

that piece is assigned that color. For example if a given piece is similar to the middle

piece of the first side, that piece is now the color of the middle piece of the first side.

The scanning time is radically improved when this method is used. There are no robot

movements involved in the process since the scanning is done in a different system 4.4.

If the manual side switching is ignored, taking the snapshot and processing the data

Reg: 100047218 25

CMP-6013Y

is very short. Even though it looks like the web-cam scanning method requires more

processing power - considering all processing is done on a computer instead of the brick-

processing time is shortened.

Reg: 100047218 26

CMP-6013Y

4.4 Cube Interaction

The robot is very similar to the Mindcuber model except for the scanner. System con-

sists of three motors, one being optional since it is the arm that controls the RGB scan-

ner. Proximity sensor is also optional for the camera build. Two motors are connected

to the Brick in the ’A’ and ’B’ ports. These motors are referred as MotorA and MotorB

throughout the project.

Reg: 100047218 27

CMP-6013Y

• Motor A

This motor is used in three motions: “Tumble”, “Hold” and “LetGo”. When

Tumble is called Motor A goes over the cube and pulls the cube with the friction

force applied from the top, after a certain rotation (around 200 degrees) the cube

gets flipped. Hold and LetGo are methods that are called to either hold the cube

in place or let go of the cube to do a free rotation.

• Motor B

This motor is used in two motions: “FreeRotateB” and “RotateB”. Although these

two methods end up having the same impact on the cube, the speed and rotatio-

nAngle variables are very different. FreeRotateB rotates when MotorA is not

holding the cube and RotateB rotates the cube when MotorA is holding the cube.

When the cube is being held by MotorA, the speed and rotation required to make

a 90 degree turn increases. Instead of having the need to constantly update these

variables the methods are separated.

Reg: 100047218 28

CMP-6013Y

• Scanner

This system was separated from the solver system because of the data gathered

from the initial scan tests. For the camera scan to work perfectly the cube has to be

in the same place and orientation. The robots moves proved unpredictable while

rotating and ultimately lead to errors in the scanner system. Scanner system has

the web-cam, a tripod and cardboard half-box to keep the cube from moving. The

web-cam is placed right on top of the cube to scan the top face. The legs of the

tripod are blu tacked to the surface to prevent any external factors from tilting or

moving the camera during the scan. This system is manually operated, meaning

the cube needs to be physically flipped in order to continue with the scan.

Reg: 100047218 29

CMP-6013Y

4.5 Translating to Robot Movements

A solution for the given cube is generated using the solving algorithm, however this

solution is formatted in a way that assumes that certain color sides are in the “Front”

and “Up” states all the time. Most algorithms will come up with a solution that requires

the cube to be held with the Red side facing towards the solver and the white or yellow

face pointing upwards. The moves generated have to be executed while cube is in this

state otherwise the system will not be able to solve the Rubik’s Cube. The way the

current system is, it is not possible to keep the cube at the same state all the time. There

are some systems that use multiple bricks and motors to make this possible 2.3.2.

Translating the solution into robot movements requires certain steps.

Firstly the cube’s state has to be tracked. The cube’s state can be tracked with only

two variables, face and up. The starting values for these variables are white for up

and red for face. These variables need to updated after every step of the algorithm.

Reg: 100047218 30

CMP-6013Y

Secondly, a given step from the initial solution must be translated into a new notation

used by the robot. For example, when up is white and face is red, step “U” is translated

into “ Tumble2, RotateB’ ”.

Translation process involves three methods.

• instruction = TranslateMove(solution(index), face, up);

• aSolution = GetRobotMove(instructions);

• (face, up) = UpdateFaces(aSolution, face,up);

These methods are run in a loop and are executed for every item in the fed array,

human solution(for index = 1: length(solution)). An item is fed into the method Trans-

lateMove along with the orientation state of the cube. The method converts the given

instruction to the corresponding instruction that is correct for the orientation.

Reg: 100047218 31

CMP-6013Y

TranslateMoveTranslateMove works with four sets. These sets have all the possible instructions.

• moveset = ’R’, ’F’,’L’,’B’,’D’,’U’;

• moveset2 = ’R2’, ’F2’,’L2’,’B2’,’D2’, ’U2’;

• moveset3 = ’R”, ’F”,’L”,’B”,’D”,’U”;

• moveset4 = ’R2”, ’F2”,’L2”,’B2”,’D2”,’U2”;

The method uses a modulo operation to give the correct translated move. “Up” value

is checked before checking the given move. A variable moveNo is used in the mod-

ulo operation. The index of the correct move is calculated by the equation: index =

mod((moveNo + face-1), 4). Finally the element in the correct moveset with the index

number is returned.

Once the instruction is acquired it is fed into the method GetRobotMove. GetRobot-

Move takes the instruction, translates into a set of instructions that correspond to robot

movements. These instructions are standard for the values “face = red, up = white”.

This is the reason we translate the instruction in the first place.

Reg: 100047218 32

CMP-6013Y

The final method UpdateFaces takes the robot moves and updates the current face and

up values. UpdateFaces uses an algorithm to produce these results.

UpdateFacesColor codes are again utilised here: Red = 1, Blue = 2, Orange = 3, Green = 4, White

= 5, Yellow = 6. An algorithm is implemented in this method that uses the five arrays

that are the diagonals for a given “up” value. The “up” also decides the middle layer.

Two indexes are created, the first one being “diagno” and the second being “index”.

Diagno is the index number that shows which diagonal array the algorithm should use.

It is equal to the position of the given face value inside the “middle’ layer’ array. Index

is then calculated by finding the position of the “up” value in the chosen diagonal. An

example of a diagonal is: diagonal = [1,5,3,6];

“find(a,b)” function is a Matlab function that returns the index of the element that

meets the condition “a” in the column “b”.

• RotateB

RotateB uses the robots motor connected on the ’B’ port. This motor makes

the rotation motion that helps rotate the cube around the Y axis. This motion

combined with the other motor that is connected in the port ’A’ holding the cube,

creates a motion that twists the lowest layer of the cube. RotateB is the notation

for a single 90 degree turn on the motor B. RotateB’ is the same motion with a

negative speed variable for an inverse rotation. The number next to the notation

indicates how many times this motion has to be repeated.

Reg: 100047218 33

CMP-6013Y

• FreeRotateB

FreeRotateB is the same 90 degree turn but without the “A” arm holding down the

cube. This means the speed and rotation angle parameters are different to the ones

from RotateB. There is less friction between the cube and the MotorB therefore

speed should be decreased along with the rotation angle.

• Tumble

Tumble uses the robots motor connected on the ’A’ port. This motor is the arm

that holds or pushes the cube. Tumble is the motion that goes over the cube, grabs

it and then pushes it to make a tumble motion. The number next to the notation

indicates how many times this motion has to be repeated.

Reg: 100047218 34

CMP-6013Y

5 Outcome, Analysis and Results

5.1 Analysed Test Data

These results are gathered from the tests carried out on the MindCuber system 5.1 . The

cube has been scrambled randomly for a random amount of moves before the test was

carried out. Twenty tests were carried out and the fourteen of these tests were success-

ful. Most of the unsuccessful tests are caused by the RGB sensor failing to recognise

the difference between red and orange. Once in twenty times the robot fails to create a

tumble motion which causes the error. It can be concluded from the results that the sys-

tem compensates for the lack of reliability of the scanner with the near perfect accuracy

of the physical interaction with the cube. The Lego software used in th development of

this system makes sure the moves are accurate. The scan time and solve time and move

count data are very consistent throughout.

Reg: 100047218 35

CMP-6013Y

These results 5.1 are gathered from the tests carried out on the Camera Build system

created in the project. The cube has been scrambled randomly for a random amount

of moves before the test was carried out. Twenty tests were carried out and the sixteen

of these tests were successful. All of the unsuccessful tests were caused by the robot

unsuccessfully physically interacting the cube, while doing the tumble motion to be

specific. The scanning is quite accurate in this system 5 so none of the failed attempts

were caused by a scanning error. The Matlab Lego toolbox does not give the amount of

control over the motors that is required to carry out the robot movements very accurately.

Reg: 100047218 36

CMP-6013Y

Reg: 100047218 37

CMP-6013Y

Comparing the two systemsIt can be seen that the Camera Scanner system looks inferior in most ways; scan time,

solve time and move count. However, it can also be seen that the success rate is higher.

It is also extremely important to look at the causes of the errors while comparing the

two systems. While the RGB Scanner system has failed to scan the cube multiple times,

Camera Scanner system has failed to correctly carry out rotation and tumble motions.

It is also worth mentioning that the Camera Scanner system used lower speed values on

the motors to increase precision, resulting in the solve time to be much longer. These

two systems both have their strengths but robot movements can be easily improved in

the future where the scanning is much more complicated.

5.1.1 Timing Analysis

• Scan Time

Scan time for the RGB Scanner system gives an average of 27.03 seconds. This

means the scanning takes 23 % of the total time. This time , although improvable,

is a good compromise if the success rate is very high. In other words, provided

the RGB scanner scans the cube successfully every time, 27 seconds is tolerable.

However, as shown on the graph 5.1 and analysis below, RGB sensor build does

not have a very good success rate. The system repeats the scanning process if

the scanned cube is not legal. The scanning is repeated up to three times before

aborting the run. This is not reflected to the data as it can alter it. In theory, if the

process is repeated multiple times before a successful scan, it can take up to three

times as long.

Camera Scanner system works a little different to RGB sensor. Cube needs to be

manually flipped by the user and this process can either be timed or not, depending

on which time the analyst is looking for. If the analyst is looking for the CPU

time(time it takes for the system to carry out a given operation) then it is very

minimal. If the analyst is looking for the time passed in real life seconds, it

actually takes longer to scan the cube using this system assuming the RGB scanner

was successful on the first attempt 5.

Reg: 100047218 38

CMP-6013Y

• Solve Time

The average solving time for the RGB sensor is 88.57 seconds, 57 % of the total

time. Solving requires the cube to be twisted, rotated and flipped. One in twenty

times the MotorA failed to grasp the cube properly which resulted in a 5% error

rate. Considering the nature of the Lego robots this is more than acceptable.

Solving stage for this system is very fast and accurate.

Camera Scan system has an average solve time of 138.92 which is 77% of the total

time. This percentage is extremely high and it shows that solving takes longer than

it should when compared to the RGB system. As stated in the comparison 5.1,

speed values are significantly lowered in order to increase precision. However,

even with the improved precision error rate is still 20%. To sum up, solving stage

is very slow and inaccurate.

Figure 5: Camera Timing Experiment

Figure 6:

Reg: 100047218 39

CMP-6013Y

5.1.2 Success Rate Analysis

The data suggests that the Camera Build is less stable on the solving stage while phys-

ically interacting with the cube. On the other hand since the the RGB sensor build is

using the Lego software, it is very reliable in the solving stage. Except for the Tumble

motion failing on very rare occasions, the RGB solver almost caused no errors.

The Camera Scan proved superior to the RGB scan. It is, in theory, bulletproof. If

there are no external factors affecting the system between scans, error rate is 0 %. 5

Camera Scan system has 20% error rate and all of these errors were caused by the poor

cube interaction.

5.1.3 Move Count Analysis

Both systems have a very similar average value when it comes to move count. RGB

Sensor system with 23.55 and Camera Scan system with 26.40. It is evident that the

two systems use a very similar solving algorithm.

6 Project Evaluation

6.1 Project Aims Evaluation

The main aims of the project were successfully accomplished as proved by the data. The

Camera System has been built, programmed and tested against MindCuber - the RGB

sensor built . The system successfully scans the cube using the camera, comes up with

the correct algorithm and solves it by using the motors. The data proves that the scanner

system is very accurate but some problems can be encountered while physically solving

the cube. The system accurately came up with an algorithm in all of the tests carried out

and the solution was also accurately translated into robot movements. The initial plan

to include the scanner in the system has been changed in order to improve the success

rate of the scans, therefore making the robot non-autonomous.

Reg: 100047218 40

CMP-6013Y

6.2 Future Research Topics

• Scanning

Although scanning is very accurate in the current system, it had to be moved

out of the solver system for reasons given here 4.4. Computer Vision aspect of

the program can be improved to track down the cube with, laying the grid in the

right orientation and position. This will allow the camera to be integrated into

the solver system, making the robot fully autonomous. Different color spaces like

Adobe RGB can be explored in order to maximise scanning accuracy.

• Solving

Algorithm used in the current system is a very good one for worst-case scenar-

ios but sometimes gives solutions that are too long for easy scrambles. Multiple

algorithms can be integrated into the system to find the shortest solution for a

given scramble. A robot code solution can be written to eliminate the translation

process.

• System

The current system only has two motors that interact with the cube. This causes

the robot solution to be longer than it has to be. Provided the cube can be ma-

nipulated in the same way humans manipulate it, the solution length would be

equal to the robot solution length. This system would require different Bricks to

work simultaneously, which means threading would be necessary. However, this

method would improve the solve time drastically.

Reg: 100047218 41

CMP-6013Y

References

[rub] Rubiks Cube. http://www.ingvet.kau.se/juerfuch/kurs/sgat/prst/s11cubP.pd f .

[2] (2012). Cubethunder. https://www.youtube.com/watch?v=P05Q6jSf34c.

[3] (2012). Tiltedtwister. http://tiltedtwister.com/tiltedtwister2.html.

[4] (2014). http://www.turing.org.uk/scrapbook/test.html.

[5] (2015). MindCub3r. http://mindcuber.com/.

[6] (2016). http://www.cs.cmu.edu/ chuck/robotpg/robofaq/1.html.

[7] (2016). https://www.youtube.com/watch?v=cO5DLbpp3-M.

[8] (2016). http://berensproject.tumblr.com/.

[9] (2016). How to Solve the Rubik’s Cube.

http://lghttp.38568.nexcesscdn.net/8013252/pdf/uploads/generalcontent/Rubikscube3x3solution−en.pd f .

[Knapp] Knapp, A. Lego Robot Solves Rubik’s Cube In 3.253 Seconds.

http://www.forbes.com/sites/alexknapp/2014/03/17/lego-robot-solves-rubiks-cube-

in-3-253-seconds/.

[Kovesi] Kovesi, P. D. MATLAB and Octave functions for computer vision and image

processing. Available from: <http://www.peterkovesi.com/matlabfns/>.

[12] Nail, E.-S., Sascha, H., and Markus, B. (2010). An Evolutionary Approach

for Solving the rubikâAZs Cube Incorporating Exact Methods. http://www.genetic-

programming.org/hc2010/7-Borschbach/Borschbach-Evo-App-2010-Paper.pdf.

[13] Rosenberg, JenniferRosenberg, J. (2016). Who created the rubik’s cube?

http://history1900s.about.com/od/1980s/a/rubikscube.htm.

[14] Scott, H., David, B., Ruth, S., and Janet, W. (2013). Com-

munication between Lingodroids with different cognitive capabilities.

http://www.itee.uq.edu.au/lingodroids/filething/get/180/heath-etal-icra2013.pdf.

Reg: 100047218 42

CMP-6013Y

[15] Solver, R. (2016). Rubik’s cube simulator and solver - file exchange - matlab

central. http://www.mathworks.com/matlabcentral/fileexchange/31672-rubik-s-cube-

simulator-and-solver.

[16] Tomas, R., Herbert, K., Morley, D., and John, D. (2010). God’s Number is 20.

http://www.cube20.org/.

Reg: 100047218 43