I guess this is a question for me, what is the record for solving an unknown cube with no inspection time?Go with inspection and let both Faz and the robot start with the cube in "hand". Could be a close race.
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
I guess this is a question for me, what is the record for solving an unknown cube with no inspection time?Go with inspection and let both Faz and the robot start with the cube in "hand". Could be a close race.
Yeah it was our final year project at Swinburne University last year for our double degree in Mechatronics (Robotics) and computer science. It has been graded and we got High Distinctions (There was also a thesis, presentations and other course work involved).
Looks like (human or robot in this case) thislewait...? (Kociemba) the one where all pieces are oriented then solved with double moves only...
It's spelled "Thistlethwaite", it differs from Kociemba, and the latter is what they use:
http://www.theage.com.au/technology...t-that-solves-rubiks-cube-20110601-1fgbc.html
- Have you considered recording a few of shortest solutions found by the algorithm and using a simple metric (count up and weight the number of grips / turns to estimate actual solve time) to pick the best one?Not sure, but it takes about 60-80 ms per 90deg turn. The problem here is that depending on how the cube is held, it may take more or less robot moves to turn a face. I guess it is an average of 22 cube moves per solve in approximately 6 seconds of actual solving so 3.67 per second. Hopefully we will get this faster.
- If you want to do a little math (which should nevertheless be very fast for the computer), avoid scanning the sixth face if it is determined by the other 5.
cubies = {{"B", "D"}, {"B", "L"}, {"B", "R"}, {"B", "U"}, {"D", "F"}, {"D", "L"}, {"D", "R"}, {"F", "L"}, {"F", "R"}, {"F", "U"}, {"L", "U"}, {"R", "U"}};
OddPermutations[list_] := list[[#]] & /@ Select[Permutations[Range[Length[list]]], Signature[#] == -1 &];
EvenPermutations[list_] := list[[#]] & /@ Select[Permutations[Range[Length[list]]], Signature[#] == 1 &];
PartitionByVisibleStickers[l_] := Count[Length /@ (Flatten[Tuples /@ l, 1] // Gather), 1];
ProbabilityOfPredictability[l_] := (PartitionByVisibleStickers[OddPermutations[l]] + PartitionByVisibleStickers[EvenPermutations[l]])/(24*2^4);
ProbabilityOfPredictability /@ Subsets[cubies, {4}] // Mean
377/440
In the video, you turned the cube around, then turned it back to start the solve. That would have been some good fraction of a second saved using a relatively simple algorithm. (Assuming face detection is fast, which it seems to be.)
Yes, I understand that. What I'm saying is that in that solve, the last face you looked at required a certain move, and the first move of the solution happened to be exactly the inverse of that move. Therefore, if you could have predicted the last face, you could have saved both moves on that solve. In general, you can save at least one of those moves (most of the time).It must just look that way as it needs to pass over a few sides it has already seen while manipulating the cube to see every side. I can guarantee you it doesn't turn it back to the start to solve. The system currently keeps track of how the cube is held so you could start from any rotation.
Hi everyone,
This is then used to generate a solution of approximately 22 moves using the Kociemba algorithm.
And being able to scan fast too.
Most of these solvers are using either Kociemba or a varient.
- Have you considered recording a few of shortest solutions found by the algorithm and using a simple metric (count up and weight the number of grips / turns to estimate actual solve time) to pick the best one?
- You could also consider leaving the algorithm online and searching for shorter solutions from certain parts of the solve, allowing you to switch to one of them if you find it before your robot gets to executing that part of the solve. (e.g. find a solution with 22 moves, then start solving and try to compute a solution to what the cube state will be after, say, 4 moves. If you quickly find a solution for *that* which is under 18 moves (or faster to execute, if you use the robot metric), switch to it after the fourth move).
- If you want to do a little math (which should nevertheless be very fast for the computer), avoid scanning the sixth face if it is determined by the other 5.
- As far as I know, none of these three has been implemented in a robot before, but they seem like relatively easy ways to shave off some time.
I would love to be in contact to perhaps help with this; I think if you are using
22 move solutions it's quite likely there is a lot of speedup to be had in the
solving algorithm. Or perhaps you are using longer algorithms because the robot
can execute them faster?
In any case, my contact info is on http://cube20.org/ and I'd be absolutely
delighted to hear from you.
Most but not all! ;-)
When I saw you explain the method, I thought your technique was similar to Kociemba's algorithm?
No, I believe it is quite different. It is a two-phase, table driven algorithm that I developed before I knew any of the details of Kociemba's algorithm.
Yes, I know it was independently developed but I recall seeing similarities in the two systems. Kociemba is also a two-phase table driven algorithm.
If I recall correctly your first phase was sub-optimal with an optimal second phase (like Kociemba).
Have you studied the other algorithm enough to know the differences?
Is this enough to convince you that they are different? ;-)