Experiences

ROB 330 - Simultaneous Localization and Mapping

I was super excited before taking SLAM Robotics as I was excited to code for robots. However, over the semester I had my course I learned that coding robots is vastly different than coding for my computer science classes. Problems I had were not necessarily solvable through a google search, we suddenly didn’t have any of the debugging tools we had in my EECS classes, and most differently, in class we learned the high level algorithm without going into detail about each step of the code. Through the semester I learned how to code in a much more realistic environment, where the answers are not right out of reach and improved my grit.

We worked in teams of 4 in the class to split work. In this process I practiced my systems thinking, improving how to split work and balance things between our teammates. I also practiced trusting my teammates to do their own thing. Finally, while working with a team, I practiced empathy. Everyone had other courses and other things to balance with their time, and we all had to be understanding of how much or little time one could put into the project.

For our final project we had to do something new and creative for our robot, which pushed my creativity. We ended up repurposing our robot to become a cat that knocks objects off of tables. I would normally not have had to think of something like that in my classes, but this course forced me to improve my creativity.

Atombot: Swarm Robotics and Collective Intelligence

Since January I’ve had the opportunity to work on the Atombot: Swarm Robotics and Collective Intelligence project under Professor Y Z at the University of Michigan. My cohort of classmates were the first group to work on the Atombot project, and with that came a lot of excitement, but also some difficulties.

Our excitement drove us forward to creating a project proposal and got my team to start designing and building a robot with 4 leg-wheels. Through this process, I noticed a lack of leadership and decided to fill that hole. I learned how to organize meetings, excite my team members, and help fill gaps in knowledge on my team.

Along with organizing the subteam, I had to work on my systems thinking, as robots inherently pull from so many areas of engineering. Planning timelines and purchases required thinking ahead which was another skill that I developed over my time at Atombot thus far. Finally, as with any robotics project, I had a chance to improve my teamwork. Splitting work fairly and balancing expectations of everyone on the team are things I’m always striving to improve, and I was lucky enough to have another chance to practice it.

ROB 311 - How to Make Robots and Make Them Move

I felt extremely under qualified for this class when I started. I felt as though I was lacking background in many areas and experience with the tools we were using. Due to this, I was forced to connect with many more of my classmates than I do in most of my classes. One of the people I worked with was my teammate. Together, over the course of the semester, we built a ball-bot, a robot which balanced on top of a basketball and drove it around. We spent our time going through the entire engineering process and pulling skills from various areas. We designed, fabricated, and built the robot. In addition wired, coded, tested, and tweaked our robot to improve.

From this class I learned a lot about communicating and how important a community is. If we didn’t work with other teams, none of us in the class would have done well. In addition, we improved our risk management skills. We had to decide between a guaranteed 80% or a chance at 90% depending on how we configured the robot.

REUSE - Research Experience for Undergraduates in Software Engineering at Carnegie Mellon

The REUSE program was my first research experience. My research was creating and evaluating the possible applications of a configuration-based performance fuzzer. I expanded the JQF fuzzing library on github by creating a new performance fuzzer, which compared the effectiveness of a program with different configuration settings. The fuzzer would create “random” inputs and assess the difference in runtimes between two configurations. Based on that, it would then decide whether or not to create more inputs similar to the input that was just run.

From this experience, I learned more and got more comfortable with git repositories. In addition, as my first research experience, I learned more about what research is. I learned how to find and read research papers effectively, communicate with a professor about progress, and what problems I should solve on my own vs as my professor, among other things.

It was also learning how to communicate in a group and reporting to someone. I learned how to give regular updates, the best way of communicating information, and what content to leave in or cut out of an update.