Preseason: December Training Groups

With build season on the horizon, we uphold a cherished tradition of introducing our robotics enthusiasts among the freshmen to the art of constructing our robot. This involves granting them the autonomy to choose their preferred subgroup for training and providing diverse learning opportunities. Here are what our subgroups did for training:


Programming training is a course of 3 group meetings followed by individual work. The group meetings are generally conducted at home over Discord calls. This is to allow for members of programming training to attend other training when the lab is open, and because we don’t have enough computers with the required programs to host training in the lab.

The first meeting explains the general structure of our robot code and downloads the programs on each person’s home computer. We download VSCode with WPILib (, and GitHub Desktop ( We also get everyone added to our GitHub organization.

The second meeting gets each person started with their own branch on the 2023 training repository. We show them how to code the basics of a subsystem and how to set up the rest of the code so that it would work, including setting up Inputs and Constants files. We also explain what functions are used to complete the objectives such as default commands and motor interfaces.

The third meeting finishes explaining the functions of WPILib. This sets them up to start coding subsystems on their own. They are provided a training subsystem that is a collection of motors and motor groups that they must use to get encoder positions, and set to either speeds or position setpoints. They are expected to code it from the input file through a command and a subsystem to control the motor. This uses both SparkMaxes and Talon FXs. They also figure out how to stop the motor automatically when the encoder value is greater than a certain value or less than a certain value.

After the third meeting, students continue to work on their training alone and are encouraged to ask questions in the chat. Once they complete each subsystem it is checked by the lead programmer and feedback is given.

We use GitHub in two major ways. Firstly we use it to back up all of our code and ensure that we always have a working version stored off-site. Secondly, we use it to allow multiple users to edit the same codebase. Each programmer works on their branch on different parts of the robot. For example, one person would be working on the drivetrain while another is working on the pivot, and a third person is working on the intake or shooter. This allows for faster code development. Once any section of the code is completed, the programmer creates a pull request explaining what they did. The lead programmer then checks the code manually to find any errors and then tests the code on the robot. If the code works well, it will merge into the main branch.

Code Structure:
We use a command-based robot for the structure of our robot.

Each major component of the robot gets a subsystem. Subsystems deal with moving motors and converting sensor readings into meaningful data. This could be converting encoder ticks into an angle for an arm, or creating odometry readings for the drivetrain. Subsystems must have all motors private and set motors to a speed/position once per cycle. This means that most subsystems have fields that serve as intermediaries for the speed. Most subsystems should assume the previous value is continued unless told otherwise. This allows for instant commands to be used for things like an intake. Subsystems must also be singletons. This means that only one instance of a subsystem can exist. This is implemented by using a getInstance function to find or generate the instance. This simplifies code and means that commands do not need to be passed subsystems to function. All subsystems are placed inside the subsystem folder in the code

Each function of a subsystem gets a command. Commands are named in the format [Subsystem]_[Function]; ex. Arm_Move or Grabber_Intake. Commands cannot interact with motors directly, they must pass through a subsystem. This decreases the number of points where a motor can be used and simplifies debugging. Commands must declare their stop condition in the Java Docs at the top of the class. Commands are to be in a folder named after their subsystem inside the commands folder.

All Inputs are handled through the class. This class is the only place where joysticks are defined and contain functions that return any values. This allows for easily switching controllers and button mapping. At the top of this class, there will be a comment explaining what each button does on the driver and operator controllers. This class is also where any speed reduction can occur by multiplying or dividing controller inputs.

All constants are placed in this file. They are organized in subclasses by subsystem and in interfaces beyond that if needed. This allows for easy importing and organized values. Constants can also contain functions that call for constants, such as an enum to value function or functions that read/write constants from a file. This is used to maintain manually adjusted constants across instances of the robot without updating code. The appropriate constants are written to a USB drive in the rio and read from it on startup. All constants must be public, static, and final.

General Rules
Avoid repeating code. If something is already written and needs to be called multiple times, change it to a function and call it from both spots.

Nothing should be public unless necessary. If a variable needs to be changed, create methods to regulate the values. Assume that anyone changing the values doesn’t know the limits of the robot or subsystem and limits the value in the method.

Don’t use System.out.println. It is slow and not very useful. Instead, push data to SmartDashboard. If data should be shown to drivers, set the position on the board it should end up in.



The elevator chose to assemble an elevator for our robot using the ThrifyBot Elevator Assembly Guide which utilizes normal FRC pieces to create an elevator for the robot. The team then proceeded to cut the metal pieces needed for the elevator using our chop saw and band saw. We carefully taught them the correct way how to operate these machines for them to be able to use these machines in the future in the process of building our robot.

After all the materials were gathered, then the team started to assemble the metal pieces that they cut out onto each other utilizing L-brackets. The freshmen were taught the proper ways of how to use a drill such as putting in and taking out bits and the different modes on the drill to put on the L-brackets safely. They then learned how to construct the bearing blocks using the Thrifybot guide and mounted them on the metal pieces making our base stage of the elevator. While this was going on we split the team into two in order for the second team to cut more metal for the second stage which goes inside the base stage.

They then slid the second stage into the base stage. We are practically done except, we need the chain break. After we get it, then the elevator will be finished.


Diving into the field of scoring, the team chose to design and produce a 2022 Cargo shooter. This was carefully chosen after researching previous games and designs our team was unfamiliar with, and was a good training exercise for newer members. Utilizing OnShape, a shooter was designed that consisted of a dual-wheel design and would be driven by belts and gears. This not only taught newer underclassmen about CAD basics, but also mechanical design in the use of hex shafts, gears, pulleys, and belts. Soon, the design will be fabricated from Lexan on our CNC router and then assembled for testing with the 2022 Cargo pieces prior to kickoff.


The electrical team introduced its new members to the world of electrical specifically how to wire correctly and safely and how to use specific electrical tools in meetings. The team’s first workshop was an introduction to electrical and the function of the electrical components that are inside of the FRC robot in order for the new members to gain a further understanding of how the electrical components correspond with the other parts of the robot. Here is the link to the presentation that we used in the workshop:

In our second workshop, we taught the new members how to operate electrical tools safely and efficiently. However, they did not use the tool yet but they have a further understanding of what each tool does and how they can use it effectively without harm. Here is the link to the presentation: In the third workshop, it was an interactive workshop in the lab where we taught how a basic FRC electrical circuit works using a previous bot. Besides our presentations, we showed guidelines to the new members on how to wire effectively:,,


The new members were taught how to cold call. This involved utilizing our cold call script that is there to help the new members if they are stuck or if the responder has a question for them. This provides assistance to the new members. Cold calling allows the members to learn how to speak in a businesslike manner in order to gain money for the robot.

As well as this, we started brainstorming for the impact video that will have to be made for competitions. We brainstormed all of our team’s accomplishments throughout the past few years and looked through moments in order to include them in the video. We also progressed through and brainstormed through the Impact short answer questions. This teachers the new members how to cooperate with a team in brainstorming which could give them a plethora of new different ideas that they might not have though of at first.