# Skewb Solving Robot

#### NewCuber000

##### Member
Hello,

I am working on a Design project with 3 other 2nd year Engineering students from Canada, as well as a 2nd year Computer Science major. We are planning to build a robot that can take a scrambled Skewb puzzle and solve it. We've been working on this project for 3 or 4 months now, and are hoping to have a prototype completed by the end of March.

I made this forum post so that I could post some updates on our progress, ask peoples opinions, and form polls. Any discussion is welcome. When we were coming up with the idea, we couldn't find any similar projects that have been done before, besides robots that solve the traditional Rubik's cube, and a few robots that would solve higher ordered cubes like the 4x4x4 or 5x5x5. We've definitely come across some challenges while designing this, but I think we've come up with a reasonable solution. Yet again, there's no guarantee we will get a working prototype by March, since most of this project is being done completely from scratch (We're writing our own code, and 3-D printing a lot of our parts).

So far, all we have is a good idea of what our design will look like, some prototypes of claws that will grip the Skewb, a few circuit models using an arduino uno, and about 600 lines of C++ code (Almost solves the first layer of the cube). The solving method is going to be extremely inefficient, but the goal was to find a solution that works, not one that is quick. The solving time for the robot may actually be between 10 and 20 minutes, but that's just a rough estimate.

If anybody has any questions, ideas, or concerns, let us know! I'll probably post more soon.

EB

#### Mike Hughey

##### Super Moderator
Staff member
Just curious why you're going with a solver that is extremely inefficient? It's not too hard to make a pretty efficient skewb solver. The WCA TNoodle scrambler is capable of a really efficient solve without too terribly much computation time, and it's public domain software. And I would think an efficient solver would mean a lot less wear and tear on your custom parts since they would have a lot less work to do.

Does it have something to do with recognition? Is it difficult to recognize the entire state of the puzzle before beginning?

By the way, I think it's a great idea for a project!

#### NewCuber000

##### Member
It's not necessarily the code itself that's making it so inefficient, but the way that the robot solves it mechanically. We only actually have 2 claws that are twisting the cube, and those claws only have access to 4 of the corners. Therefore sometimes the puzzle has to do 5 turns where a human would use one . Part of it sort of has to do with cost, and not using more motors than we absolutely need to. It's also proven to be incredibly complicated to physically build something that can turn the Skewb to the point of being solved, especially with the materials we have access to... and also since we're only second year Engineers. Recognition will also take a while, but the solving time will take much longer I think.

I actually couldn't originally find a public domain Skewb solving software, although I admit I didn't really look much into it. We were somewhat set on trying to do the whole thing from scratch, as much as possible. However if we find the deadline is approaching and the program we wrote isn't quite doing it for us, I'll definitely look into that, thanks .

I'll probably post some sketches this weekend and maybe pictures of some of the mechanical parts that we've made so far this weekend or something. I'm also planning on posting a poll asking peoples opinions on here about the project (It's kind of a project requirement). anyway, thanks for the input!

#### xyzzy

##### Member
We only actually have 2 claws that are twisting the cube, and those claws only have access to 4 of the corners. Therefore sometimes the puzzle has to do 5 turns where a human would use one .
A skewb really only has four axes of rotations, so even having access to four corners might be enough depending on which four corners you can turn.

It's sort of like how a 2×2×2 can always be solved using only {U, R, F}, or {U, L, F}, or {D, R, B}, etc. Any time you want to do a move that's not one of the three allowed moves, just do a move on the opposite face (in the case of a skewb, on the opposite corner) and then transform all the subsequent moves by a rotation. In fact, I believe this is how TNoodle's skewb solver functions.

#### NewCuber000

##### Member
A skewb really only has four axes of rotations, so even having access to four corners might be enough depending on which four corners you can turn.

It's sort of like how a 2×2×2 can always be solved using only {U, R, F}, or {U, L, F}, or {D, R, B}, etc. Any time you want to do a move that's not one of the three allowed moves, just do a move on the opposite face (in the case of a skewb, on the opposite corner) and then transform all the subsequent moves by a rotation. In fact, I believe this is how TNoodle's skewb solver functions.
You're right. Our design is a little different than that though, because we technically can access any of the corners because our robot design is capable of rotating the cube (sort of). It's hard to explain without showing a picture. I'll upload one in a minute.

I'm going to think of using a readily available software such as TNoodle to program the Skewb. It's hard at this point since the computer programmer and I have already put a substantial amount of time into the code, but this would probably make the robot 3 times as efficient... plus there's still the Arduino program to write that will take plenty of time.

#### NewCuber000

##### Member

This is a drawing I made at one of our first meetings a few months ago. A lot of minor changes have been made and more detail has been put in since then, but this is somewhat the idea. The servo motors squeeze the arms of the claws together and the steppers rotate the claws. There are 3 claws in total - one holding the cube, and 2 which can rotate 4 of the corners (and technically all 8 if you make it rotate the cube a certain way). Obviously this is a bad drawing and we weren't sure of much at the time, but it's the best one we have so far until someone starts making sketches in AutoCAD.

#### NewCuber000

##### Member

This is a prototype of the claw that holds the cube from the bottom. We made a lot of changes to this for a number of reasons and the new claw parts are being printed. We're using the same design for all 3 claws, but the shape of the plates that grip the cube are different for the bottom claw and the side claws.

#### turtwig

##### Member
I'm not exactly sure what restrictions your robot has on turning, but you can solve a Skewb optimally with only access to 4 corners (R, L, U, F). Any state can be solved in 11 moves or less. I recently made a optimal Skewb solver for a school project that can generate a solution in around 10 seconds by just trying every possible solution. My project was only software, but if you can see the whole Skewb to determine the state and are able to do any move as you have said, you should be able to use the same method and, unless each move takes longer than 1 min, it should be faster.

#### Mike Hughey

##### Super Moderator
Staff member
Yes - the TNoodle solver does the same - it just tries every possible solution, and solves in 11 moves or less. So I think you'll find writing your own version of this is pretty straightforward - you can use the TNoodle code as an example. It's probably simpler than your own code - it's really very simple code!

#### NewCuber000

##### Member
I'm not exactly sure what restrictions your robot has on turning, but you can solve a Skewb optimally with only access to 4 corners (R, L, U, F). Any state can be solved in 11 moves or less. I recently made a optimal Skewb solver for a school project that can generate a solution in around 10 seconds by just trying every possible solution. My project was only software, but if you can see the whole Skewb to determine the state and are able to do any move as you have said, you should be able to use the same method and, unless each move takes longer than 1 min, it should be faster.
The robot can do any move on the cube, but certain moves can take up to 5 different robotic turns functions to do. So theoretically, if I use an optimal solver, an 11 move scramble could end up being 55 'moves'. 50% of moves only require 1 robotic turn, but 50% require 5 turns (if a corner isn't located on one of the 4 corners that may be turned directly). But that's still much better than originally, so thanks to all of you. Our self-written code is sort of terrible - it attempts to break down Sarah's cubing method into its components and solve it accordingly. That was the only way any of us knew how to do it.

EDIT: I'm pretty sure that a Skewb takes an average of about 8.4 moves to solve (Could be wrong), so using an optimal solver, if 50% of rotations take 1 twist and 50% of rotations take 5 twists, It would be an average of 3 twists, and the robot would take an average of ~25 twists to solve. That's not bad, although that's discluding the other mechanical moves that the robot will have to do like resets and such, and of course scanning the cube.

Last edited:

#### NewCuber000

##### Member
We're conducting a survey based on the prospects of this project and what you guys think so far based on the information that I've posted. I know there's not much to work with, but it would be helpful if at least 5-10 people made an attempt to participate. Post your responses below.

Questions:

1. Would you be interested in seeing a Skewb-Solving device on display at a WCA event? Yes or no.

2. What are the most important features that you think this robot should have (examples: speed, move-count, visual appeal, etc.)? Choose 3 if possible.

3. Do you think this project is feasible? If not, in what way?

4. Do you have any recommendations for improvements in what you've seen so far?

5. Have you seen any similar devices created in the past? What was the most similar one?

#### Mike Hughey

##### Super Moderator
Staff member
I think I don't quite understand which of the corners can be turned. The way I'm looking at it, if the bottom claw is just holding the cube and isn't supposed to move, I can only see that the top 2 corners could be turned? (the two opposite the bottom claw) The ones your drawing seems to show being turned would seem to be working against the bracket that's holding the bottom of the cube - am I misunderstanding the drawing?

I was wondering if it might be possible to optimize the solver to treat each turn the robot has to make as a move, so that you could optimize for your robot. But since I don't quite understand which corners can be turned, I don't know how much work that would be; if the number of moves required goes up much above 11, it would probably become too slow of an algorithm to simply use the brute force method of trying all possibilities.

#### NewCuber000

##### Member
I think I don't quite understand which of the corners can be turned. The way I'm looking at it, if the bottom claw is just holding the cube and isn't supposed to move, I can only see that the top 2 corners could be turned? (the two opposite the bottom claw) The ones your drawing seems to show being turned would seem to be working against the bracket that's holding the bottom of the cube - am I misunderstanding the drawing?

I was wondering if it might be possible to optimize the solver to treat each turn the robot has to make as a move, so that you could optimize for your robot. But since I don't quite understand which corners can be turned, I don't know how much work that would be; if the number of moves required goes up much above 11, it would probably become too slow of an algorithm to simply use the brute force method of trying all possibilities.
The bottom claw both rotates and opens and closes and so do the 2 claws on the sides. The Skewb is sitting on an angle on the bottom claw, and if you release the side claws and have the bottom rotate a certain amount, it can reach 2 other corners.

As for the program, we only need something that spits out some Skewb notation that solves the cube (for example, R L' B U L....), and the Arduino program will do the rest (finding and reading in the colours, executing the moves, etc). We will need to run 2 different codes.

#### NewCuber000

##### Member
We're conducting a survey based on the prospects of this project and what you guys think so far based on the information that I've posted. I know there's not much to work with, but it would be helpful if at least 5-10 people made an attempt to participate. Post your responses below.

Questions:

1. Would you be interested in seeing a Skewb-Solving device on display at a WCA event? Yes or no.

2. What are the most important features that you think this robot should have (examples: speed, move-count, visual appeal, etc.)? Choose 3 if possible.

3. Do you think this project is feasible? If not, in what way?

4. Do you have any recommendations for improvements in what you've seen so far?

5. Have you seen any similar devices created in the past? What was the most similar one?

If anyone wants to comment anything on this, please feel free, it would be a great help even if you feel you don't have 100% clarity on what we're trying to achieve. Just try to answer the questions from your perspective, whether you're just a cuber, a designer, a WCA delegate, you're knowledgable about robot design, or whatever else.

#### Mike Hughey

##### Super Moderator
Staff member
Still trying to understand how your robot ultimately solves it. I think I understand now how it does the 4 corners (to some degree, at least). So how do you solve it if you have a move to turn one of the other 4 corners? Is there a set of moves that accomplishes that using the 4 corners you can reach somehow, or do you somehow rotate the cube?

#### NewCuber000

##### Member
Still trying to understand how your robot ultimately solves it. I think I understand now how it does the 4 corners (to some degree, at least). So how do you solve it if you have a move to turn one of the other 4 corners? Is there a set of moves that accomplishes that using the 4 corners you can reach somehow, or do you somehow rotate the cube?
Yes, that was what I was talking about when I said that some rotations can take 5 moves. In order to reach those corners, the whole cube can be rotated by rotating both of the side claws at the same time.

#### Mike Hughey

##### Super Moderator
Staff member
Yes, that was what I was talking about when I said that some rotations can take 5 moves. In order to reach those corners, the whole cube can be rotated by rotating both of the side claws at the same time.
Ah, that makes sense - thank you. And an exchange like that (plus a move) takes 5 times as long as a move that it can reach?

I'm wondering how hard it would be to write code that would try to optimize for using as few of those moves as possible.

#### NewCuber000

##### Member
Ah, that makes sense - thank you. And an exchange like that (plus a move) takes 5 times as long as a move that it can reach?

I'm wondering how hard it would be to write code that would try to optimize for using a few of those moves as possible.
Yes, so it will consist of a cube rotation (which is just twisting both sides at the same time), then rotating the cube from the bottom claw, doing the move, and then doing the previous moves in reverse. So basically its using setup moves. I guess if you consider rotating the bottom claw a move, then it will be 7 moves. and that's not even including the gripping in and out movements that the claws need to make.

I think we're going to use an optimal Skewb solver (if we can find one, that is) that outputs some Skewb notation for solving the cube and use it in conjunction with an Arduino program, that will scan the cube, send that information to the Skewb solver, get the Skewb notation back for solving it, and then it will pretty much just be a series of if statements that will tell the motors how to turn to execute certain moves. I guess the easiest way would then be to reset after every move. but I guess I see where you're going with the optimization thing - maybe moves could be cancelled along the way.

I am by no means the programming expert on this project, though - Matt Piere is our programmer and he understands this better than I do. I have little concept of how he plans on connecting the programs together so that we can have communication between them - I think he mentioned text files. But I trust him and it seems possible

#### abunickabhi

##### Member
We're conducting a survey based on the prospects of this project and what you guys think so far based on the information that I've posted. I know there's not much to work with, but it would be helpful if at least 5-10 people made an attempt to participate. Post your responses below.

Questions:

1. Would you be interested in seeing a Skewb-Solving device on display at a WCA event? Yes or no.

2. What are the most important features that you think this robot should have (examples: speed, move-count, visual appeal, etc.)? Choose 3 if possible.

3. Do you think this project is feasible? If not, in what way?

4. Do you have any recommendations for improvements in what you've seen so far?

5. Have you seen any similar devices created in the past? What was the most similar one?

1. Sure, infact I am working on a non-cubic puzzle scrambling bot myself (https://github.com/abunickabhi/WCA_allpuzzle_scrambler) Although I have not found to time and money to get started on it. Also, I am learning robotics for past semester, and will do it after the semester ends. Skewb solving bot sounds dope.

2. Speed is obviously the main thing that comes to my mind if this bot is ever to be used in an official WCA comp.
Move count is another aspect and the way the Tnoodle software takes care of this issue, should be noted by you.

3. I think this project is feasible. (although not on the first attempt, maybe the 10th attempt or so)