DevilBotz
2876

Java and the first 15 seconds

I joined the programming group and learned Java by working on our robot’s autonomous routines. My focus was the first 15 seconds of a match, when the robot had to carry out its routine without a driver.

This was my introduction to connecting code to a physical machine: writing a routine was only the beginning; I also had to test what the robot actually did.

Learning PID balancing

I learned and applied PID control to balance the robot. Instead of relying on a fixed driving command, I worked with feedback so the robot could respond to its tilt as it approached a balanced position.

Testing the move to swerve drive

As we moved from tank drive to swerve, I tested the accuracy of our drivetrain odometry—the robot’s estimate of its position. I needed to check how closely its actual movement followed the path we expected before relying on that movement in autonomous.

From a path to a complete autonomous routine

I compared the same routine in two stages: first, the path and odometry on their own; then, the routine with the other subsystems integrated. That let me check the driving behavior separately before testing the full sequence of robot actions.

Working with cameras and AprilTags

This was our first season using vision processing in competition, and I worked on the camera and vision software documented in our 2024 binder. We began with camera streams for driver visibility, then used PhotonVision’s AprilTag yaw measurements and a rotation PID to help align the robot.

As our system developed, we also used the camera’s position and orientation to interpret target measurements. The adjustable camera mounts below were part of the vision hardware supporting that work.

Relating target distance to shooter angle

My vision work connected camera measurements to scoring behavior. We measured actual distance, drivetrain-odometry distance, and vision-reported distance alongside the arm angles that scored reliably. Those measurements became our distance-to-arm-angle mapping.

Our binder records a piecewise mapping followed by a second-order polynomial fit after we gathered another set of measurements. This shows the calibration and testing behind the aiming behavior, rather than just the finished routine.

Building and deploying autonomous paths

I used PathPlanner as part of our autonomous development and tested the routines before deploying them at two competitions. We used a shared naming scheme for field positions and notes so we could describe a routine clearly—for example, which starting position to use and which notes to collect.

Our software combined those paths with subsystem actions. Later vision-pose updates also supported our drivetrain odometry and the “Drive to Amp” driver-assist feature described in the binder.

Planning a seven-week build season

As team lead, I planned our seven-week build season. I organized the schedule around important dates and the work that programming needed from the rest of the build, so we could prepare the robot for competition within the time available.

I used build timelines and sprint planning to make the work visible and help coordinate progress across the group.

Teaching Java and leading programming

I trained new programmers in Java and led a 10-member programming subteam. I delegated tasks, mentored new members, documented vision-calibration work, and created communication meetings to help unblock teammates.

That meant making room for other people to learn while keeping our autonomous and integration work moving toward competition.

Improving autonomous between competitions

I continued developing and testing autonomous routines as we moved from one competition to the next. These two runs show the improvement over one week that I described in my project notes.

I worked with our mechanical, electrical, and drive groups during that process. Across my FRC work, I developed and tested 15 Java autonomous routines; through our combined testing and integration, we reached 85% successful autonomous runs.

Turning game analysis into priorities

As Vice President of Competition, I worked on our game analysis, strategy, and research/design process. I helped evaluate possible robot actions by their value and difficulty, then organize the choices into must-have, should-have, could-have, and won’t-have priorities.

That process helped us choose a robot focused on shooting quickly and reliably. The research spreadsheet and MoSCoW list show how we turned the game’s possibilities into a practical direction for the build.

Using cycle times to guide design

I worked on the cycle-time analysis in our strategy and research/design section. Our calculator takes in operating variables and estimates the time and scoring value of different cycles; it flags cycles that cannot fit into a 25-second active period.

We used that analysis to guide goals such as subsystem throughput and hopper capacity, connecting the match strategy to what the robot needed to do physically.

Connecting research with the robot architecture

I contributed to the research/design work that connected our priorities to a robot concept. We looked at earlier robots from the 2017 game for useful ideas, including shooter throughput, hopper handling, and intake arrangements.

Our mechanical, CAD, electrical, and software work came together through subsystem prototyping and integration. I documented that process in the technical binder and used it to explain the reasoning behind our robot to judges.

Building the technical binder and preparing judge talks

I was responsible for building the full technical binder and preparing our judge talks. I brought the strategy, research, design decisions, and subsystem descriptions into one document so we could explain both what our robot did and why we made those choices.

The strategy and research/design pages are the clearest record of my senior-year work. The subsystem sections also document the engineering done across our wider group.

Scouting with EPA and developing match strategies

I built a comprehensive spreadsheet of the teams at each of our competitions and used estimated points average (EPA) to compare their expected scoring. I used that information to build match strategies and coordinate with our alliance partners.

Coaching the driver and operator

I served as our drive-team coach and trained the driver and operator to work together. I focused on their coordination and communication, while developing the match strategy they needed to carry out on the field.

In this practice session, another robot played defense against us. That gave us a way to practice the connection between the driver and operator under pressure.

Introducing younger students to robotics

I also took part in our local middle-school outreach, presenting robotics and FIRST LEGO League. This gave me another way to explain our work: making the robot and the engineering process approachable for students who were meeting them for the first time.