Training is one of the biggest issues with FRC. The learning curve can be very intimidating for new people, especially people who have no robotics experience. This year, our team reevaluated how we do training. Rather than throwing people into the deep end, we tried using VEX and small FRC robots to get everyone hands-on experience as early as we possibly could.

Despite being a Student Run, Student Built team, many of these changes were led by one of our relatively-new mentors. It wasn’t feasible for our students to navigate the political challenges associated with these changes and give the time to train our rookies while also improving our own robot technology. Also, it is impossible to determine how much of our retention success during this off-season is due to our training efforts, our cultural efforts, and other factors.

What Did We Do Before?

Before the VEX and Minibots training program, we started off with an introduction period to FRC. During this time, people learned about what FRC was and the different sub-teams, and each sub-team created activities to teach the basics. Then, after CalGames (the off-season tournament we participated in), we let people express interest in a sub-team. There were several problems with this approach. First off, it is hard to fill one work session (6-8 hours) with one sub-team. With several sub-teams, including programming, there is essentially the 30-minutes of training and the 20+ hours training option. We had a hard time teaching people how robot code works and especially having people write code, without going into many of the annoyances of programming such as:

  • Syntax nuances
  • Variable typing
  • Scope

We knew that going through these topics would be boring to many students, and it doesn’t make sense to get everyone on the team trained in the nuances of Java. However, if we didn’t have them actually writing code, it was hard to find a way to fill the work session, which made the new people be bored. Almost every subteam had the exact same issue. CAD was one of the worst, since the learning curve is so steep for it. The training experience for everyone ended up being a disaster, and we decided that it was worth trying to figure out an alternative.

Long-Term Impact of Our Old Training System

The training system that we used was very bad for team longevity. We usually lost about 25% before Build Season and another 25% during the season. We talked to many of our team members who left, and there were some common threads for why they left:

  • Participants did not have fun during off-season training
  • Participants did not know enough to help contribute to the robot in their rookie season
  • Participants felt that some (non-safety-related) team policies, such as our mandatory team t-shirt policy to all work-sessions, were too extreme
  • Participants often feared the enforcers of the policy above, to the point that they would rather not show up than to show up in an improper t-shirt or in violation of another policy

These complains fall into two categories: improper training and improper culture. In addition to these complaints, our training simply wasn’t being effective for anybody but the most dedicated to end up in a role where they could contribute significantly during Build Season. As a result of our training failures, we frequently had not enough people working and too many people sitting around.


Why VEX?

We had the idea to use VEX to train rookies because a couple of students and mentors (myself included) have had experience with it and our school has several kits available. VEX is a much easier way to get started with robotics because everything is simpler. You don’t have to get students immediately shop trained because the parts are pre-drilled, wires are pre-made, and the software is simpler. This means that it was significantly easier for rookies to get hands-on experience early in the process, given that they could build and then learn how to improve.

The ProtoBot Project

For their VEX project, students were given instructions to build a ProtoBot. These instructions are available from several different locations. They also had mentors ready to help, but the process was largely done by the rookies. Once they finished their robots, they had the opportunity to drive it around using code that comes standard with the VEX Cortex. By starting so simply, they got to drive their own robot very quickly.

A ProtoBot (image by VEX Robotics)
A ProtoBot (image by VEX Robotics)

We chose to have them build a ProtoBot, because it has all of the features of an FRC robot but in its simplest form. There is a drivetrain, intake/outtake, and vertical motion mechanism, but it is much smaller and easier to build than one would be in FRC.


The instructions make it easy to put stuff together, and the Cortex has a built in program that lets you run a ProtoBot. However, it can be very helpful for your students to write their own version of the code to get hands-on programming experience.

For this project, we used RobotC, a language that is very popular in VEX Robotics. You can get it at the link below.

Explaining the Code

Before people actually wrote code, we explained some sample code that achieves the end result. This lets us go through the basics of program flow, conditionals, and everything they would need to know to achieve the end result. The code that we used is very simple, and can be found below. We walked them through the code and periodically asked “why do you think we did this?” or “what does this do?” to see if they were following. This exercise took very little time and proved to be a helpful way for them to learn the concepts.

We also worked on a whiteboard to diagram the flow of what needed to happen, so that the rookies could see the correlation and importance of planning.

A rendering of our code layout
A rendering of our code layout

Letting Them Loose

Before they wrote their own code, I tried writing several versions of the same VEX code to understand what needs to happen and to act as a jumping off point for the project. You can find several examples at the repository below.

After we explained the code, we let the rookies try to write it themselves. We had a programming mentor (who also was new to VEX) help guide the students through the barriers that they encountered. We used RobotC for our language, because it shares similarities with Java, it is supported on the Cortex microcontroller that we used (we did not use V5), and it is free. In addition, I had experience with RobotC, which allowed me to help when needed.

They were allowed to use any resources they wanted except for the example code repo. In addition, they could ask me (or someone else who had done VEX before) for help, but we tried to not give away the answer. Since a big part of programming is finding the answer elsewhere, it was best for us to let the programmers try to find information.

We did help them find information and recommended good websites to aid the process. The main website that they were directed to is Renegade Robotics, the website for a team that I had mentored. The Coach’s Corner section of the website has basically every piece of information you could possibly need for getting started with robotics. They have everything from basic drivetrain code to PID controls, and I often refer to their resources even when writing FRC code.

In addition, they found lots of information by just doing Google searches. Even more than learning the VEX-specific syntax, the exercise of writing their own code proved to be incredibly helpful for learning how to find code snippets and change it for your own situation, a task done frequently in FRC and in industry.

Next Steps

The next step was to design and build a mechanism to manipulate a tennis ball. Once again, mentors were available to offer advice, help find materials, and assist students if requested, but the mechanism was designed and built entirely by rookies. We found that this step required a lot more involvement from mentors, because learning design takes a lot more time than putting together parts based on instructions.


Once the rookies had finished with VEX, it was time for them to build a minibot. Minibots are the minimum viable product of FRC robots. They consist of the smallest possible FRC West Coast drivetrain with two mini-cims driving the wheels. They also have encoders on each side, which allow them to become a programming testbed. The electronics consist of everything required for FRC (Battery, PDP, Radio, etc.) as well as one motor controller for each side (we used Talon SRX motor controllers because the minibots became programming testbeds after they were finished and we use Talon SRX controllers on our robot).

A minibot used for Autonomous development. This minibot was made by rookies and has Talon SRX motor controllers on a MiniCIM
A minibot used for Autonomous development. This minibot was made by rookies and has Talon SRX motor controllers on a MiniCIM

We also made a version of a Minibot with Spark MAX and Neos for programming practice.

These robots have proved to be a huge help for programming practice. They are about half the size of a competition robot in width and length which makes them much easier to carry and bring in a car. They also provide everything that is needed for autonomous or drivetrain development. It was very helpful for our rookies to be engaged in a project that benefits the team, since their work helped the entire team, and this feeling of usefulness is one of the most important aspects for student retention. The rookie projects are also heavily featured at our outreach because it is a less intimidating way for people to learn about FIRST and gives our rookies a sense of pride that their own robot is being shown as the demo bot. Since we started showing the VEX and Minibots, we have received a lot more positive feedback from our community.

Boosting Retention

My team has experienced some major changes since last year. These include, but are not limited, to:

  • Reevaluating training
  • Creating a more relaxed culture
    • Only mandating team t-shirts at competition, not at worksessions
    • Having more worksessions, but not requiring that students be present for all worksessions
    • Recognizing that cell phones can be a helpful tool in robotics and removing our complete ban of them during worksessions
  • Encouraging mentors to be more involved in the training process, which allows rookies to learn better and veterans to improve our robot skills
  • Revisited the role of mentors on our team, encouraging them to take a bigger role in training

Through these changes, we have experienced one of the highest off-season retention rates since our team split several years ago. We also are having rookies better trained going into Build Season thanks to hands-on training and more progress on most sub-teams since veterans are now able to focus on making our team technically better.

There is no panacea for the problems of FRC. There always will be people leaving, or people who aren’t having fun, or people who aren’t willing to put in the time to be prepared to contribute. That being said, if your team looks at the problems with other teams and try to find solutions to the problems, the effects of the problems can be reduced.



This site uses Akismet to reduce spam. Learn how your comment data is processed.