23 March

Published by jaceron on

Team:

For this week, the team met with the staff to figure out what was expected from us. We have been making fairly steady progress in all three major components of the project. We decided that if we could have one motor arm be able to read and input and properly turn the cube, then we’d be in a good place for the last four weeks of capstone. Our biggest challenge is to ensure that we can turn accurately with a load. If this isn’t possible, it basically ruins our plans for the rest of the capstone. To ensure this works, we’ve tested thoroughly before attempting to put any kind of load on the motors. We hope to start turning the actual cube in the following weeks.

As of now, there are no major issues blocking the team’s progress. We’re on track to perform for the demo and hopefully we’ll begin to see the light in the next two weeks.


JT:

This week, I continue to work off of the progress I made before spring break. With one test motor working, I double checked all the connections, voltage, and current values to ensure that I wouldn’t burn anything out. Specifically, I made sure the reference voltage on the motor drivers was around .55 Volts to limit the max current on the motors. To ensure the current limiting worked as expected, I measured the actual motor in series to see that its current value was about.5 Amps, well below the max current it can take. I did notice that the motor itself ran quite hot when I left it running. However, my test code did have it performing moves until I removed the power supply. Upon further research, I found that our Nema-17 stepper motors are rated for 120 degrees Celsius. Also, the motors are supposed to start failing by completing the wrong amount of steps before it actually fails because of the temps. With this in mind, I’m pretty confident that this single setup is complete and can be readily duplicated in the future.

I also began to work on using serial input to control the motors. I set up some basic functions to allow the arduino to take an input string ending with a newline character. The string is then stored in a local variable and ready to be parsed. Next week I hope to be able to parse a string of at least 20 characters, and move the motor appropriately. By the first demo, I’m sure we can also have a coupling arm on the motor moving at least one side of the cube.


Lily:

This week, I discussed my power circuit design with the team and others involved in capstone, including our TA and advising professor, about concerns that arise (e.g. AC noise) and determined that the current circuit design is adequate for now. However, I will continue to ask other resources for their opinion on the circuitry.

A few of the drivers that I soldered had loosened pins, so I resoldered those pins as well as 7 more stepper drivers so that JT can begin working on making and testing the parallel motor-driver setups. JT and I discussed the heat that was coming off of the motors and determined a safe operating temperature by limiting the maximum current for the motors. We wanted to quickly find a safe operating temperature for our own safety and with the housing in mind. We noticed that too low of a current would result in a really high-pitched whining in the motors.

During Spring Break, I noticed that my implementation of the moves was not adequate enough for the implementation of the Beginner’s Method. I approached the moves definition very naively, attempting to shift cubie positions without entirely identifying and linking these cubies when the Cube object is first created. Subsequently, I had to refactor bits and pieces of my code since Sunday. On Tuesday, (long story short) I lost EVERYTHING on my computer (partition was corrupted…). Because of this, I’ve lost some of my refactored code, but I have a stronger idea of what needs to be completed so that I can finish my Beginner’s Method. I helped Sam and JT take in a cube state configuration and feed it into the existing Two-Phase method for solving, and attempted to hand-solve the configuration according to the outputted solution string.


Sam:

This week, I made great progress on integrating our software components. After finalizing the cube state detection HSV values and testing with scanning an entire cube, I was able to pipe this configuration string with the two phase algorithm to output a solution string. This integration is a big milestone that we hit as we are now in the process of connecting our modular components. I successfully scanned a cube with the correct orientation and passed the cube’s configuration string to the two phase algorithm to get a sequence of 20 or less moves that would solve the cube. The next major integration is having the Arduino correctly control the motors to move the faces of the cube in accordance with the solution string.

The integration between cube state detection and the solver is specifically designed so that it is easy to interchange which solver is used in the pipeline. This makes our code cleaner and more readable. I spent time specifically designing how to organize our code and to minimize as much duplicate code as possible. Code management is important with a project like such. We are making great progress and in the coming week I will start design and implementation work from our software to our hardware. The following is a picture of what the solution string is and what the Arduino needs to comprehend to figure out which motors to turn. Go Cubr.

 

Categories: Status Reports

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *