Course: CSCI 1510

Written Narrative

Last year, I was the lead programmer on my high school’s FTC robotics team. While it was fun to work on things that were interesting to me, particularly the programming aspect of it, it definitely taught me that failure is normal, and it happens all the time.

One of the main issues that occurred while I was programming the robot were mainly issues with the robot itself, rather than the code. For instance, we had an arm which was pretty janky to put it nicely. For instance, whenever the arm was raised, it would jerk around, which ended up being really annoying and silly to fix.

Another one of the issues was that the motor wasn’t able to hold with the weight of the arm, so I had to main the arm motor constantly powered, so that it wouldn’t scrape against the ground and subsequently cause the robot to not be able to drive.

Despite the effort I put into refining the code, the hardware issues were causing a lot of issues. These issues were annoying, but they could also be detrimental to our team whenever we compete. Ultimately, I realized that not everything could be fixed just from the code, so I ended up trying to make the actual mechanic of the build better. This worked, but the entire system was super strange, so it wasn’t super great.

After putting in time to get it to work for the most part, I learned from my failures and learned that not everything was under my control. Through these challenges, I learned the importance with the balance between software and hardware. Previously, I used to think that if I could tweak the code enough, maybe everything would work out. However, after this experience, it taught me that no amount of programming could fix a mechanical issue.

This experience shifted my perspective on problem-solving. I realized that no matter how skilled you are in one area, like programming, you need an understanding of all of the parts to troubleshoot effectively. I also learned that sometimes, solutions that are good enough are sometimes necessary, especially when you’re approaching deadlines. I had to let go of perfectionism and accept that our robot didn’t need to be perfect, it just had to work for the most part.

This also goes with anything related to working in teams. No matter how skilled you as an individual are, you need to work with a group of people in order to accomplish something large. You can’t be the master of all trades, because if you try to be that, you’ll end up being mediocre at everything.

“The man who chases two rabbits catches neither.” – Confucius

For anyone working with robotics, my advice would be to approach each project with flexibility and an open mind. Robotics, like many things in life, are inherently unpredictable, and failures are a part of the journey. Sometimes, you have to work around issues with creative solutions—in this case, trying to fix hardware issues with software. Importantly, don’t be afraid to experiment; you may end up with something that’s not ideal, but functional, which sometimes is what you need.

“Comic Strip”

Brainrot Video