Team:

Since all three of us are software focused, the biggest risk that jeopardizes this project is the construction of the solving robot. To mitigate this risk, we’ve planned and chosen a mechanism that requires the least moving parts and precision out of all our solving options. The motor drivers we purchased are only able to rotate along one axis. They’re also quite popular options with a lot of use in other projects with a fair amount of documentation. On top of this, we plan to always have at least 2 members working with the hardware at all times. We’ve purchased two sets of the necessary equipment so that all the members can work and experiment on their own time (JT and Sam live together). If all else fails and we have none of the robotics working by the end of two weeks, we’ll begin to pivot and focus on the software side of our project, potentially creating a trainer instead of a solver.

In anticipation of the hardware challenges ahead, we’ve gotten started on the software necessary for processing and identifying cube configurations with OpenCV and translating configurations for input with the Beginner’s solving method. Finishing this part of the software requirements will allow us maximum time for working with the hardware that is arriving this upcoming week.

No direct changes were made to the design of the system. We’ve purchased all of the parts required and even planned for backups in case some parts were damaged or out of stock. We believe we have the tools and information necessary to proceed as planned.

---

JT:

This week, I oversaw the purchase of all the necessary equipment to get our capstone project moving. I created a Purchases excel sheet (attached at the end) with Lily to keep track of all our current and future purchases. We prioritized purchases that were needed as soon as possible to begin the construction of our cube solving robot while also listing less time sensitive purchases along with alternatives if any parts were to not fit out standards. We expect our Nema-17 stepper motors and A4988 stepper drivers to arrive by Monday of next week. In preparation, I’ve done research and looked at other examples as to how I can immediately start to begin to manipulate the stepper motors. Reading various Arduino forums about stepper motors, I’ve acquired a basic understanding of what is necessary to begin rotating motor arms.

I’ve also placed orders for multiple different types of speedcubes for the team. Since I have the most experience with speed solving, I chose an array of different cubes that we could potentially use for our solver. Different cube models typically come in different sizes, color configurations, and twisting mechanisms. Having different color schemes to test is important so that we can see which provides the best feedback to our cube state detection software. Having different twisting mechanisms is even more important because this is what directly affects our robot the most. A cube that allows for ‘corner-cutting’ or higher tolerances will be most beneficial to our robot. I’ve purchases a cube that comes with magnets in each side piece to ensure it snaps back into place to see how it compares in the robot with normal non-magnetized cubes.

I’ve also worked with Sam, providing input and feedback, about the software he is writing for our initial cube state detection. Looking at what Sam has accomplished this week, I began to see how we could integrate a third party algorithm that can solve the puzzle with the highest efficiency. Since we plan to write our own beginner’s method solving algorithm, we wish to also be able to incorporate a much more efficient solver to showcase our hardwares potential. I dissected the basic structure of how Kociemba’s TwoPhase solving algorithm works and gave Sam the feedback and information necessary to be able to adjust the cube state detection software so that it will integrate nicely.

I believe the team is currently on schedule to finish as we expect. We’ve taken a solid week to pre-plan the actions necessary and purchased 90% of the parts that we need for this capstone. Assuming the parts arrive next week as expected, I’ll be able to direct my full attention towards the robotics and hardware aspects of the project. By the end of next week the team will have the cube state detection software fully completed and parts of beginner’s method implemented. We also plan to be able to control at least 1 or 2 of the 6 motor arms by the end of mandatory lab on Wednesday.

---

Lily:

This week, JT, Sam, and I worked on purchasing the necessary hardware for our capstone project, Cubr. JT and I researched vendors for parts needed, keeping track of everything purchased and total costs in a spreadsheet. We saw that a lot of the parts we needed were currently backordered and thus had to find alternative vendors and/or parts for backup components. We expect these parts to arrive early this upcoming week so we can begin working with the motors and motor drivers as soon as possible.

Figure 1: Purchase spreadsheet

Sam was able to complete the cube configuration identification with OpenCV this past week, so I started working on translating the configuration for input with the Beginner’s solving method. I have been going through the basics of Kociemba’s TwoPhase solving algorithm to figure out how to translate the given cube configuration into a rudimentary text-based UI for human validation, based on Figure 3. From there, the team and I will begin writing the solving algorithm for the Beginner’s method. For example, we have the following test cube configuration:

FUUBUUDRBLBBBRLBLBFDDBFRUURFFDFDDFDUDDRLLLRRLLRLFBURFU

which is derived from Figure 2. After solving, the cube configuration should be the following, as seen on Figure 3:

UUUUUUUUURRRRRRRRRFFFFFFFFFDDDDDDDDDLLLLLLLLLBBBBBBBBB

As of today, I have been working on creating a Cube class with Face objects (all in Python) to map the input configuration, and expect to finish the Object-Oriented Programming aspect by the end of the weekend. Having this portion designed and done well is crucial for use with any solving algorithm that we may utilize. Since the Beginner’s method task is slated for two weeks, this upcoming week, the others and I aim to finish writing the 18 turning functions and test our implementation of the Beginner’s method to obtain a valid solution string for each configuration we test.

Figure 2: Test cube configuration; Figure 3: Output solved cube configuration

I believe that we’re on schedule to finish as planned. We’ve been careful to plan our purchases and work on the software ahead of time such that we have maximum time with working on the hardware component of our project in the upcoming weeks.

---

Sam:

This week, I made significant progress on the cube state detection software for our project. Currently, for the cube state detection, we are using the built-in mac webcam to detect and map all sides of the cube. The current experience for detecting the state of the cube is that a window pops up with a designated area for the cube to be placed in the webcam. From the user’s end, once the cube is placed in the center, the user hits the space bar which captures the average hue and saturation values of pixels for a given region of the image. Using a distance function to the nearest color, we classify a region of the cube as having a certain color and store this in a 2D list.

Figure 4: Webcam scan of a given side of a cube

Figure 5: Mapping cube faces based on centerpiece color

My progress is currently on schedule. I have the framework set up of how we will be scanning and mapping the cube. Next week, I will be working more with the testing and validation phase of the cube state detection algorithm and fine tuning the ranges in which we detect every color. Currently, we are detecting color in the HSV (Hue, Saturation, Value) color space because it is more robust in detecting color with different lighting. Currently, we do misclassify colors depending on the lighting, therefore, I will be fining tuning the ranges so that we do not misclassify any colors.

I will also be working close with Lily in the upcoming week to interface the cube state detection output with the beginner’s method algorithm so that we can start work on the solver algorithm. As we ordered parts in a timely manner, I believe our team is on good track currently with the project. We are trying to be ahead of schedule in order to create more buffer time with the hardware aspect of our project, specifically in the way we interface our software with the hardware components. For next week’s milestones, I plan to test the cube state detection algorithm thoroughly, and hash out and create the interface from the cube state detection algorithm to the solving algorithm (with Lily).