WEEK 10 DECISIONS,DECISIONS…#

Machine week!!!! Very big and crazy especially for me since I tend to have a historical aversion to group projects. Since coming to the Media Lab, however (in large part due to my amazing peers), I have had the incredible oppurtunity to work with others and be continously amazed by their brilliance and coolness. As a result, I feel like I am learning a ton and slowly changing my tune on my curmugdeonly group project ways.

While the main documentation for our project can be found on our website, (WATCH THE VIDEO ITS FUN!!!) I will be talking here about my own journey and what I specifically worked on. The TLDR of that is that our group couldn’t decide what to make, so we decided to make a machine that makes decision by flipping a coin and crosses out a series of decisions on a piece of paper until only one remains.

To begin, I had an early conversation with our Group Leader/Non-Gendered Mom Person/Dictator Jessica and Cyrus on what sort of tasks to take on. The primary question was whether or not we wanted to work on something we knew we were good at or something we were bad at but wanted to improve. I was firmly in the latter camp, so in a move of intense hubris/dedication to scholarly pursuit I self volunteered to lead the Electric Engineering team. This was a mostly beauracatic position, but nonetheless I was excited to gain the oppurtunity to learn some EE stuff (and hopefully a little MechE too since I wanted to learn).

Right out of the gate, I was the person charged with working with Jake (super goated TA this week thank you again Jake!!) to get the kit we were given of modular components setup and moving. After some easy setup tasks of making a virtual environment and installing the required packages, we had some motors moving! I then figured out how to get the other components moving, since we would need two motors, a solonoid, and a servo for our machine. This was initially a bit confusing as the Python code was a bit dense and difficult to parse, but I slowly wrapped my head around it. I needed to brush up on my async Python code fundamentals a little, but after I spent a few hours banging around and changing/trying things, I got all the pieces moving.

model

model

Luckily, the MechE team frontloaded the work of getting the physical structure of the machine setup, so by Friday or so I had a cute little chasis to play around with. In the end Kye, Jessica, and I synced a lot and wrote a lot of the final code either in tandem or in close communication. I specifically wrote a lot of the lower level embedded code that the others built their interface on. For this, I worked in spirals - as soon as I could make the motors move and had them mounted on the belt, the next step was to make them move to particular coordinates. This was seemingly easy, but I ran into the bug of the motors glitching out with repeated movements and going in odd directions or moving by weird steps. For example, I would tell it the motors to move in the positive X direction, but they would move in the negative X direction. Quentin at some point saved the day and told us to try using the provided function goto_and_await rather than simply the add to queue function for adding commands. The difference seemed to be that the second one doesn’t await, thus making it easy for the motors to fire early and go out of sync while the first does. With this problem fixed, I could then easily tell the motors to go anywhere I wanted, thus enabling me to hand off the higher level code to the software and other EE team people.

model

Another detail I had to figure out was the problem of setting the home on the machine. As far as I could tell, the machine had no way of knowing its absolute position at any given time, thus neccesating that we define and set its origin of 0,0 by hand each time we run the machine. I spent a little time figuring out how the conventions that Jake gave us through his code worked by seeing which direction seemed to be positive and negative X and Y, and then communicated this to the software team and helped write some basic code to send the machine to where it thought home was.

At various points, I also attended a few MechE meetings to check in and get some wise learnings and teachings from Jonny on structural integrity and the like. I didn’t contribute a ton to the MechE team, but I did at least assemble and mount the webcam to the skeleton of the machine.

model

During all of this, I was the main communicator with Grand Overlord Jessica, telling them how our team was working and making sure our decisions made sense with there’s and their team’s. It was important to work through various organizational decisions like which bits of code were to be EE embedded code vs higher level software code (for example, crossing out a particular line), and I was the main EE rep messaging and chatting to coordinate this.

draw

flip

Overall, this was a very intense but fun week and I really felt like I got the oppurtunity to bond with my cohort, which is really nice :) My one critcism is perhaps that Jake is simply TOO SMART in that the setup kit we got made it super easy to make things move, but perhaps too easy? I am not sure if I have a strong foundation in making things move without this kit in the future, even though I enjoyed using it overall.

model

NOTES FOR PROGENY#

-trust your cohort, they’re amazing!

-if you plan tasks out and when and how you will do them, you can avoid late nights (we did this very well actually, thanks Jessica!)

-group project excellent op to become besties with your classmates