Code Teaching Curriculum

Question

How can we teach new robotics members to indpeendently program and troubleshoot an FRC robot during the main season.

At the beginning of the training process, I identified that the main challenge was deeper than teaching new members Java commands. New programmers had to understand how all the systems (Java, WPILib, vendor libraries, the RoboRIO, motor controllers, Phoenix Tuner X, and Driver Station) worked together to form a cohesive system. Most of the students I worked with had little experience with FRC programming, so had to modify my curriculum from rotation to rotation to ensure I was accomodating all experience levels.

I therefore defined my goal as helping new members develop understanding of the complete control system so they can eventually program and troubleshoot everything independently. To work toward this goal, I taught coding concepts and the relationship between software and physical hardware.

Brainstorm

Before teaching I considered ways we could introduce programming to new members. I helped edit and refine the coding curriculum to optimize its content absorption among new members.

One option was to give students working examples of ready-made code that they just had to copy and paste. This would be fast, but I thought it would encourage students to just copy paste code instead of internalize the concepts behind the code. Another option was to focus entirely on Java fundamentals before dealing with the hardware. Although this would lead to a stronger programming foundation, it would make the lessons less connected to what students need to accomplish with the robot.

I decided towards a more hands-on approach introduce a small amount of Java and then immediately connect to real FRC hardware. I wanted to allow students to troubleshoot problems themselvers. Instead of fixing an error, I would ask questions like "what do you think is causing this" or "what part of the system should we test first" I wanted to integrate mistakes in the learning process.

I also realized that tools such as Phoenix Tuner X could be a step between hardware and Java. Before asking students to control a motor through code, we could use Phoenix Tuner to verify that the RoboRIO could communicate with the motor controller to identify it is CAN ID.

Plan and Design

I planned the teaching in steps so the new members wouldn’t get overwhelmed. First, I explained how the RoboRIO, motor controller, Driver Station, WPILib, and Phoenix Tuner all connect. Then we used Phoenix Tuner to make sure the hardware was communicating before moving into Java. After that, I introduced basic Java concepts and helped them connect those concepts to actual robot code. Finally, we tried deploying the code and testing the motor.

Build and Create

For the coding part, I worked with new members while they made and tested basic FRC programs. The test board used a Kraken X60 motor with a Talon FX controller, so I also explained why we needed the CTRE Phoenix 6 vendor library instead of just WPILib. 

I also taught some basic Java concepts like methods, constructors, classes, inheritance, and overriding methods. I tried not to just give them code to copy because I wanted them to actually understand what each part was doing. 

For assembly/electrical, I helped teach newer members how the robot’s electrical system works. We went over how power flows from the battery to the breaker, PDH, and different controllers. I also helped them practice crimping, stripping wires, and some soldering

When some crimps came out loose, we had them do tug tests and figure out what went wrong instead of just fixing it for them. Usually it was because not enough copper was inside the connector or the crimper wasn’t closed all the way.

Test and Analyze

One issue we ran into was that the code built correctly on the laptop, but it would not deploy to the test board. We tried a different laptop, Ethernet instead of Wi-Fi, and tested the motor through Driver Station. Eventually we found that the laptops were using WPILib 2026 while the RoboRIO was still on 2025. After updating it, the problem was fixed. 

This was a good example of how not every programming problem is actually caused by the code. Sometimes the issue is firmware, hardware, networking, or something else in the system.

We also had a motor controller that would not show up on the CAN bus. We checked power, the CAN chain, and Phoenix Tuner. Eventually we found that one CAN wire had been crimped into the wrong terminal and was shorting the signal to ground.

Reflect and Improve

One thing I learned is that teaching someone is usually slower than just doing the task yourself. There were a lot of moments where I could have fixed the code or wiring much faster, but then the new members wouldn’t really learn anything.

I think having them troubleshoot their own mistakes worked well because they started understanding how to solve problems without asking someone else. Though asking others for help is always encouraged, independence and the ability to think through problems yourself is the ultimate goal and is very crucial. The main thing I would change is giving students more time in one subteam. With only a short rotation, small setup problems can take up a lot of the time and we don’t get very far into actual programming.

Another thing we worked on was fixing the testboard. Because each rotation is only a week, minor issues with the test board take up a huge percentage of time that could be used teaching. I spent a class period during week 4 just fixing the test board. Overtime, it had gotten a lot of wear and tear. The screws had come loose and the CAN wiring was faulty. Also we had trouble connecting the motor. To address this, I spent a chunk of time just addressing any issues I could think of with the test board. This helped a lot because for subsequent rotations, we were able to teach quicker without having to troubleshoot issues with the testboard every week.

Communicate

A big part of this task was explaining technical ideas in a way that made sense to people who had never done FRC before. I tried to explain why things worked instead of only telling people what to do.

For example, instead of just telling them to install Phoenix 6, I explained that it lets our Java code communicate with the Talon FX motor controller. When we were doing electrical, I explained where the power was going before we started wiring things.

I also asked people questions while they were debugging instead of telling them the answer straight up. I think that helped them understand the problem better, and it also made me realize that by teaching something, you understand your content more deeply too.