# Skewb Solving Robot



## NewCuber000 (Jan 17, 2019)

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 (Jan 17, 2019)

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 (Jan 18, 2019)

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 (Jan 19, 2019)

NewCuber000 said:


> 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 (Jan 20, 2019)

xyzzy said:


> 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 (Jan 20, 2019)

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 (Jan 20, 2019)

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 (Jan 20, 2019)

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 (Jan 20, 2019)

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 (Jan 20, 2019)

turtwig said:


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


----------



## NewCuber000 (Jan 20, 2019)

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?

6. Any other comments?


----------



## Mike Hughey (Jan 20, 2019)

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 (Jan 21, 2019)

Mike Hughey said:


> 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 (Jan 22, 2019)

NewCuber000 said:


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



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 (Jan 22, 2019)

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 (Jan 22, 2019)

Mike Hughey said:


> 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 (Jan 22, 2019)

NewCuber000 said:


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


----------



## cubezrawesome (Jan 22, 2019)

that looks cool!!


----------



## NewCuber000 (Jan 22, 2019)

Mike Hughey said:


> 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 (Jan 27, 2019)

NewCuber000 said:


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

4. xyzzy and Mike Hughey have important suggestions, please follow them.

5. I have seen big cube solving bots, and 3x3 solving bots in the past (Mostly on this forum: http://cubesolvingprograms.freeforums.net/)

6. Yo! (If you have any further doubts or need help, drop a mail to [email protected])


----------



## NewCuber000 (Jan 28, 2019)

abunickabhi said:


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



Thanks for the advice, I'll definitely make sure I consider all of everyone's suggestions! and good luck with your project as well, it sounds really interesting!

Also, I've been emailing with turtwig and we've been trying to incorporate his Skewb solver into our project. It should be doable with the right modifications, it's just a matter of getting it to work, and getting his Java code and our Arduino code to collaborate with each other.


----------



## Filipe Teixeira (Feb 19, 2019)

NewCuber00 said:


>


this is beautiful


----------



## NewCuber000 (Feb 26, 2019)

Filipe Teixeira said:


> this is beautiful



Yeah, it turned out pretty nice, although we made 2 adjustments to the model and it's actually a bit smaller and more compact now. I didn't have a huge part in designing the claws, though, that was mostly my other teammates, Matthew Hill and Matthew Kneed-Teed. 

We've made a lot of progress since the last time I updated. We're probably over half-way done the supplementary code that will be used with Turtwigs skewb-solving code, and we're going to start building our first prototype this week! I'll start putting out some more pictures this week.


----------



## NewCuber000 (Mar 12, 2019)

Here is a picture of us beginning to build the initial prototype. At least now you can all get a better idea of what's going on. There are 3 servo motors to grip the cube and 3 stepper motors to turn it. It's not perfect, but it should serve it's intended purpose once we work out a few kinks.

I've written the Arduino code that turns the motors based on a given solving algorithm. If anyone's interested I might link the code here sometime. It's pretty basic, it's just a bunch of if statements that if it's given, for example, b, it will execute a series of motor twists that will do some set up moves, turn b, and undo the setup moves. some rotations will require much longer set up moves than others. Then, it just goes through every letter in the solving algorithm.

Unfortunately, I'm having trouble connecting my Arduino program with our colour-reading Python program as well as Turtwig's Javascript Skewb-solving software.  It's definitely quite a task. Arduino doesn't make it easy to read in data into the program from your PC. I may have figured out a way to do it though, so we'll see. Of course, I could always input the colours manually, but that's not as fun.

I'm expecting to have SOMETHING that works within the next two weeks, although it will probably still require some user input.


----------



## Hazel (Mar 12, 2019)

NewCuber000 said:


> Here is a picture of us beginning to build the initial prototype. At least now you can all get a better idea of what's going on. There are 3 servo motors to grip the cube and 3 stepper motors to turn it. It's not perfect, but it should serve it's intended purpose once we work out a few kinks.
> 
> I've written the Arduino code that turns the motors based on a given solving algorithm. If anyone's interested I might link the code here sometime. It's pretty basic, it's just a bunch of if statements that if it's given, for example, b, it will execute a series of motor twists that will do some set up moves, turn b, and undo the setup moves. some rotations will require much longer set up moves than others. Then, it just goes through every letter in the solving algorithm.
> 
> ...


That's really cool, good job! I'd love to see the code.


----------



## NewCuber000 (Mar 12, 2019)

Aerma said:


> That's really cool, good job! I'd love to see the code.



Cool, view the spoiler at your own risk, it's over 400 lines 

So the code is kind of unfinished and is extremely inefficient right now. I have 12 different sub-functions being called into my main function, 'setup()', that all correspond to a different set of motor rotations, and I used them as sort of building blocks in my code. I could probably reduce it to about 5 functions if I was smarter about it. I might change it sometime. 

The 'Reading in the string' section is unfinished and I just put in something for now that allows me to test the code. 



Spoiler: Arduino Code





```
// Skewb-bot Motor Controlling Program
// Eric Boudreau
// This program will take in a string of Skewb notation from a Python program, and will turn all of the motors of the Skewb-bot according to the inputted Skewb notation.


// include the Servo library
#include <Servo.h>


// define pin numbers for Stepper motors
const int dirPin1 = 0;
const int stepPin1 = 1; // stepper 1 for the bottom claw
const int dirPin2 = 2;
const int stepPin2 = 3; // stepper 2 for the left claw (Camera-facing)
const int dirPin3 = 4;
const int stepPin3 = 5; // stepper 3 for the right claw (Camera-facing)

// define constants
int N = 11; // max amount of twists to solve a skewb in given Javascript notation
int x; // Used as a counting variable in for loops.
char incomingString;

// Define servos
Servo servo1; // servo 1 for the bottom claw
Servo servo2; // servo 2 for the left claw
Servo servo3; // servo 3 for the right claw


//******************************************************************************************** Setting Up  ****************************************************************************************************//


// main function, runs once
void setup() {

  Serial.begin(9600);
 
  // set all pins as outputs
  pinMode(dirPin1 ,OUTPUT);
  pinMode(stepPin1 ,OUTPUT);
  pinMode(dirPin2 ,OUTPUT);
  pinMode(stepPin2 ,OUTPUT);
  pinMode(dirPin3 ,OUTPUT);
  pinMode(stepPin3 ,OUTPUT);

  //Define pins for servos and min and max pulse widths based on servo specifications
  servo1.attach(6, 771, 2740);
  servo2.attach(7, 771, 2740);
  servo3.attach(8, 771, 2740);

  //define variables.
  char notation[N], front[5], back[5], top[5], left[5], right[5], bottom[5], letter;
  int k=0;
 

//************************************************************************************** Reading in the Colors ************************************************************************************************//


  // Turn the cube such that the camera can take a picture of each side of the cube. Print a statement to the serial monitor for every image taken.

  rotateBottomCounterclockwise(45);
  Serial.print("Take Picture of front side\n");
  delay(1000);
 
  rotateBottomClockwise(180);
  Serial.print("Take Picture of back side\n");
  delay(1000);

  rotateBottomClockwise(45);
  gripAndRelease();
  flipCubeBackward();
  ungripAndHold();
  flipCubeForward(); //RESET
  rotateBottomCounterclockwise(45);
  Serial.print("Take Picture of bottom side\n");
  delay(1000);
 
  rotateBottomCounterclockwise(180);
  Serial.print("Take Picture of top side\n");
  delay(1000);
 
  rotateBottomClockwise(45);
  gripAndRelease();
  flipCubeForward();
  ungripAndHold();
  flipCubeBackward(); //RESET
  rotateBottomCounterclockwise(45);
  Serial.print("Take Picture of left side\n");
  delay(1000);
 
  rotateBottomClockwise(180);
  Serial.print("Take Picture of right side\n");
  delay(1000);
 
  // reset cube to initial position
  rotateBottomCounterclockwise(135);
  gripAndRelease();
  flipCubeForward();
  ungripAndHold();
  flipCubeBackward(); //RESET

//*******************************************************************************************Reading in the String*********************************************************************************************//


  notation[0] = 'B';
  notation[1] = 'b';
  notation[2] = 'U';
  notation[3] = 'u';
  notation[4] = 'L';
  notation[5] = 'l';
  notation[6] = 'R';
  notation[7] = 'r';
 

  /* Read into Arrays
     Send arrays to File
     Read File name */
 
 
//*********************************************************************************************Solving the Cube************************************************************************************************//


  //Run the while loop until the end of the string is reached. Cube will go from unscrambled to solved.
  while(k<N)
  {
    letter = notation[k];

    if(letter == 'B'){
      Serial.print("Turn back clockwise\n");
      gripAndRelease();
      flipCubeBackward();
      ungripAndHold();
      flipCubeForward(); // RESET
      rotateBottomCounterclockwise(90);
      reset180Forward(); // RESET
      gripAndRelease();
      turnRightClockwise();
      ungripAndHold();
      turnRightCounterclockwise();
      rotateBottomClockwise(90);
      reset180Backward(); // RESET
      gripAndRelease();
      flipCubeBackward();
      ungripAndHold();
      flipCubeForward(); // RESET
    }
    
    if(letter == 'b'){
      Serial.print("Turn back counterclockwise\n");
      gripAndRelease();
      flipCubeBackward();
      ungripAndHold();
      flipCubeForward(); // RESET
      rotateBottomCounterclockwise(90);
      reset180Forward(); // RESET
      gripAndRelease();
      turnRightCounterclockwise();
      ungripAndHold();
      turnRightClockwise();
      rotateBottomClockwise(90);
      reset180Backward(); // RESET
      gripAndRelease();
      flipCubeBackward();
      ungripAndHold();
      flipCubeForward(); //RESET
      
    }
    
    if(letter == 'U'){
      Serial.print("Turn top clockwise\n");
      rotateBottomCounterclockwise(90);
      reset180Forward(); // RESET
      gripAndRelease();
      turnLeftClockwise();
      ungripAndHold();
      turnLeftCounterclockwise(); // RESET
      rotateBottomClockwise(90);
    }
    
    if(letter == 'u'){
      Serial.print("Turn top counterclockwise\n");
      rotateBottomCounterclockwise(90);
      reset180Forward(); // RESET
      gripAndRelease();
      turnLeftCounterclockwise();
      ungripAndHold();
      turnLeftClockwise(); // RESET
      rotateBottomClockwise(90);
      
    }
    
    if(letter == 'L'){
       Serial.print("Turn left clockwise\n");
       gripAndRelease();
       flipCubeForward();
       ungripAndHold();
       flipCubeBackward(); // RESET
       rotateBottomCounterclockwise(90);
       reset180Forward(); // RESET
       gripAndRelease();
       turnLeftClockwise();
       ungripAndHold();
       turnLeftCounterclockwise(); // RESET
       rotateBottomClockwise(90);
       reset180Backward(); // RESET
       gripAndRelease();
       flipCubeBackward();
       ungripAndHold();
       flipCubeForward(); // RESET
    }
    
    if(letter == 'l'){
       Serial.print("Turn left counterclockwise\n");
       gripAndRelease();
       flipCubeForward();
       ungripAndHold();
       flipCubeBackward(); // RESET
       rotateBottomCounterclockwise(90);
       reset180Forward(); // RESET
       gripAndRelease();
       turnLeftCounterclockwise();
       ungripAndHold();
       turnLeftClockwise(); // RESET
       rotateBottomClockwise(90);
       reset180Backward(); // RESET
       gripAndRelease();
       flipCubeBackward();
       ungripAndHold();
       flipCubeForward(); // RESET
    }
    
    if(letter == 'R'){
      Serial.print("Turn right clockwise\n");
      gripAndRelease();
      turnRightClockwise();
      ungripAndHold();
      turnRightCounterclockwise();
    }
    
    if(letter == 'r'){
      Serial.print("Turn right counterclockwise\n");
      gripAndRelease();
      turnRightCounterclockwise();
      ungripAndHold();
      turnRightClockwise();
    }
    
    k++;
  }

  Serial.print("The Skewb is Solved!\n");
  return;

}

void loop(){
  return;
}

//************************************************************************************Functions used within the main Program***********************************************************************************//
// rotates cube 90 degrees with bottom plate
void rotateBottomClockwise(int angle){
  float fraction;
  int steps;
  digitalWrite(dirPin1, HIGH);

  fraction = angle/360;
  steps = fraction*200;
 
  for(x=0; x<steps; x++){
    digitalWrite(stepPin1, HIGH);
    delay(2);
    digitalWrite(stepPin1, LOW);
    delay(2);
  }
  delay(500);
}

void rotateBottomCounterclockwise(int angle){
  float fraction;
  int steps;
  digitalWrite(dirPin1, LOW);

  fraction = angle/360;
  steps = fraction*200;
    
  for(x=0; x<steps; x++){
    digitalWrite(stepPin1, HIGH);
    delay(2);
    digitalWrite(stepPin1, LOW);
    delay(2);
  }
  delay(500);
}

// side arms grip, and bottom arm releases cube.
void gripAndRelease(){
  servo2.write(30);
  servo3.write(30);
  delay(500);
  servo2.write(80);
  servo3.write(80);
  delay(500); 

  servo1.write(30);
  delay(500);
}

// side arms release, and bottom arm grips cube.
void ungripAndHold(){
  servo2.write(80);
  servo3.write(80);
  delay(500);
  servo2.write(30);
  servo3.write(30);
  delay(500); 

  servo1.write(80);
}

//does a cube 'flip' backward.
void flipCubeBackward(){
  digitalWrite(dirPin2, HIGH);
  digitalWrite(dirPin3, LOW);
 
  for(x=0; x<67; x++){
    digitalWrite(stepPin2, HIGH);
    digitalWrite(stepPin3, HIGH);
    delay(2);
    digitalWrite(stepPin2, LOW);
    digitalWrite(stepPin3, LOW);
    delay(2);
  }
}

//does a cube 'flip' forward.
void flipCubeForward(){
  digitalWrite(dirPin2, LOW);
  digitalWrite(stepPin3, HIGH);
 
  for(x=0; x<67; x++){
    digitalWrite(stepPin2, HIGH);
    digitalWrite(stepPin3, HIGH);
    delay(2);
    digitalWrite(stepPin2, LOW);
    digitalWrite(stepPin3, LOW);
    delay(2);
  }
}

void reset180Backward(){
  digitalWrite(dirPin2, HIGH);
  digitalWrite(dirPin3, LOW);
 
  for(x=0; x<180; x++){
    digitalWrite(stepPin2, HIGH);
    digitalWrite(stepPin3, HIGH);
    delay(2);
    digitalWrite(stepPin2, LOW);
    digitalWrite(stepPin3, LOW);
    delay(2);
  }
}

void reset180Forward(){
  digitalWrite(dirPin2, LOW);
  digitalWrite(stepPin3, HIGH);

  for(x=0; x<180; x++){
    digitalWrite(stepPin2, HIGH);
    digitalWrite(stepPin3, HIGH);
    delay(2);
    digitalWrite(stepPin2, LOW);
    digitalWrite(stepPin3, LOW);
    delay(2);     
   }
}

// turns the left corner clockwise.
void turnLeftClockwise(){
  digitalWrite(dirPin2, LOW);
 
  for(x=0; x<67; x++){
    digitalWrite(stepPin2, HIGH);
    delay(2);
    digitalWrite(stepPin2, LOW);
    delay(2);
  }
}

// turns the left corner counterclockwise.
void turnLeftCounterclockwise(){
  digitalWrite(dirPin2, HIGH);
 
  for(x=0; x<67; x++){
    digitalWrite(stepPin2, HIGH);
    delay(2);
    digitalWrite(stepPin2, LOW);
    delay(2);
  }
}

// turns the right corner clockwise.
void turnRightClockwise(){
  digitalWrite(dirPin3, LOW);
 
  for(x=0; x<67; x++){
    digitalWrite(stepPin3, HIGH);
    delay(2);
    digitalWrite(stepPin3, LOW);
    delay(2);
  }
}

// turns the right corner counterclockwise.
void turnRightCounterclockwise(){
  digitalWrite(dirPin3, HIGH);
 
  for(x=0; x<67; x++){
    digitalWrite(stepPin3, HIGH);
    delay(2);
    digitalWrite(stepPin3, LOW);
    delay(2);
  }
}
[/SPOILER]

// NOTES:
// The code assumes that the cube is in the correct position initially.
```


----------



## Hazel (Mar 12, 2019)

NewCuber000 said:


> Cool, view the spoiler at your own risk, it's over 400 lines
> 
> So the code is kind of unfinished and is extremely inefficient right now. I have 12 different sub-functions being called into my main function, 'setup()', that all correspond to a different set of motor rotations, and I used them as sort of building blocks in my code. I could probably reduce it to about 5 functions if I was smarter about it. I might change it sometime.
> 
> ...


This is super cool! How are you planning on going about the solution-finding process?


----------



## NewCuber000 (Mar 13, 2019)

Aerma said:


> This is super cool! How are you planning on going about the solution-finding process?



We're actually using a Javascript solving program and HTML file given by another user on this site, Turtwig. For now, we can input the colors into his website and get a solving algorithm that we can manually input into the Arduino program. Eventually, though, we would like to use a Python program and a camera to read in the colours by analyzing pixel values in pictures, and use it to connect the Arduino and Javascript programs in a way that all of the programs communicate with each other. Not an easy task, which is why we're taking the slightly easier route first 

Also there was quite a few bugs in my Arduino code when I tested it, but we're working on fixing them.


----------



## NewCuber000 (Mar 18, 2019)

So the Arduino code is like 95% functional now (besides a few angles that may have to be adjusted a bit), our only problem is that when we started soldering wires together and used the PCB we made, only half of the motors worked.  maybe we just did a poor soldering job, or there are some loose connections, we are newbies after all. Hopefully, we will get it working within the next 2 weeks, and if we do, I'll post a video here.


----------



## NewCuber000 (Mar 19, 2019)

ANOTHER UPDATE: It works... we fixed a couple of soldering connections on the PCB, and now it works great (with a few slight misalignments here in there). We still can't quite get the camera to read in the colours of the cube yet, so for now, I'm doing it manually. But we tried a couple of test scrambles, and it is capable of solving the puzzle.

IT WORKS

I'll post a video in a week or two once it's fully put together and assembled.


----------

