Hi everyone. I was invited along to an FRC regional across the country to help supervise our robotics students (I am a high school teacher). I knew nothing about robotics prior to the trip but I’m absolutely hooked now! i have so much I want to learn now. However, our team faces some of the following obstacles. If you have any advice on how to fix these, I’m all ears!
I have no experience in robotics, the other two coaches are only good at metalwork and basic programming respectively. What should we be doing to upskill? What skills do you feel a coach needs to have?
We have 15 kids in our team. Only about four or them are competent builders or programmers. How might we structure our team to get the best results? E.g. do we have a build captain, programming captain, drive team captain? How does your team ensure that all students have a sound skill base?
If the kids get into FRC, this means they get a COMPLETELY FREE trip across the country with their friends and they miss school for a week. The government mostly pays for them to go. This obviously means we get kids interested for all the wrong reasons and we get deadweight on our team. How do you get rid of your uncomitted students?
What kind of things does your robotics group do during the off season to prepare? E.g. what do you build?
Firstly, you may want to edit your title and post, replace “coach” with “mentor”. In the context of FRC, a coach is someone (typically a student, but can be a mentor) who is on the drive team and helps communicate between teams on the alliance, keep track of the match timer, and give direction. Mentors are the non-highschoolers.
Read. read. read. Chief Delphi is a good source of information. Review prior challenges, robots, and how the robots are designed. Evaluate what your teams manufacturing abilities are and learn as much as you can within that ability. Overall robot design is very important.
Keep in mind the kids will do a lot of research on their own regarding design, or at least they should.
Our team has a few leads. Our technical leads are “hardware lead”, “Software Lead”, and “Electronics Lead”
Within hardware, we have “subsystem” leads. They work on one specific part of a robot. Typically the hardware lead is responsible for organizing and ensuring that the subsystems work together well. Some examples of what we call subsystems are the drivetrain, the lift, the ball holder, the intake system, and the hatch holder (at least for our robot this year). The subsystem leads are responsible for designing their subsystem, and giving responsiblity to other students to help them create it. They are chosen by the mentors, the hardware lead, and the club president.
Club president is elected on our team, and technical leads are appointed by mentors and the president.
All students aren’t well rounded. Many will only do software, or only hardware. But it helps to have a rudimentary understanding of everything (which they will pick up over time).
We have a check in / check out sheet used throughout the build season. There’s a (not strict) cutoff for students. Show up during the season and be on task, or else you can’t come to worlds. Keep in mind you will need a minimum amount of people in the stands to help scout the teams incase you are in a picking position.
IMO 15 is close to the minimum to comfortably scout, talk to judges, and maintain the robot at world’s.
Sometimes we build drivetrains for practice designing. We try new things, like a hex shaped drivebase, or trying out different wheel configurations.
Drivetrains are the most important part of the robot. Trying out new designs that you’re unsure of during the actual build season is unnecessarily risky for many teams.
For example, the year we switched to a “west coast” drivetrain (cantilevered wheel axles) we had tested it the summer prior.
Welcome to FRC! One thing about ChiefDelphi is there’s a lot of different topics being talked about all the time, and it can be confusing to figure out where to start. Several teams have compiled a bunch of really great resources that are worth a read. I’d suggest the documents here from Team 254, especially for a starting point regarding the robots themselves: https://www.team254.com/resources/.
A look at their handbook could also be helpful regarding your second and third points.
We have four important pre-season activities to train up members and keep a good amount of knowledge in student heads.
Rookie education
Our rookie education program is called Geared Learning and is run by veteran students for the benefit of the rookies. We made a list of “things an ideal rookie knows” and came up with a program to teach those things.Having the veteran students teaching is valuable because it cements knowledge for the returning students, and introduces the new students to the older ones. I don’t have a lot of specific details on Geared Learning, but I can get them if you’d like.
Mock Kickoff
It’s easy to charge into a robot design without thinking things through, and end up building the “wrong” robot. We Run two mock kickoffs per year. One is run by mentors for some of the more dedicated engineering students and student leaders. The second is run by the engineering leaders for the rest of the engineering team. We grab the rulebook to an old game and run through the first 2-3 days of build season with it. This lets us keep a controlled kickoff procedure, and keeps the build leaders from falling into “cargo cult engineering” where they just parrot the procedure off without really understanding the steps.
Mentor-taught workshops
Sometimes we just need to tell things to students. At workshops, we teach students some basics of robotics from physics to wiring to SolidWorks. We ran a 5-day CAD workshop last summer, and 6x 2-hour workshops last fall.
An off-season robot.
There’s no substitute for experience. The best way to learn how to build a robot is to build a robot. Last season we had the veteran students “outline” a robot, and had some newer students do the detailed design work. We built the robot and entered it in an off-season event. Robot here.
A lot of other teams have resources on their websites. In this post a linked a bunch of them.
Re: what does a non-technical person do on the team:
Manage the schedule. By this I mean the big year-long schedule. Make sure that you don’t have too much downtime in your year, but that you’re not overworking the kids. Contrary to popular belief, this is not a 6-12 week program. Good programs are year-round affair.
Manage the team’s resources. My theory of “running a team” is that there are 5 resources you need: Money, equipment (&facilities), people, knowledge (&procedures), time. Take a look at each of those and figure out where you’re falling short. Come up with some concrete steps you can take to remedy that shortcoming. If you tackle one or two a year, you’ll be good in no time.
Edit:
3. Coordinate the “boring” administrative work. Running a robotics team means coordinating food for students, travel arrangement for the team, facilities access, etc. Having someone managing those items will make any team’s path easier.
The Compass Alliance is a site started by FRC 3132 Thunder Down Under (and an assortment of partners) that has a lot of resources.
From the skill-sets you’ve mentioned, it sounds like your mentor group may be weak on electrical. That is a critical area for making the robot work predictably, so that’s probably a good area to study up on. The good news here is that the electrical rules are pretty strict, which means they spell out a lot of the basics, and the FIRST site has a lot of information on how everything hooks together. This thread has some more information and links to other good places. If you want more information or extensive recommendations on best practices, there’s a lot of that around in various threads or you can message me if you like.
Moving on to team structure and motivation, the big idea is to get everybody’s hands in somewhere and let the kids figure out what they’re into. I spend a lot of time encouraging new team members to try things they don’t know how to do yet and working in the “I show you one, I help you do one, you do the next one without me and have me check it when you’re done, then you train the next kid” mode. I also do a bit of traffic-cop work to make sure the experienced kids let the new ones get their hands in. Every kid doesn’t have to learn all the things, but they should have a chance to try it a little and see if they like it. A lot of teams have a minimum amount of productive time required during build and/or preseason to travel with the team. I don’t know if that’s an option for you, but it might help.
My team’s structure is a bit idiosyncratic and varies from year to year based on what students we have, but a fairly common pattern on FIRST teams is to have a captain for build, with mechanical, electrical, and programming subdivisions, and mechanical subdivided further by mechanism. There is frequently a second captain for the “business” side – covering spirit, outreach, marketing, fundraising, photography, and submitted awards.
Off-season, we do a lot of demos for younger kids, we run summer camps, we do outreach work, and we have a lot of training sessions for our newer members where they learn how to do things like disassemble and reassemble gear boxes, rewire an older robot, and upgrade our last competition robot’s mechanisms and/or software for off-season events.
I’ll start off by saying, my team of a similar size doesn’t have a structure of the “x lead” variety. Everybody participates in the design discussion at the beginning of the year. This typically weeds out the “missing school is fun” kids. Well, that combined with our 21 hour/week meeting schedule. We also have a meeting requirement in order to travel.
As for the knowledge base of the mentors, take some online coding classes, study different types of mechanisms, learn about the electrical/pneumatics side of things. And get someone that can keep the team on task (hi Mrs. Lund). My team is lucky enough to have @Christopher149 as a mentor, he has years of experience in FRC and really knows what he’s talking about and he devotes a LOT of time to robotics.
As for off season, look at your team’s weak points and work on those. If it’s fabrication, have them build a simple elevator or ball intake with designs already drawn up (maybe making 118’s Everybot?). If it’s design, look at one of the old games (don’t let them look up bots from that year though) and have them design and build a robot from that year. If it’s coding, design a game with your team members to get them more knowledgeable on programming. My team personally struggles with elevators (specifically of the rope pulled variety) so I want us to perfect the rope system over the summer.
When it comes to new members, I am a firm believer in the FTC “feeder” team. I started out in FTC knowing absolutely nothing about robotics. By the time I got to highschool, I knew my way around the basics. And that was just one year of FTC. We just got our first batch of 3 year FTC freshmen and it was amazing. They all knew about several different mechanisms, strategies and several of them knew some Java to help program the robot. They all come into FRC ready to try new things without the “I don’t know how to do that” mindset. Our main programmer didn’t know a lick of java when he started, he programmed the entire robot (more or less). But get your FRC team members involved as mentors for the FTC kids. Most of our FTC kids are going to join FRC because of us mentors. I probably wouldn’t know much about it if it weren’t for my FTC mentors.
It’s for the kinds of teams who are starting at zero and know next to nothing, but progresses quickly into more advanced topics and contains a lot of reference material. There’s stuff in there just to mess with my students, like 2 pages about CAN frames. It’s not a white paper, and it’s not supposed to be. It’s a pretty shallow overview and is of limited value in the long run, but not every team is made up of prep school elite, and if your team is like mine, just teaching them the basics is going to be an uphill battle. Plus, it’s got pictures and pretty colors.
Personally, I read stuff like 254’s technical binders and use the vast repositories available from the Compass Alliance and teams like 3847, but—and here’s where the haters come out—these guys have been at it for so long and have amassed so much knowledge that they forget what it’s like to be an absolute beginner and have no idea where to start.