13 April

Team:

This week, we wired the six driver-motor setups in parallel and got all of the motors to rotate accordingly. We encountered an issue with reading a solution string, but managed to get the motors turning with respect to one-character commands (i.e. instead of F1, we have F working). We noticed that the motors get uncomfortably warm when idling, and discussed this with our professor. After some research, we determined this to be normal and found that the motor would sooner skip steps than completely fail from overheating. However, this upcoming week, we will be taking careful measurements to ensure the current through each motor does not exceed their current ratings.

We gained clarification for the remaining semester schedule and determined that our progress is mostly on time. Luckily, we allocated the rest of the schedule to be slack time, so we have some leeway for finishing our respective modules and for making minor alterations/additions before demo day next month.

JT:

This week, I completed another major milestone for my section of the project. In previous weeks, I’ve only ever tested Cubr with two motors. At the end of this week I had all six motors plugged in and turning sequentially. The project can successfully take any input string from its serial monitor, and turn the respective cube faces properly. Working with Sam, it can also receive a string from a python program through a third party module. With these steps completed, Sam can scan the cube and pip his cube state in Kociemba’s TwoPhase solver or Lily’s Beginner’s Method solver. From here we’re able to successfully send the string to the controller and turn the motors from there.

With these major accomplishments under our belt, we’re poised to finish strong with plenty of slack time. The last major milestone we’re all going to be working on is the housing. I talked to Professor Sullivan and we’d like to try and enclose the solver in a clear acrylic. The only concern right now is how hot the motors get when plugged in. After some research, it appears normal for the motors to run very hot to the touch, but the motors are rated for up to 80 degrees Celsius. I’m going to run one of our extra motors for an extended amount of time to test the durability. Nonetheless, we only plan to have the robot plugged in when it’s ready to solve. Next week I’ll spend most of my time planning how we’re going to house the robot. I’ll contact some Mechanical Engineering friends in order to learn how to design and lasercut a basic housing arrangement.

Lily:

This week, I assisted JT with wiring the six driver-motor setups. In addition, I discussed the housing design with JT and discussed the structure and refactoring of code for the overall main function with Sam. The plan is as follows: the overall main function will call the cube state detection module and receive the cube state string, which will be passed into either the Beginner’s Method or Two-Phase algorithms. After the solving algorithms return a solution, this solution string will be piped to the Arduino within opening and closing delimiters, < and >.

For the housing design, JT and I decided to make the housing out of acrylic so that we can actually mount the motors and use the laser cutter in the Makerspace (for which I have the appropriate training).

I’ve finished the second layer algorithms and reached the desired cube state for the first two layers with a few tests. Because I’ve come across some bugs, I’ve assigned an issue to Sam to help me to verify and debug my sublayer algorithms (for white cross, white corners, and the 2nd layer). In the meantime, I am working on finishing up the third layer algorithms: OLL (orient last layer) and PLL (permute last layer). Since this part is the most unfamiliar to me in terms of cubing, I have been taking extra care in mapping the moves between/through orientations. As a refresher: OLL has 57 different orientation cases to orient both the edges and the corners of the top layer at the same time; the last step, PLL, has 21 cases.

I am still trying to put in 3D print orders for our coupling arms, since half of ours (from a prior print job, last week and earlier this week) printed wrong for some reason, but I am confident that we’ll get the arms printed and painted such that they’ll correspond to each of the cube faces.

Sam:

This past week, Lily gave me an extremely in depth description of her code so that I can debug and verify her code for the white cross and white corner functions of the beginners method. In the beginners method, the way to solve the cube is by first solving the white cross, the white corners, then layer by layer until the cube is solved. This is obviously an oversimplification but I am tasked with debugging and verification to make sure the code is 100% correct.

I continued work with pyserial and verified with the motors that it worked correctly when I sent the correct string from a python interpreter. I will continue work on this to integrate this into a python script. We also have more work to do with housing in which we are going to use acrylic.

We are on track and made good progress in this short week due to carnival. Next week I will finalize the script and will make a new interface between my python script and the Arduino code so that only a single character maps to a given movement of a cube face instead of 2 characters, which is implemented currently. This simplifies the Arduino code and makes the code more readable. Go Cubr.