2nd Year FRC Team Mentor here. Planning Kickoff and hoping for a more organized kickoff this year. Last year we wanted to dig in and play with all the new toys and figure out the control system. This year we have a lot of returning members so I would really like to go about it more intelligently. What are some of the routines that other teams go through on the kickoff day in order to make a good start?
Here’s 1058 kickoff day:
After watching the game animation a few times we read the manual. In great detail. Read the manual, read the manual, read the manual. Read it until you all know every rule by heart. Next, our team discusses as a group what strategy we would want to do. We first start by looking for game breaking strategies (which are rare, but you don’t want to miss them), and then we make a list of every possible strategy we could use, and discuss the pros and cons to each strategy. By the end of the day, we have a pretty reasonable list of the strategy we’d like to compete with. Usually designing for the actual robot doesn’t happen until the last hour of the first day or until the second day. I know for a fact that some powerhouse teams spend multiple days just going through the game analysis.
As a second year team, I think it will be important for your team to know your limits and design within them. Know what resources you have and use them well. Good luck with your season!
about half our team attends the local kickoff event, the other half watches it from our build space on the live stream. Once the stream is over, the half at the build space gets everything as ready as they can (including lunch!). That half will then try to finish eating just as the half with the kit of parts gets back to the build space. At that point, they trade places - the other half eats, while the half that is done goes through and sorts/inventories the kit of parts.
Then we go over the game rules as a group, maybe play the game animation a few times as well. Once we think we know how the game is played, we do our best to set up a quick “field”, and “play” it with students as robots. Do that until we think we know all of the strategies for playing. Then come back and talk about the strategies we see as possible. That’s pretty much it for kickoff day.
The next Monday we have our yearly fundraiser at a local restaurant (which includes us eating there for our meeting!), and we do more of the same. Talk strategy, and start talking design. We try to come up with 3-5 mechanisms we want to prototype that week. The rest of the week is spent prototyping and building the drive train. We ask the captains to collect the team decision for the overall design of the robot before our meeting the Saturday after kickoff.
Make sure you have a group of people to immediately start working on designing/building mock-up field elements. This is oft-overlooked, and absolutely essential to success. Also be sure to set aside a few people to do inventory with the KOP. Losing parts is no fun.
You should start with brainstorming - your goal for kickoff weekend should be to identify the directions you’re going to be heading in during the subsequent week or so of rough prototyping. Try to reign in the scope of the brainstorming. Keep the design process in mind - you cannot design anything until you have design constraints set, so the first talks should always be about strategy, not about robot design. Figure out how to play the game effectively, and then design around the strategy you decide on; you should be thinking about which tasks will be easier/harder to design for, but specific designs should wait.
Of course, in order to talk strategy, the first thing you need to do is read the rules. Front to back. Everyone on the team must do this before participating in the strategy discussion.
Well, as I don’t know the exact nature of your kickoff venue, I’ll just say what we do.
So, on kickoff, we have one person go to Marquette to pickup the tote(s) while the rest of us host a kickoff/game video watching event in town. So, watch the webcast, find out the game, and begin hashing out strategies, designs, mental prototyping. I guess we can get away with this since the mentors (and at least some students) have a very solid idea of how to use our stuff, that we dive into strategy and not putting together an electronics board, etc.
Also, like Jay, we (well, at least I do) make sure to read the manual, find what changed from last year, gather dimensions, scoring rules, all that.
Assign one or two people to inventory the KOP.
Download the manual before kickoff so you don’t lose time waiting for overcrowded servers.
Read the rules
review the game. define what makes the most points. how to play defense.
decide what features your robot needs to play the game.
Read the rules.
learn how to play the game.
Oh I forgot pizza
You will have a mix of student experiences so, one of the best ways to review the rules is to have a contest to see who can calculate the highest possible score in the game.
Have each student, if possible (depends on access to a game manual, which may be available on their smartphones almost immediately), spend 15 minutes determining the highest score possible. Loop the video on mute.
(Mentors should do this too, but refrain from excessively guiding students.)
Then put them into groups of two to polish their results for 15 - 20 minutes.
Then groups of four to compete to see which team comes up with the most plausible high score possible.
(Sprinkle with mentors, but avoid being dominant.)
Winners get to eat lunch first or a hex bug or a hug…
This step may take a long time, so moderate arguments, write down salient points, have the team conclude who did the best work (if possible).
This will get all of the students cogitating on the types of scoring and their relative values (autonomous game play, end game), as well as rules and limitations.
Repeat the process for designing how to manipulate the game piece. You may want to mix experienced with rookies for this.
Then, inventory the KOP as a whole team, piece by piece.
This is important because all team members need to familiarize themselves with the components that FIRST supplied us with.
Close the day with two or three lists of Strategies, Design, and …
Send students out with a homework assignment to rank the lists.
I personally believe that letting the game idea “marinate” overnight can improve the depth of the game understanding and make for a better Sunday when the design begins.
Saturday-Watch kickoff at local kickoff. Then everybody goes home and reads the rules. Occasionally, a few of the kids (drive team and captains) meet later in the night at the school, inventory the KoP, and do a little shop prep. The programmer (we only have one) takes the laptop home and sets up the control system.
Sunday-Everybody is now a “rules expert” and has memorized all the rules. This makes brainstorming 10x as fast. Instead of having somebody get excited about an idea (let’s dump basketballs into the top goal!), waste time arguing with somebody else (no, you can’t dump the balls… yes, you can, show me the rule!), then discover the ideas is invalid (see, I told you the robot couldn’t be that tall), all ideas that are considered all legal. During morning, ONLY STRATEGY is discussed, no design. Then, once it becomes afternoon, basic designs start happening. Quickly decided are the drive base and a few possible layouts. No set design is locked in, but instead the separate design teams prepare for prototyping, and the drivebase team starts to finalize gear ratios by the end of the night. At the end, many desirable feature lists are made, but we tend to want to do a few very simple mechanisms (can be made with hand tools), and one pretty complex one (CNC stuff needed).
Monday-First real day of build. Team splits into three. The people who want to work on the real complicated stuff get to build the field models. We also use the field drawings provided by FIRST as a comical example of how not to dimension parts. The drivebase team assembles the kitbot and revives a previous robot for prototyping. Finally, the prototyping team puts together prototypes. We’re fans of rapid prototyping, and we find that spending 30 minutes before making any parts to think of a design really helps. This let us have a working 775 shooter on the first day of build season that could shoot form the front and back of the pyramid. The programmer goes home with the laptop and drafts drive code as well as the rest of the robot code.
Our routine is similar to those above. This year we are trying something slightly different:
Watch kickoff and animations. Watch animations several times, and any supplemental videos. Have lunch.
1 person to inventory KoP
Several people to mock up some field elements (or at least start on it)
A few people to print out and read the manual
The rest play the game, with humans standing in as robots. This is the key part of the day, we do this for 2+ hours. By doing this, we get to understand:
> Capabilities a robot needs to succeed at the game
> Issues with the game that may not be obvious
> Best (and worst) scoring opportunities
> Field issues that may be strategic
Normally, we would quit at that point, read the rules on Sunday, and return Monday to brainstorm Strategies (and rank them), and once these are set we determine Capabilities to implement those Strategies (this may take 2 days). The next days proceed to Mechanisms to get the Capabilities, then prototypes, proofs of concept, and after a week, our design review (last step before committing to a design)
This year, after the Human Robot game, we decided to split into 6 groups, spend an hour ‘designing’ robots, then each group presents their idea in 10 minutes. Then we go home, and follow the outline above.
The purpose of the ‘blitz’ design exercise is to ‘get it out of our system’ (everyone wants to jump to design, right?) and maybe cross-seed the design with some good ideas. It’s fun, too. And it helps folks understand the need to be succinct in presenting ideas (and (later) keeping our regular progress reviews to under an hour…)
Year 2 is often harder for teams, so be sure to really focus on simple robots, that are very durable, and easily repaired. Don’t over-reach, and instead focus on letting your drivers practice a real lot. Excellent drivers can compensate mightily for a mid-level robot.
Kickoff for 195:
First, we go to a local business who provides a conference room for our entire team to watch the webcast. Not only do we enjoy watching as a group, it helps to get brainstorming done right away. It is encouraged to bring a notepad and a pen here.
After this we go to our build space which is split up into many rooms. We use this to our advantage. We divide into smaller brainstorming groups to develop what we believe a “good” robot should do. We encourage these teams to stay realistic. We find it very important to incorporate students of every grade into each group. After awhile brainstorming in small groups, each group presents their solution to the rest of the team. We then decide as an entire team what we feel as a team is the best option strategy wise.
It is important to follow some brainstorming “rules” for kickoff day:
-There is never a bad idea.
-Write every idea down.
-Make sketches when possible. Even if the are not very detailed, any sort of visual representation can help.
-Include everybody. You never know who could come up with the next choke-hold strategy.
As Stated above, it is also important to inventory the Kit and look and hold at what you are given. Another necessity of kickoff day is the rule book. We have 2-3 students who are dedicated to knowing the rule, keeping up with updates, answering questions for team members, and submitting questions if they arise.
The most important thing to remember, through the stress of Kickoff, it is intended to be fun, so stay positive!
This is a big thing in brainstorming/design discussions in general, and is one of the things you should strive to promote as a mentor. It’s very easy for discussions to be “held captive,” so to speak, by a handful of very vocal members. This is bad practice - it makes it easier to fall victim to groupthink and harder to see viable alternatives. Making sure that the more reserved people speak their minds is difficult, but will have far better results.
It’s been mentioned before, but bears repeating: read the manual. Lots.
Here’s how Team 2220’s kickoff weekend will go (we are doing this a little bit different this year, though):
Saturday: Half the team goes to the University of Minnesota kickoff event to pickup and help distribute the KOP to other teams. The other half stays back at our home high school and watches kickoff there. After distribution is done, the UMN people inventory our kit quickly and then come back to our high school to start brainstorming. While they’re on their way back, the people at base are busy reading through the manual and watching the game animation over and over to get a feel for the game and the important aspects of it. Some of our students are speedreading the manual through to get a feel for the major rules, which are compiled to a one page document that we can share with everybody else.
After everyone is back at the school and fed, we split into small groups of mixed subteams. Our team is very large (around 70 students and 30 mentors), so we need to split up in order to gather strategy feedback most efficiently. The subteams do a few major things: they discuss and develop a position as a whole on what the most effective game actions will be in the game, specifically using math and expected values to try to get ballpark figures of how efficient actions will be, as well as breaking these actions into groups of complementary actions.
We cut these groups off around 6 to send everybody home to sleep on their ideas-- as well as let everyone read the manual through and have some of our students develop a “scoring spreadsheet” to let us play with robot scores-- basically this lets us see how effective certain strategies will be at different levels of efficiency.
Sunday: Everyone comes back to their small groups. They consolidate all of their ideas into a coherent game strategy of what the robot will do during auto, tele, and the endgame, as well as sorting out all their supports for that strategy. After that’s been squared away, the leads for each of these groups convene to argue out the strategy. They meet without the entire team to allow the rest of the team to focus on planning prototypes, watching Ri3D/BB, and otherwise planning out essential tasks for the build season. The leadership group basically spends the rest of Sunday hashing out the strategy for the robot, as well as into Monday if necessary. After we have a strategy, an even smaller group of the captains and strategy leads meets to determine tests for whether a given design meets specifications. These tests, like the strategy document, are prioritized. Team members go home and finish any homework they have to do for Monday.
Monday: As before mentioned, Strategy meets to determine tests, and necessary continuation of the strategy discussion happens. No meeting for regular team members.
Tuesday: Presented design requirements for each subteam and the whole robot. We begin with brainstorming all possible mechanisms to achieve these goals. We also meet with one of our sponsors, Skyline Exhibits, to run our strategy and game plan by them.
If our schedule seems fairly intense on just coming up with game strategy, that’s because it is. It’s important to make use of those first few days when everyone is super invested and all the ideas are flowing to channel into strategy creation and debate.
The main thing to take away is to just have a very precise schedule for how those first few days are going to work out-- those first few days are a very good indication of how the rest of the season is going to go.
I drove the team to do this human-robot activity a couple years ago and the kids thought it was silly and a waste of time, and it’s been difficult for me to convince them of its value.
So, this year we are applying some game theory based on our last training session from the fall and figuring out what possible scoring outcomes we can achieve by tackling different combinations of objectives. Come up with reasonable scoring techniques and how they may be defended against, determine how to score points in multiple ways with and try to estimate probability, and finally determining level of value of those scoring objectives to other potential teammates.
Only then will we start talking about mechanism ideas and generating trade studies or materials to purchase for prototyping ideas.
Might be a difference between your kids and the kids I was with, but having that simulated game session can show some “things to consider” that might not be all that obvious just by doing analysis. OTOH, the analysis can come up with some things that playing the game doesn’t have.
If I might make a suggestion… Do the analysis for several strategies, then play a couple of rounds pitting one strategy against another, say 3 rounds with similar strategies. (Simulate, you know, Einstein or something like that. ) Might be a couple of unrealistic assumptions in one or the other strategy. Then go back into analysis for a bit-- “There’s a hole here, which can ruin the strategy. Any ideas to fill it?” And, of course, leave the “how” out of it.
After watching the kickpff we go get a room and sit and talk about how to play the game (no design concepts. We discuss the game). Sunday is when we have each subteam come up with a concept (even the PAW team).
After watching the game a few times, and bring up the manual for the basic rules, we go about spending a few hours coming up with strategy and ideas for what we want the robot to be able to do. Then we come up with a list of ideas to perform the functions of the robot. Then we take a break and chill over the information over lunch :D. After lunch we will try to narrow down the ideas to only two or three, then begin prototyping (mainly so that everyone can be able to express their ideas, and it allows new members to show their creativity and basic machining). By the end of the first day we would like to be able to know what the drive base will look like so we can build it either that day or for the next to begin programming (not waiting until the last three days like we usually do). Hope this helps, and good luck!!!
I remember doing human-simulation of the game with Ike from 33 for Logomotion. We used bagels as tubes (different flavors for different shapes.)
It was both educational (we got an idea of going across the field and how putting tubes/bagels at different angles was trickier than anticipated) AND fun (pretty sure that human-simulation ended up in a stick-fencing match between me and another mentor…).
If you can come up with a way to get students giggling while doing the simulation, and then end with serious analyzing of what was learned, then I think it can be a good team-bonding exercise and game-learning experience.
Does anyone have an actual link showing the FIRST webcast times?
I’ve “heard” it’s from 10:30-11:30, but I can’t find anything confirming that on the FIRST web site.
Based on this thread http://www.chiefdelphi.com/forums/showthread.php?t=122987&highlight=kickoff I would say you’re correct.
100% agreed. We actually give each person present a chance to speak by going in order around the room, perhaps 3-5 times over the course of a few hours. Some kids say “I have nothing to add that hasn’t been said”, OK, but speak now or forever hold your peace…
We do vote on the capabilities, and generally the most votes wins, but for ties and near ties we may shelve that choice for a day and revisit it.
Human Game:** The kids have some rules, they need to think carefully about being a robot and understand the capabilities the “have”. Need to keep it realistic. We use anything for game pieces, including imagination. Most kids are watching, six kids who ‘get it’ are playing as robots. Every game there is an organized debrief.