RI7D: An Engineering Journey – Insights, Rants, and Revelations

Day 1: Kickoff and Planning

On Day 1, we kicked off the event at the ACE Climatic Wind Tunnel in Oshawa, where we met with other Toronto-area teams, shared ideas, and brainstormed strategies. The energy was electric as we discussed the game animation, reviewed the rulebook, and identified the subsystems we’d need to build. Mentees were introduced to the project, and everyone left the kickoff feeling motivated and ready to tackle the challenge.

At this point, we didn’t think much about what we had—or didn’t have. The only things in our possession were a drivetrain and literally nothing else. No inventory, no spare parts, no tools beyond the basics. But we were too caught up in the excitement to worry. After hours of brainstorming and planning as a team, we went home with a solid plan to start prototyping our ideas the next day. Little did we know, things wouldn’t go as smoothly as we hoped.

The team at the ACE Climatic Wind Tunnel during the kickoff, meeting with other Toronto-area teams and brainstorming ideas.

Day 2: Design Struggles and Borrowed Parts

On Day 2, we didnt have access to our workspace, so we began trying to pick a point-scoring scheme to focus on. After much deliberation, we decided to focus on creating a mechanism that could score coral and process algae. (If you’re not familiar with FRC, here’s a link to the 2025 Game Manual for reference.)

For those who don’t know what coral and algae are, here’s a quick explanation:

The coral is the white tube, and the algae is the green ball.

We finally settled on what we thought would be our final design and began identifying potential issues before prototyping it with wood. Meanwhile, I compiled a list of electronics we needed to borrow from other teams, and team members went out to gather the necessary components. In a moment of overconfidence (or sheer optimism), I started working on the code without even considering the hardware we had—or didn’t have. (I now know, that it wasn't the best idea)

By the end of the day, we weren’t entirely satisfied with our design so we had to scrap it, but we managed to secure a RoboRIO, radio, and PDP from another team, which we would receive the next morning (Day 3).

Day 3: The Battery Crisis

We started the day by assembling what little we had from our inventory: a RoboRIO, a radio, and four motor controllers. That’s when we realized something glaringly obvious—we didn’t have a battery. Without a battery, we couldn’t test any of the electronics, and we couldn’t test any of the code. It was a major roadblock that brought everything to a standstill.

With nothing to do on the control systems side, most of the control systems team pitched in to help with mechanical and CAD work wherever they could. It was a frustrating and demoralizing day, but we had no choice but to keep pushing forward.

Day 4 and 5: Locking In and Problem-Solving

By Day 4, we were fully locked in. We borrowed a battery and a VRM (Voltage Regulation Module), only to realize we didn’t have the right cable to power the VRM. So, one of us went out and bought the cable (that was only avaliable from a store 4 hours away). Then, we discovered we didn’t have the lugs for the 6 AWG wire needed to connect the battery. So its my turn for a trip to the store, and we finally had what we needed. These days were a whirlwind—every problem that came up, we tackled head-on without slowing down.

The lugs we finally found after a long search. This was one of the many hurdles we faced during the build.

With the battery and VRM in place, we could finally flash the radio and the RoboRIO, allowing us to start testing and working on the software side of the robot. After flashing the radio, we spent some time trying to push code, but nothing was working. The motor controllers were flashing strange colors, and after wasting some time, I looked up the error codes. Turns out, they were indicating a sticky fault.

What’s a sticky fault? It’s a persistent error in the motor controller that doesn’t clear automatically and requires manual intervention to reset. According to the PDF spec sheet for the motor controller, I needed to connect to the RoboRIO or PDP (Power Distribution Panel) to clear the faults manually. The PDP, however, was made in 2015 and didn’t have a USB-C port or anything modern—so I had to plug into the RoboRIO instead.

But when I opened Phoenix Tuner (a software tool used to configure and diagnose CAN devices on FRC robots), nothing showed up. This meant there was likely an issue with the CAN wiring. At this point, literally anything could be wrong—this was the first time I was dealing with this hardware, and after double- and triple-checking everything, we still couldn’t clear the sticky faults or test if any of the components worked. It was a frustrating setback, and we started to dread what Day 6 might bring.

The PDP with a red light indicating a communication or power fault. This was one of the many hurdles we faced during the build.

Day 6: A Fresh Start and New Challenges

Deciding to start Day 6 with a fresh mind, I arrived at the workspace early and decided to tackle the CAN wiring issue head-on. I re-did all the CAN wires, plugged my laptop into the RoboRIO, and opened Phoenix Tuner. To my surprise—and slight frustration—it just worked. On the first try. I tried to balance my anger at how simple the solution was with the relief of finally making progress.

At this point, the only way to make the robot move was to manually set the output percent of a motor controller using a slider in Phoenix Tuner. But just seeing the robot’s wheels spin was enough to give the entire team a much-needed boost of motivation. It was a small victory, but it reminded us that we were capable of overcoming the challenges in front of us.

With the CAN communication issue resolved, I could now access the firmware for the PDP and motor controllers. After more scavenging on the internet, I managed to flash newer firmware onto the devices. But just as one problem was solved, another emerged. When I was writing the code for the robot, I had used WPILib 2024, thinking there wouldn’t be much of a difference—and, admittedly, out of laziness. However, I had flashed the RoboRIO with 2025 firmware. Naturally, pushing 2024 code to a 2025 RoboRIO didn’t work at all (which, to be fair, makes sense). So, it was time to install WPILib 2025 and rewrite the code.

By the end of the day, the code and firmware for the RoboRIO were aligned, the motor controllers and PDP had no faults, and all the electrical components that needed a team number were properly configured. I tested and confirmed that all the motor controllers were working. It felt like we were finally making real progress.

As I left the workspace that evening, I thought everything would finally work together the next morning—the morning of the 7th and final day. Little did I know, the issues never stop.

The robot pushing an algae up a ramp.

Our Robot and Team