30 March

Team:

The team has made a lot of progress since we first started. Since we are pretty confident in our ability to make one motor arm work, we’re positive we can duplicate the system for all six faces of the cube. Our biggest hurdle as a team, is ensuring we stay on schedule to create the proper “misc” pieces. This means taking the time to properly 3D print the right coupling arms for Cubr and also figuring out how to house each of the motors and the cube itself. We originally wanted to print the entire housing, but we might switch over to laser cutting some basic side pieces to hold the robot together. We think this is easier and less time consuming in case we make mistakes with our prints.

We are right on time to perform for next week’s demonstration. There is still a minor setback from when Lily’s computer crashed, but we should be able to stabilize. For the demo, Sam’s cube state detection properly pipes into Kociemba’s TwoPhase Solver, which produces a valid input. From here, I can manually input a string into the arduino, and a single face will turn respectively. After demonstration, we’ll start to transition into the home stretch by duplicating the arm systems and ensuring all the individual modules are properly integrated.

JT:

This week was a bit of an easier week for my part of the project. With the midpoint demo next week, I only had to focus on making one motor work up to specification instead on working on multiple motors. Since one motor is the major subsystem of the entire project, it only makes sense to make sure it’s working correctly and completely so it is easier to duplicate when we create the full solving robot.

As for serial input to the motors, I’ve adjusted the current code to read inputs from the serial monitor only enclosed in <>. This ensure that the robot only reads string that we specify. Previously, I was simply using the newline character, which worked but was not exactly the tightest to ensure proper inputs.

Lastly, Lily and I began looking into coupling arms for the robot. In the makerspace, I learned how to use the 3D printers and some basics of the software required. I am not familiar with 3D designing and printing, so to start Lily and I found a template for a similar cube coupling arm. For the demo, we plan to use this just to see if our major subsystem is working as desired. However, I do plan on eventually learning to create our own coupling arm entirely to fit our cube perfectly.

Next week I simply want to completely wrap up the code for reading an input string. I should be on track to do this while ensuring we have a good deliverable for our midpoint demo on Wednesday.

Sam:

This past week I made progress with integrating the solver software module with the hardware component. In our project, we need to communicate the solution string from the solver to the Arduino so that the Arduino can control which faces the motor should turn. The way in which I initially researched how to communicate from the Mac to the Arduino was using the serial monitor. Serial communication is the method in which we will communicate from the Mac to the Arduino, and using the serial monitor is the easiest way to do this, however, it is not seamless. For example, if we use the serial monitor, we cannot use a streamline process and integrate our software module with the robot part of our project without manually inputting the solution string into the serial monitor.

After researching different modules, I decided to use PySerial, a module that encapsulates the access for the serial port. This allows us to not manually input the solution string and write a python script that sends the solution string to the Arduino. I made good progress this week, and hope to finalize the code for this next week. I am working closely now with JT to integrate his Arduino code to control the motors. I am also working with Lily to ensure our different software modules follow the interface for integration.

Our team is making good progress and for the demo this week we hope to get a face of the cube to turn. Lily and JT have made good progress on the coupling arms. As of right now, we are on track. Go Cubr.

Lily:

This week, I quickly caught up to the code that I lost last week for the solver module. The move definitions are complete and debugged. Last week, we attempted to handsolve a give cube configuration with the solution that the Two-Phase algorithm; this week, I realized that our understanding of the move definitions switched the 90-degree counterclockwise turns with the 180-degree turns. With this in mind, I had to switch my respective definitions, which are now able to reach a fully solved state for a given cube state configuration and a solution string outputted from the Two-Phase algorithm.

JT and I worked on the coupling arms for the robot module. We found a template so that we could integrate and test the firmware. We decided to print the part at the Tech Spark makerspace FabLab (since I have completed the required official Fire Extinguisher Use training). Since Wednesday, the 3D printers in the makerspace have had some issues (many of the printers are out of service, print queues don’t proceed, etc.) so at the time of this post, I am still checking to see if our parts have been printed yet. As soon as the print job completes (probably by tomorrow), I will check the fit of the piece with one of our Rubik’s cubes and a motor arm.

Currently, I am working on completing the layer-by-layer solutions for the Beginner’s Method and designing the housing. For the solver, I will be working with Sam and JT in connecting the modules together. I am very confident that our team should be ready for our demo this upcoming Wednesday, assuming we won’t have any roadblocks with the 3D printers.