# Can kociemba or other method solve the Rubik in 5 faces turn only?



## Pohk (Oct 29, 2018)

Hi,
I am ask for help.
I am a beginner of Rubik, I hope to write a python program for the following robot.




I try to use kociemba method directly, but the machine can only turn 5 faces, it can not turn upper face(U U' U2). Is it possible to modify the kociemba method or possible to replace each of the U moves with an equivalent sequence?


I use the ptyhon package from here:
https://github.com/muodov/kociemba

example:
kociemba.solve('DRLUUBFBRBLURRLRUBLRDDFDLFUFUFFDBRDUBRUFLLFDDBFLUBLRBD')
return: D2 R' D' F2 B D R2 D2 R' F2 D' F2 U' B2 L2 U2 D R2 U

Thanks


----------



## Ranzha (Oct 29, 2018)

The good news is that U = R L F2 B2 R' L' D R L F2 B2 R' L'.
The bad news is that you'll probably have to rewrite the solution algorithm yourself, without definition of U/U2/U'.


----------



## Pohk (Oct 29, 2018)

Thanks Ranzha.

U = R L F2 B2 R' L' D R L F2 B2 R' L'
U' =R L F2 B2 R' L' D' R L F2 B2 R' L' 
U2 = R L F2 B2 R' L' D2 R L F2 B2 R' L'

Is it correct?


----------



## DGCubes (Oct 29, 2018)

Pohk said:


> Thanks Ranzha.
> 
> U = R L F2 B2 R' L' D R L F2 B2 R' L'
> U' =R L F2 B2 R' L' D' R L F2 B2 R' L'
> ...



Yes.


----------



## Herbert Kociemba (Oct 30, 2018)

Another question is how this relates to the two phase algorithm. If we define as usual the phase 2 as the states which are generated by
<U, D, R2, F2, L2, B2> it is more natural to ignore for example the B2 move. We have
B2 = U D L2 R2 U' D' F2 U D L2 R2 U' D' with all moves valid in phase 2 on the right hand side. So in phase 1 we can use <U, R, D, F, L> to put the cube into a phase 2 state and then use <U, D, R2, F2, L2> to solve the cube. 
The pruning tables will get larger though because we loose the 16-fold symmetry and only have a 4-fold symmetry left

Of course it is just a rotation of the whole cube if you want to omit a different face.


----------



## SenorJuan (Oct 30, 2018)

There are other equivalents to U, including:
U = L R' F2 B2 L R' D R L' B2 F2 R L'
As your robot can presumably solve L and R simultaneously ( and F & B ), then this sequence is effectively only 7 moves long, as are the previously mentioned algs. So not quite as cumbersome as it first appears.


----------



## Herbert Kociemba (Nov 1, 2018)

I worked the approach I described above out and the modified two phase algorithm gives solutions with an average of less than 22 moves. Here is for example the cube in the cube pattern without using B moves: R2 F2 U R U2 L F2 R' L2 U2 L F U F2 U2 R2 U' (17f)

The hardest postion from the cube20.org page is also more difficult for the modified solver, here is a 24 move solution without B-turns
R F' D' R' L2 D' R2 U R' D' F U R D2 L' F' U2 D' F2 R2 D F2 L2 U'


----------



## Pohk (Nov 1, 2018)

Herbert Kociemba said:


> I worked the approach I described above out and the modified two phase algorithm gives solutions with an average of less than 22 moves. Here is for example the cube in the cube pattern without using B moves: R2 F2 U R U2 L F2 R' L2 U2 L F U F2 U2 R2 U' (17f)
> 
> The hardest postion from the cube20.org page is also more difficult for the modified solver, here is a 24 move solution without B-turns
> R F' D' R' L2 D' R2 U R' D' F U R D2 L' F' U2 D' F2 R2 D F2 L2 U'



I am very honored to receive your reply. I can understand to make a rotation to ignore B2 move.
But I am trying to understand the 2 phase method you are using, but it does take a little longer for me. 
And I can't loading the kociemba.org, instead I visit it from https://web.archive.org/web/*/kociemba.org.
Could you please share the modified code for my further study?


----------



## Herbert Kociemba (Nov 1, 2018)

Pohk said:


> And I can't loading the kociemba.org, instead I visit it from https://web.archive.org/web/*/kociemba.org.
> Could you please share the modified code for my further study?



I have no idea why kociemba.org should not work. But nevertheless I put the Python project to Github. The memory requirements are relatively large (250 MB). What is quite interesting that it takes only about 2 moves more on average when fixing a face. Spending 2 s for each computation, for 50 random cubes I got on my PC



18​
19​
20​
21​
22​
23​
1​
2​
9​
14​
21​
3​


----------



## xyzzy (Nov 1, 2018)

Herbert Kociemba said:


> The pruning tables will get larger though because we loose the 16-fold symmetry and only have a 4-fold symmetry left


If you fix the B face, you're left with only 4-fold symmetry, but if you fix the D face, you still have 8-fold symmetry. I'm not sure I see the reasoning behind why fixing B instead of fixing D should be more natural.


----------



## Herbert Kociemba (Nov 1, 2018)

xyzzy said:


> If you fix the B face, you're left with only 4-fold symmetry, but if you fix the D face, you still have 8-fold symmetry.


Because if I fix the D face then in phase 2 I only can generate <U, R2,F2,L2,B2> and I do not believe that it generates all phase 2 states. Or can you give for example a generator for D in <U, R2,F2,L2,B2> ?


----------



## xyzzy (Nov 1, 2018)

Herbert Kociemba said:


> Because if I fix the D face then in phase 2 I only can generate <U, R2,F2,L2,B2> and I do not believe that it generates all phase 2 states. Or can you give for example a generator for D in <U, R2,F2,L2,B2> ?


D = (R2 B2 L2 U B2 R2 F2 Dw)3 Dw = R2 B2 L2 U B2 R2 F2 U F2 R2 B2 U R2 F2 L2 U L2 F2 R2 U F2 L2 B2 U2

A bit long, but I found it by hand lol.


----------



## Herbert Kociemba (Nov 1, 2018)

xyzzy said:


> D = (R2 B2 L2 U B2 R2 F2 Dw)3 Dw = R2 B2 L2 U B2 R2 F2 U F2 R2 B2 U R2 F2 L2 U L2 F2 R2 U F2 L2 B2 U2


Great, so indeed your proposition is possible too because <U, R2,F2,L2,B2> generates all phase 2 states. But I suspect that the average maneuver length will be higher because the branching factor is lower than with <U,D, R2,F2,L2>. It really took me some effort to get my version work (hopefully) correctly and I will not invest more time in this subject in the moment.


----------



## Pohk (Nov 15, 2018)

thanks all.
I just make it work. 
it take just 1s for each computation but it take over 20s for the color resolver. 
https://github.com/dwalton76/rubiks-color-resolver


----------



## Voltara (Nov 15, 2018)

Great work. It's nice to see a fresh Mindstorms solver design.

I played around with David Gilday's MindCub3r a while back, and replaced the solver with my own. (There is a video here.) My strategy for resolving colors was to minimize the sum of variances of each color component (R, G, B) within each group of 9 stickers. I implemented it using a branch-and-bound depth first search to find the optimal grouping.

The key optimization that made such a search feasible was to consider only those groupings of colors which are physically realizable on the cube. Instead of assigning 1 sticker at a time in my search, it would assign all 3 stickers of a corner, or all 2 stickers of an edge. To further limit the complexity of the search, it first looked for the optimal corner assignment (corners are more tightly constrained than edges), and then looked for the best edge assignment to fit the corners. In other words, it did not backtrack to consider suboptimal corner assignments.

Perhaps you could try something similar to cut down on the 20+ second color resolution times.


----------



## Nosae Semaj (May 2, 2019)

Just use ZZ and do EO with F turns


----------

