I joined StrykeForce in my sophomore year of high school as a member of the Programming Subteam. During the first year, I learned Java and WPILib which is the library that we used. It really isn’t until the second year where I started to thrive. In my second year, I started to focus on 3D localization with vision systems. As an extension, I learned a lot about automation and computer vision. Furthermore, in both my first and second years, I was getting hands on experience with control systems, handling programming in a team project, and learning how to engineer. However, in my senior year, things changed.

In my senior year, I was made the Programming Team Lead. As Lead, I led several projects and played a large role in changing how we structure our programming team. One of the first things I changed was our vision system, as I had used it extensively, I did not like using it and believed that it would be best to develop our own custom system. This development was quite lengthy and took an entire off season to get a version that was good enough to go to competition. I and one other student worked on this project. I focused on the computer vision, data processing, and networking with the other student focused on the web interface, Linux integration, and general loop structure. Through doing this, we were able to come up with a fully in-house software that would be able to be updated whenever the team needs a custom feature. Furthermore, we were able to customize how the data is processed and improve our accuracy. 

One other major project I worked on was a upheaval of how we handled our automation. In years past, for every autonomous routine, we would spin up a custom command for every single routine. This was usually a lengthy and somewhat involved project. When the year’s game required many routines, it meant that we would spend a significant amount of development time purely on writing routines. In my senior year, the game could feasibly have hundreds of unique routines. As such, a change was needed. This is where I came up with the idea of creating an autonomous handler which would be able to take minimal input and produce a routine that was as effective as our old system. This resulted in our routine development time taking hours to only taking minutes. There were even times in competition where we created a unique routine on the fly without testing it.

The last major project I will talk about is our how we tracked game pieces. Due to the game pieces being bright orange, we theorized that we could detect the pieces by looking for that specific color. As such, I went to work working with a vision software that would filter the image for the color and use two PID loops to control our robot to drive and pick up the piece. This system was integrated into all of our autonomous routines so we would use full 3D localization for 90% of the routine but when we needed to pick up pieces we would switch to using the data our camera would feed us to get us the rest of the way. It was so effective that we went from being 60% accurate to almost 100%. The drivers liked it enough to also implement it when they couldn’t see so all they had to do was push a button and the robot would automatically pick the piece up.

In all, my time on 2767 taught me very valuable things not only about myself but also how to handle team environments. I would not be the student, the person, or the engineer without these experiences. It gave me confidence in my ideas and also showed me that as long as I am in the right environment I could not only succeed but thrive.