Cube solving Robot

Status
Not open for further replies.
K

Karthik

Veteran
Joined
Mar 23, 2007
Messages
530
Location
Bangalore, India
WCA ID
2008PUTH01
YouTube
Visit Channel
Hi all!
I plan to make a Cube solving Robot this summer.I have a dedicated team and we are planning to start in June.
Well I know a few such robots have already been made but we thought of giving it a shot ourselves.
Firstly we plan to make a simulation of the cube and solve it virtually.
We plan to use Fridrich.
Actually the challenge in coding is the way we represent the cube.What could be the best way to represent the cube so that changes made after each rotation can be simulated easily?
More we dont plan to use a robotic arm(as in Rubot).Because of the complications involved and the cost will not fit into our budget.
After the simulation,we plan to modify the software to turn the 6 faces using 6 computer interfaced stepper motors connected to the center pieces.
This model comes out to be the simplest of the solvers.
I would like to hear yours suggestions and comments on the ideas I have poured.
 
Code: 
class Cube
{
 public:
 Cube(/*Whatever parameters you feel like using*/);
 ~Cube()
 
 void RotateFace(int Face, int Turns); //Face can be one of six predefined constants; Turns is the number of clockwise turns. 
 void ReadCube(); //Scans the cube and fills in the variable information.
 
 private:
 Cubie Cubies[20];
 int SolutionAlgorithm[/*However mcuh memory you want to use */] 
}

class Cubie: public Cube
{
/*Cubie class here */
}

Etc. Simulating a cube shouldn't be that hard if you use OOP.

Good luck with your project!
 
Originally posted by Cubinator@Apr 25 2007, 09:41 PM
Code: 
class Cube
{
 public:
 Cube(/*Whatever parameters you feel like using*/);
 ~Cube()
 
 void RotateFace(int Face, int Turns); //Face can be one of six predefined constants; Turns is the number of clockwise turns. 
 void ReadCube(); //Scans the cube and fills in the variable information.
 
 private:
 Cubie Cubies[20];
 int SolutionAlgorithm[/*However mcuh memory you want to use */] 
}

class Cubie: public Cube
{
/*Cubie class here */
}

Etc. Simulating a cube shouldn't be that hard if you use OOP.

Good luck with your project!
Click to expand...
Simulating a cube is the easy part, solving it is the hard part. Writing code to make a cross would be difficult.
 
Writing code to make a cross would be difficult
Click to expand...
You could do it the quick and dirty way: perform all possible moves on the cube and put the results in memory. Check if one of the results has a solved cross. If it doesn't, perform all possible moves on all in-memory-results and save those, etc.

This will work because 8 moves (max for cross) deep will fit into the memory of any modern computer. You could like at Cube-Explorer, A-Cube or Cubie. Some sources are even available to download
 
Just a quick calculation. This will be almost accurate:
First move: 6 faces, 3 types of turns = 18 possibilities
Next moves: 5 faces, 3 types of turns = 15 possibilities
1. 18
2. 270
3. 4050
4. 60750
5. 911250
6. 13668750
7. 205031250
8. 3075468750

This might seem like a lot, but it is not. Remember GigaHertz cpu's can do giga-amounts (1000000000) of calculations per second! And 8 moves would be maximum. You would be done much sooner on most cases. The 190080 possibilities are for edges only. If you use a dumb brute-force method like I described you will have to do more calculations. You could save those calculations into a solution-array/hashtable for the 190080 edge-cases if you want to be faster/smarter.

http://www.cubestation.co.uk/cs2/index.php...fop/cross/cross
 
I think there are two main approaches of representing the cube.
1.) save the layers. The cube has 6 layers representing 9 stickers. The advantage is that you can relatively easy perform a move.
diag.gif

2.) Save the cubies. You have to save the position of each individual cubie and its orientation. Disadvantage of this approach is, that you can't map your picture of the cube easily (without thinking and writing code ;)) to your cubies.

I prefer approach 1, cause i think you need less code and brain :) than with approach 2. Although approach 2 is much nicer from the view of OOP ^^.
Code: 
class Layer
{
 public static final RED = 0;
 public static final WHITE = 1;
 // ...
 public int[3][3] sticker; //sticker[x][y]
}

class Cube
{
 //0 = U; 1 = F; 2 = B; 3 = R; 4 = L; 5 = D
 private Layer[6] layers;

 public void performR(
 {
  layers[0].sticker[2][0] = layers[1].sticker[2][0];
  layers[0].sticker[2][1] = layers[1].sticker[2][1];
  layers[0].sticker[2][2] = layers[1].sticker[2][2];

  layers[1].sticker[2][0] = layers[2].sticker[2][0];
  layers[1].sticker[2][1] = layers[2].sticker[2][1];
  layers[1].sticker[2][2] = layers[2].sticker[2][2];

  // ...
  // i know, that you can write this code within 4/5 lines, but i want to keep things simple
 }

 public boolean isSolved()
 {
  // also very easy to implement
 }
}


Perhaps you can precalculate all moves which are longer than 8 turns and save them in a file. Save the turns (RUDF'U2...) and something like a matrix (which just contains information about which sticker goes to which position) for each move.

btw.: Have a look at "the mathematics behind cube explorer". Cube Explorer uses a mixture of the cubie and the layer approach.
 
Cube explorer even has a server mode so you can connect it easy to other programs. I don`t know how it works exactly, but with that you would only have to make the robot itself, make sure it makes exactly 90 degree turns and you are set :).
 
Well Joey I agree with you that getting the cross itself is going to be a tough job.The LL is actually going to be the easiest.
And AvG even an 8 move deep brute force method wont be very good.Because later I would like to convert the code to assembly and use a microcontroller instead of the computer to run the robot to make the whole thing portable.
And Cin I agree with you that approach 1 is much easier to code and standard fridrich algs especially can be easily simulated.
I would personally avoid brute-force method as much as possible because I dont want the code to hog too much of my resources.
 
Originally posted by karthikputhraya@Apr 25 2007, 06:23 PM
We plan to use Fridrich.
Click to expand...
Why? I would strongly recommend to not to use Fridrich. There are much more effective methods designed particularly for computers, like Thistlethwaite. It should also be easier to code IMHO.
 
Ya I am actually reading about Ryan Heise's Thistlethwaite algorithm.But I would like to see the robot solve the way I solve :P
Anyway I will definitely consider your opinion.I am yet to start coding.So nothing is final as such.
 
I guess you could store all 8 depth cubes.
Then thing is, for a robot to be fast, it needs to be optimal.

We can do it faster than a robot because we can have 5 tps, a robot probably has 1, 0.5. So a 50 move solution for a human == 10s, for a robot =~ 50+.
 
Well I have a few updates on the cube robot I had planned.Well I started writing the codes before a few days after my exams.I have finally been able to make a cross using a very beginners method(Which I guess is the toughest part).I didnot use any brute force or databases.The program is self sufficient and runs without any delay.
I think I will be able to complete the full coding in the next few days.
The program will solve in a more human manner rather than in the fewest moves(Unlike most of the existing robots).
AvG will be happy I guess ;)
 
Status
Not open for further replies.

Similar threads

guelda
Robot solving the cube with two hands
Replies
5
Views
507
Caleb Valenzuela
Caleb Valenzuela
Puzzle Maniac
Zack D. Films - The Fastest Rubik's Cube Solve Ever
Replies
7
Views
1,418
Caleb Valenzuela
Caleb Valenzuela
D
[Unofficial] (ROBOT) Solving a Rubik's Cube in 0.103 Seconds
Replies
11
Views
1,367
Renslay
Renslay
V
Rubics cube solving robot with OLL and PLL Training feature
Replies
1
Views
1,394
freshcuber.de
freshcuber.de
Nyanyan
[Unofficial] Fastest 2x2x2 Cube Solving Robot
Replies
5
Views
1,689
abunickabhi
abunickabhi
Back
Top