Welcome to the Speedsolving.com, home of the web's largest puzzle community! You are currently viewing our forum as a guest which gives you limited access to join discussions and access our other features.

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?

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'.

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.

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.

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 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?

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

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.

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> ?

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> ?

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.

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.