The Robot Game is what most people think of when they think of FIRST LEGO League. The good news about coaching the robot game is that “the kids do the work.” There is plenty for a coach to help with, though!
Generally, the team will have 10 minutes with the Robot Design judges, in a room with a robot game table. Some regions do not provide a robot game table. The judges will ask the team to show them some missions that they have solved, and ask questions about their strategy for the robot game and how their programs work. Many regions require a “Robot Design Executive Summary” (RDES) - our team typically makes this on paper to leave with the judges, and sometimes brings in a poster sized version to refer to during their short 4 minute presentation.
After seeing 10+ robots over the course of a morning, it can get difficult for judges to remember details about each team, even though they are taking notes! Having a very short (4 minute is the general RDES time limit) presentation that is memorable, and a RDES document to leave behind can help. Consider putting a photo of the team in the shirts they’ll wear at the competition on the sheet you leave with the judges. Tell the judges what you named the robot and why, or pick another short, but memorable story to tell. Be sure that every team member talks to the judges – you don’t want the discussion to be dominated by just one or two team members.
Use the rubric that is provided by FIRST each year to help design your presentation and to let your team know what the judges want to hear about. The judges can’t score you on software if they don’t have anything to see, so bring a computer with the software on it to show them, or print a program or two to discuss.
Your team will have three chances to run their robot at the game table. They have 2 minutes and 30 seconds to score as many points as they can. There will also be practice tables at the tournament that your team can sign up for. It is always a goal of mine for there to be no programming at the tournament, but the kids usually find something they want to tune up.
At the official game table, the kids will have a minute or so to prepare for their run to start. After their run, the referee will score the table, making notes on a score sheet of which missions were done and which were not, and touch or junk penalties if any. The referee will then share this sheet with a team member, walking them through what they have marked. In the unlikely event that your team disagrees with something that the referee has marked, now is the only time they have to make their case. They should know the rules well enough to explain to the referee without you helping (and you shouldn’t help, except perhaps to hand a team member a copy of the rules). Once a member from your team signs the score sheet, it becomes official and no changes can be made. If your team is unsure if a strategy they are using is allowed or not, they can ask the referees in the morning before the robot game even starts and find out.
If something at the table happens to be set up incorrectly, tournament officials are happy to fix it once you show them in the rules or mission descriptions what the correct setup is. Having the kids inspect the official game tables early in the day is a good idea, as well as looking them over carefully as they prepare for each run. Any time your team needs to communicate with judges or referees, it is best if a team member handles it. It’s good practice for them!
This is the most important part of coaching the robot game. The kids will learn the best by struggling with and solving problems themselves. Try to ask questions that help them define exactly what the problem is and ask the kids how they think they might solve it, rather than jumping in with a solution that you have seen. This is hard sometimes! There is plenty of room for direct instruction – you can give lessons (or find them online online) about how sensors work, line following, switches and loops in the program, etc. The role of a coach is to give kids tools and then push them to find solutions themselves.
It’s easiest for the kids to work in small groups (2-3) and divide up tasks. (We mix the groups for other team tasks so everyone works with everyone else.) On our team that usually means that each set will be working on a different mission run from base, both the programming and attachments for that mission. Sometimes kids will trade missions, though – it’s fluid. It is wonderful if you can have an adult mentor for each small group on the team, but not completely necessary. For our team, the adults do quite a bit of keeping-the-kids-on-task. This is also a good opportunity to support the kids by reminding them of the core values while they are making hard decisions and negotiating.
Build a basic rover. There are several examples on EV3Lessons Robot Design.. It’s perfectly acceptable to start with a basic build and modify with attachments / bumpers as needed for competition.
Next, go through the programming lessons on EV3Lessons.com – they are fantastic.
Go through as many lessons as you can, but soon the team will want to start working on the challenges on the board. That’s great! They can return to EV3Lessons.com when they find skills they wish they had to solve the problems they encounter.
Challenge documents are essential. Many teams have a “rules kid” with the job of knowing them inside and out. Print at least one copy of the challenge documents and have them in a binder where the team can refer to them easily. Mark important parts to refer to at an event if they need to. Be sure to keep up with the robot game updates that are released through the season. Some things change every year. Which walls will the mat be pushed against? How tall is base? Is there a junk penalty? How big is the touch penalty? Know the rules and refer to them often.
Evaluate the board – where are the areas with least clearance that you will want to drive through? Put some constraints on the dimensions of your robot. What kinds of movement will you need from attachments (lifting, pulling, pushing), will your robot be facing the model directly or will the side (or back) of the robot be towards the model? What lines on the board can you use for navigation and/or squaring with light sensors? What other sensors will help you the most? (the limit is usually 4, check the rules every year!) What is another way you can accomplish that task? And another? Come up with enough crazy ideas and one of them may turn out to be brilliant.
Consider starting positions – the more you can rely on sensors, the less your starting position will matter, but usually you’ll need a very consistent starting location for your robot. You only have 2 minutes and 30 seconds for a robot run and time spent lining the robot up and changing attachments eats away at that quickly. Using a jig can help (but remember variation in the tables will change where your jig is exactly located by a few millimeters). Remember that the defined position of the mat can change year to year (centered E/W, docked N or S for the past couple years). Make sure more than one kid on the team knows where the robot starts for each mission!
When the team (finally!) solves a mission once, we say they have had “an accident.” When that success is repeated, we call it “a coincidence.” When the mission has worked three times in a row, we start to think that we may have a solution.
Decide what order your missions should be done in. Consider the points each mission will score, but also how difficult the line up is and how difficult attachments are to add or remove – whatever is the most complicated is a good candidate for the first mission, because you have time at the table before the run starts to set it up.
There can only be two kids at the robot table at a time, but they can swap out. Who will be holding what? Do you have attachments that need to be changed? My team regularly takes over 5 minutes the first time they try running all the missions together, but with practice it comes down to under 2:30. Practice!
Kids will often build “art” pieces with the LEGO bricks – this tinkering is actually good exploration in my opinion! It’s important to regularly disassemble them, though, to keep pieces in stock for building the main robot. Have a solid method for distinguishing art pieces from attachments that are still a work-in-progress, or you may find something important has been disassembled! (A “Do Not Take Apart” shelf or bin should work, or a “For disassembly” bin.)
Troubleshooting is a huge part of the robot game! Whenever someone was having trouble on our team, we’d call out “All eyes on the robot” and get everyone watching – you never know who will see something that helps solve your problem. Your team will develop their own style and methods, but here are some ideas to start with:
What changed last? Is this likely to be a software problem or a hardware problem?
Inspect the program carefully - it can be easy to enter “12” under motor rotations instead of “1.2” and that makes the program look very different than you expect!
Make sure you have the most recent program downloaded and are not using the “recently run” menu on the robot – that can sometimes throw you off (especially if you’ve recently changed the name of the program!).
Check all the wiring and make sure the connections are tight. If a sensor is misbehaving, looking to see if it’s working in “port view.”
Insert “wait” blocks or even a sound block just before or after the part of the program suspected of having a problem. Warning: Once my team used this method to make sure a sensor was seeing a line and stopping on it correctly to follow that line. They left the sound block in for a few weeks. When they went to take it out, the robot no longer would stop and find the line correctly! They determined that in the time the sound was playing, the robot had “settled” after it’s stop. Inserting a wait block for the same amount of time that the sound had played restored the expected behavior.
Disconnect large chunks of the program “off the beam” to see earlier parts of the program run alone and then add blocks back one by one if the behavior goes back to what we expect.
Battery level can cause changes in behavior. Keep the robot on a charger when it’s not in use, and if you see strange behavior, make sure you have a full battery.
Resources in your area: Some areas have coach training sessions and / or scrimmages for teams. Be sure to connect with your local operational partner to find out what is available in your area. A more experienced team might also be willing to mentor your team.
Over the season:
maintain an engineering notebook – the story of our robot
think about strategy – how does the game board shape our solutions?
solve robot game missions
develop a short presentation with the “story of our robot” for the robot design judges
Take to event:
robot design executive summary to leave with judges
code to share (printed or on computer)
short presentation – the story of our robot
robot / attachments / charger / download cable / backup robot / battery
computer / power supply (have mission model build instructions on computer)
extra LEGO pieces
backup of programs
power strip / extension cord
printed Challenge document
photos of robot / attachments in case of damage