With Kickoff quickly approaching, it is worth taking some steps to make sure that your season gets started off on the right foot. The first two days are often the most important of the season, because it sets the path that your team will be on for the rest of the year. This post is from my view as a student as what can be done to make sure that your team gets off to the right foot, as well as an outline of our first couple of days of Build Season.
Create A Plan
Having a well-developed plan for the first two days helps everyone stay on track when it most matters, at the very beginning. We have a play-by-play developed before kickoff of the first two days, with time allotted for each activity.
Our plan is developed during Winter Break, and outlines all of the core aspects of kickoff. You can see our plan under Every Second Counts.
In addition to a plan for kickoff, we create a general season schedule. This schedule contains soft and hard deadlines for project completion, to make sure that everything stays on track. With the removal of a bag day, this plan is more important than ever.
Know Your Sub-team's Role
Every sub-team has a unique impact on the team. For this reason, it can be very helpful to understand what your sub-team needs to do for Kickoff and for Build Season. I am on software, so I am most familiar with what our software team does, and in general we participate in the prototyping process. Last year, we had some people (myself included) break off to work on scouting and figuring our our new priorities since there was no dedicated autonomous period. Some sub-teams may be able to help significantly with kickoff weekend as well, so that should be taken into account.
CAD and Code What You Can
Did you know that you can start CAD and code before build season? If you release it publicly, you can use these resources during Build Season. For this reason, it can be a huge time saver to CAD and program what you know you will need. My team often publishes our off-season projects shortly before Build Season so that other teams can use our code and we can refer to it later on.
Figure Out Who is Going to Get the KOP
Part of Kickoff is obtaining the Kit of Parts. The Kit of Parts is a tote with game elements among other things. Make sure that you have someone who is going to your local KOP event to get the Kit and watch the video. This can be a great opportunity for students to meet other people and get more involved in the team, especially second-year members who may be trying to transition to a more leadership-oriented role.
Every Second Counts
Every second wasted during Kickoff Weekend is a second you won't get back later. Have a carefully-planned schedule to follow. Make sure that there are fun activities to keep team member engaged.
A version of our 2019 schedule is below with commentary.
Have a Leadership Meeting
For my team and many others, Kickoff occurs during Winter Break. This means that our team would not have had a general meeting for about a month (our last work session of the off season was the 7th of December). While our leadership team will meet over Winter break to make a plan, it can be helpful to have a meeting the day of to review the agenda and make sure everyone is clear on roles.
At this meeting, we:
- Make sure people with roles are clear on what their roles are
- Make sure that leadership is ready to help the other team members
- Discuss anything that arose since our previous leadership meeting.
Set A Clear Start Time
It is important for as many people to be at your kickoff work session as possible. For this reason, it tends to be a good idea to set a clearly-defined start time. We found it helpful to not actually plan on activities happening for the first 15 minutes because some people may be late, but it makes people feel obligated to show up on time.
Watch the Live Stream (Optional)
If your team wants to, you can start the year by watching the live stream. The live stream can be found on the FIRST Twitch Channel.
The stream starts at 07:00 Pacific but the game is actually announced at 07:30 Pacific. My team usually doesn't watch the stream between 07:00 and 07:30, and instead has our leadership team meet. We have our general work session later so the majority of our team doesn't see the game on the live stream.
Watch the Game Animation (at least twice)
The game animation is a great way to quickly convey the basics of the game. Not only does it condense the most important aspects into a couple of minutes, but the video format is often a good way to get people engaged.
Your team should watch the game animation at least twice so that you can look for:
- Round 1: High level objectives (scoring)
- Round 2: Field Layout and important criteria
- Round 3: Anything else that you may have missed from the first two rounds
We have a general rule that you have watched the game animation enough when you can't stand the background music any more. Normally we watch two to three times before the next step, which is reviewing the rules.
Read the Rules
Everyone on your team should read the rules on kickoff. People can't help in any significant manner if they don't know what the rules and constraints are. We have one of our leadership members review the entire game manual in a group setting with the students, so that everyone can be clear on the rules.
We encourage students to bring a tablet so that they can download the PDF onto a bigger screen, which can be very helpful for such long PDFs. Our students can also use their phones or one of the team laptops.
Reading the rules can take a very long time. We usually dedicate around three hours, to make sure that there is enough time before lunch. Often it takes less but this is one of the most important parts of Kickoff Weekend. To save time, we tend to skim over sections that tend to be the same year-over-year, but teams (especially newer teams) should probably review the entire rule set.
Another good thing to do is to have students take the 1678 (Citrus Circuits - Davis, CA) rules quiz. They often cover the most important parts and it can be valuable to make sure people are paying attention.
Students, especially leadership students, should not take lunch off. The lunch period on the first day can be a valuable time to compile rules into a "most important rules" list and look at potential Q and A questions. For non-leadership students, lunch on kickoff can be a good bonding time, so having people sit together can be very helpful.
The other thing that can be helpful at lunch is discussions of very unconventional game concepts. For example, in 2019 the software team started discussing how our pre-robot Build Season plan would change because of the lack of a true autonomous period.
After lunch, we split everyone into two groups. Then we discuss offense opportunities and Q&A questions that we have. Any important things that come up in either of the group are then brought up in front of the whole team in a whole-team debrief.
After our group discussion, we break students in to two different groups. They do one activity for half and hour and then switch to the other one.
For one station, we make a spreadsheet of different scoring elements, relative difficulty, value, and expected cycle times. This helps us make more insightful planning decisions for our robot.
For the other station, we have people act out a simulated match. We use trash cans to act as scoring locations and set up a "field" in an open area. Students then run around and "intake" from intake stations (mentors/leadership on the side of the field) and then "score" in the trash cans. We do this for three reasons.
The first reason why we do this is to get a better understanding of cycle times. While we usually are more optimistic during human robot, it helps conceptualize what a match cycle will look like.
The second is that it gives us a better understanding of match play. The students on the field are very quick to figure out what gives them an advantage over the other team and vice-versa. We play multiple rounds to help this.
The third reason, and perhaps the most important, is that it helps us understand what holes exist in our understanding of the game. We frequently come across a situation that we are not sure if it would be legal. When that happens, we write it down and look for an answer in the rules later. If it is not answerable with the current rules, we add it to our list of potential Q&A questions.
Whole Team Discussion
After doing activities, we go back to a whole-team meeting. At this meeting we look at the spreadsheet made earlier and start a strategy list. We create a list of our potential strategy options. After that we split into needs, wants, and likes, which we do not finalize until Sunday.
While many people start combining functionality with strategy, it is important to avoid this. It is important to first establish what needs to be done rather than how it will be done, so that the team has an open mind during prototyping. Students and mentors are encouraged to politely remind each other if someone starts talking about the how rather than the what.
While our team rarely assigns homework, we do ask all students to read over the rules again at home. Many students choose to not do this, but it is very helpful for the students that do and it establishes early on who is more dedicated to the team.
We start by reviewing our strategy and giving team members the opportunity to suggest new strategies based off of re-reading the rules and browsing Chief Delphi.
We then have a strategy freeze, which is when our team decides on a high-level strategy which will drive the rest of the season.
Robot Functions Discussion
After we have a strategy, we break up into teams come up with the necessary robot tasks. These tasks are high-level actions that a robot must be able to do. As with the strategy, we try to avoid talking about the how at this stage, because mechanism ideas come later.
Functions are listed on a whiteboard for everyone to view.
Identify Potential Mechanisms
After identifying functions, everyone splits back into the same teams and come up with mechanism ideas to achieve the tasks. We emphasize looking at past games and robots, since many of the engineering problems have already been figured out with them, though we also try to come up with some more creative solutions to the problems at hand.
Each team is required to come up with at least 3 possibilities for each function, so that there are a lot of options to choose from and to encourage creative thinking. After lunch, teams give a short presentation on their ideas to the whole team, and everything is tracked down.
Create a List of Prototypes
After all of our mechanisms are put into a list, we rank them based on factors including cost and complexity among others. We also identify which ones require prototyping and which we are certain will be easy to do without prototyping (we usually don't need to prototype a West Coast Drivetrain). We also define what each prototype needs to tell us. We don't try to ask super generic questions, like "Does this work?," but rather more specific questions that can have a quantitative answer ("How far does this double flywheel shoot?"). Prototypes are also classified into Yes and No categories. We do not allow for maybes because they can distract from more core prototypes. In addition, we try to get it down to three subsystems that need to be evaluated early on, since that is the most that we can realistically do with our small team. If teams finish, then they may move onto another prototype later or begin production work.
Once our list is established for what will be prototyped, we split the team into the required number of groups. We try to have a wide variety of people (rookies, veterans, veterans) as well as subteams represented in the groups, so that few things are overlooked.
Teams start by drawing out their designs on paper. This helps conceptualize what they want to do, and identify any immediate problems. They then present their ideas to other prototyping teams and receive feedback. After that, they can start with physical prototypes.
One problem that we have frequently had is that more experienced team members go straight to CAD for conceptualization, ignoring the crayon-cad phase. There are two problems with jumping straight to CAD. First, when people start conceptualizing in CAD, they quickly forget about the high-level objective and instead worry about the details. While details matter, at the initial phase it is more important to prove if the concept works rather than if the details work. Secondly, it very quickly excludes rookie members. I remember that in my freshman year, I was working on a climb assist mechanism. The experienced person on the prototyping group had started trying to figure out the exact geometry of how robot loading would work in CAD within an hour of the group creation. I was left in the corner wondering what to do, because I had very little CAD experience, and it created a rough start to my season. It turned out that we didn't even need CAD to figure out what the person tried to figure out in CAD, because I figured out in about 10 minutes that it wouldn't work with fairly simple 7th grade math. For this reason, it would've been a lot more efficient and less isolating if we had started with pen and paper rather than jumping straight to CAD.
Last year we tried to have greater input from more experienced students early on by having people who were very knowledgeable about certain aspects of robots helping all of the groups to make sure that the prototypes would not be completely unfeasible down the line. In my experience, the problems about designing for controlability start at a very early stage, since control is not super applicable to prototypes. However, even asking "where would you put an encoder" or "does this subsystem need any limit switches" helps start the process of thinking about controls early on.
Appendix: Do Your Research
Doing research is one of the best ways to learn about the game and research past robots for mechanism ideas. I have compiled a list of some helpful resources for finding ideas and research
Team Websites (Robot Mechanisms)
FRC games tend to repeat common concepts. That means you can find what worked well in past years and do a similar mechanisms for the current year. For example, my team has photos from most of our robots since 1995.
You can also see the robots from Team 254 here since 1999.
Chief Delphi often has discussions about robot ideas and game rules very early on in the season.
The FRC Discord is an instant messaging community for FRC. There often are discussions about the season early on in the various channels.