Advice for Younger Teams

Seeing 148 and 254 win Worlds for their 3rd and 4th times respectively serves as a reminder that the greatest teams in FRC have been performing at a high level for many many years. Their success extends beyond their robots, to their well-run organizations. For younger teams without the same experiences, what strategies or practices would the more established teams recommend? What aspects of your organizations do you believe are most integral to your success and could be emulated by others? Topics such as season planning, event preparation, and offseason training would be especially helpful. I encourage anyone and everyone to post their advice, for both my team and the FRC community. Thanks in advance!

I just posted two link’s the top one is the Compass Alliance its a group of teams that work together to help other teams take a look at the site.

The Second is JVN’s blog he is a mentor on team 148 and he blogs through build season and more giving an in-depth look on 148 its truly a good read and I enjoy every new post that comes out.

I have been a mechanical engineer for over 30 years. Gems 4362, asked to build in my Shop. I was delighted, as it allowed me to give back to the community. It has actually been a whole more than that… So I look at things from a mechanical slant.

While there is help available through the Robotic Community, a six week build schedule means you have to hit the ground running to complete the intended design. And a narrow weight budget doesn’t help to speed up the process.

I believe that a Team’s level of success has about a 30% luck component and the balance is related to the Team’s Mentor skill base. I am not implying anything about the robot being a factory built or student built machine. I am suggesting that the Mentor Team guilds and facilitates the robot design path and timings. That which you really understand best, you tend to design faster and more accurately.

The nuance of the Game develops through the competition season. The fit of the robot ultimately to the nuances of the game are from the Mentor base’s direct design path and the secondary robot abilities that are sometimes not directly intended. They are instead part of the general, “yes and it can handle that stuff too if needed.”

Unfortunately, budget is a huge potential limiting factor to the level of components used in the robot. And that ultimately also can determine the robot’s range of ability. Just my two cents…

Here are a few key things that I’ve learned in my 4 years of being involved with FRC.

Overpower rather than underpower
What I mean by this is rather than underpowering mechanisms you should overpower them since it’s always easier limit motor power so it isn’t too powerful than it is to not have the ability to have enough power in the first place.

The 2x intake rule
One rule that we like to follow is too have our intake mechanism (If wheel, conveyor, or other active system) run at at least twice the max speed of the drivetrain. You do not want to be that team thats on the field chasing a game piece around since that looks really bad to the scouts.

Iterate designs
All to often you see teams who have very lackluster mechanisms that when you talk to them turn out to be their first unchanged version despite them being at their second or even third event. If something sucks don’t be afraid to change it. Yes it can be hard to change a mainframe part like the robot frame or an elevator but even that has been done when people see that those suck each year. Changing an intake however is much easier to justify since its often less than a couple hours work to swap it out at the next comp or unbag time you have. This iteration also doesn’t have to start after build season has ended. By the end of build season we were already on our version 2 or 3 intake and 148 was on their 6th or something (It’s in JVN’s blog) and i’m sure that every other good team built several iterations by the end of build season. By the end of comp season we were on our 5th or 6th version so also don’t be afraid to make changes mid season, be cautious about it though.

Simple drivetrain
Keep your drivetrain as simple as possible whether than means using a basic WCD or using the KOP chassis a simple drivetrain that just works is the first step to having a robot that can play the game well.

Know your abilities
You often times see teams who think that they can do a lot more than they really can and thus build a robot to do the hardest task but in the end end up screwing themselves. I would rather pool a limited amount of resources into the bot doing 1 or two things very well rather than doing all 5 things somewhat well. This year for example would have been rather than making a bot than can do scale make a bot that is just capable of doing the switch and vault and taylor the whole robot to doing that.

Don’t Lie
WHen in the pits and people come up to you can to ask about your robot or come up to you for a drivers meeting before the next match don’t lie about what you can do. For autos tell them what you have done, what’s been tested, what its success rate has been, and what hasn’t been tested. For describing teleop tell them what you’ve done all comp and what you;re best at and what you’re not so good at. If you’re honest than everyone is better off and the alliance canmake a better plan.

Ask around
At the comp don’t be afraid to go up to teams that are doing good and ask all about their robot, teams love talking about their robots and often times listening to them can teach you about design techniques you didn’t know about or teach about parts you didn’t know about. This kinda goes back to the iterate thing also, look at what teams have done well and try to apply that into you;re own designs.

Go to as many offseason events as possible. On top of this try not to have the most experienced people on the team touch the robot at all to give the new people on your team a chance to see what the pit experience is like and to get hands on with the robot in a competition environment.

Thanks to everyone who has replied so far! Does anyone have advice on how to train new members and ensure the team succeeds after senior members graduate? Or recommendations for developing a timeline for the build season?

We just literally just went through this real issue, it so easy to rely on the best driver (you know will bring it) and the best programmers and best engineers too, until they age out. Very hard to make the call to move them out, almost impossible in fact . During build …Its a thing you don’t worry about , as you have a robot to build and hopefully give other teams a run each season. There is another season hill to climb.

6 weeks is not a lot of time to think of continuity, although its always in the back of our mentor minds.

For us when forced to, we just tried to “get younger” and to promote freshman/sophomores to key leadership roles in year 5, went young in key roles. We accepted the fact ,we may need to give them some no practice and in game seasoning under fire as we transition everyone original out . In the past we sort of relied on the original non -aged out students. Eventually hit a performance wall …needed new. Our new eventually driver(s) literally drove the robot for the first time in our first competition of 2018. Made mistakes, then got better as they went . Pretty good for never driving anything even cars.

All the sudden it was a total churn and decisions to be made. So my advice is look for young even freshman strong leaders and simply give them all they can handle and let them learn and make mistakes under fire. They will surprise you if you let them and will certainly help to reinvent the team. This is good, new perspectives on everything is good. Still made elims in our second 2018 competition (missed in our first) , so there’s that. Excited for next year based on this season’s finish with the new crew of students in charge. We enjoy the competition each season. We also enjoy the past and future. Always something new.

The Compass Alliancehas a lot of different programs for helping teams of all levels, if you have any questions feel free to message me.

Also I would highly recommend watching these two videos:

  1. Effective FIRST Strategies by Karthik from 1114

  2. Strategic Design by Mike Corsetto from 1678

Jim Zondag has a timeline in this presentation"Advice for New Teams"]( It details some of the activities we do year-round.

Preparation for the next build season can start now** - recruit new members, make and execute training plans, run fundraisers, stock your shop with items you know you will need, design your team uniform, learn new software, hold team parties and team building activities. Having all of this done before build season will allow you to maximize your time to solve the challenge of building a robot.

The Killer Bees use the VEX platform to train new members. The NewBees build a VEX clawbot from a kit, while more experienced students take on the VEX EDR challenge. To build team leaders, the senior students participate in OCCRA. We try to make learning about robotics fun and different from a classroom.

To pass on knowledge between students, we use “HIVE groups” where the senior students are assigned to a group with less experienced students. It is the seniors responsibility to pass on their knowledge by working with the group. The mentors check in with the groups and provide expertise as needed. At the end of each meeting, the team comes together to discuss the progress towards the goal, with the HIVE groups reporting their successes and challenges to the entire group.

**Our offseason starts on May 1st, 2018. We like to take a day or two to catch up on sleep, homework and family.

Ping us through the Contact Us if you want more details. Be patient - We will be a little busy later this week. :stuck_out_tongue:

Each year have a FULL( ours is 4-6 hours, so bring snacks and drinks) breakdown of your year with your team leadership (don’t invite those that cant take a 4 hour serious talk); what went right, what went wrong, what when OK, what didn’t go at all.
Use that to create a list of things you think you can realistically improve for next year(don’t go over board, if you are rank 50 of 50 dont aim for top 10 or even top half, aim to fix the 2 most common fail points;if you fundraised $5k one year shoot for $7.5K the next, and $11.25K the year after that).
Use that list to help guide your decisions for the next year and keep track of how things went. then at your next end of year meeting grade yourself on how your goals went, and use that to help create your next years list of goals.

As a team make it a point to make some intentional improvement each year.

2706 has been around for 3 years and has benefitted from direct advice and experience from multiple teams as well as the wealth of knowledge that is here on Chief Delphi.

My thoughts:

  1. Spread the load. Spread the word.

Running an FRC team is a huge undertaking and if your team is small, you risk collapsing if/when your key mentors or students graduate or decide to move on. Make sure you are developing a team culture where you are bringing new students in to work with and learn from older students. Try to develop a leadership model where multiple mentors can share the workload and also train up new mentors.

I would say the same for your funding – if your team gets its funding largely from one source, you risk a crisis if that source stops funding you. Work on getting multiple sponsors.

  1. Know your limit. Stay within it.

AKA strategic design, see Karthik’s famous talk. Your goal is to roll into a competition, unbag your robot, and get inspected and ready to play some practice rounds with minimal work. That means on Bag and Tag Day you need to have a finished, functional, working, tested, robot, that can play the game and be good at whatever it is designed to do.

This is a tall order. 6 weeks is not a long time. Develop a team culture that is very honest about your capabilities and embrace them rather than fight against them. What you do not want to do is stretch your team thin trying to build a robot that does everything, but end up not finishing, bringing an incomplete robot to competition, scramble to finish it in the pit, then debug the issues that crop up match after match as you discover the flaws (aka “testing in production”) and watch your ranking plummet. This is stressful and demoralizing.

This could mean making hard decisions. Our first year was Stronghold and some of our students really wanted to do a climber. It would be a fun technical challenge and would show off to higher ranked teams who would then pick us for their alliance. But when we did the math, we realized that the best value would be to build a robot that could do just the low goal and ground defenses. We built essentially a tough little drivetrain with one simple ball intake mechanism that could also handle the defenses. We struggled to even get that done in our 6 weeks, but it was the right call: It was a solid drivetrain that never broke down, we practiced and got very good at what we did, and as a result we ranked high and were alliance captains at both of our first events.

Every year you can build on existing knowledge and refine your processes. As you get a bit faster and a bit better, you can start tackling a bit more. Power Up is the first year we even built a robot capable of doing “everything”, but we did it with the simplest possible mechanisms that our students could design and build in the given time. And we kind of did so reluctantly. We know we do better by focusing on just a few aspects of the game and building something robust to only do those things. It would make a lot of sense to build a simple, solid, and fast switchbot.

  1. Stand on the shoulders of giants. Aka, your own students.

As I alluded to in the previous point, hopefully your team is collectively getting a little bit better each year. This shouldn’t be accidental - plan for it. Write everything down. Org charts, diagrams, processes. It’s a huge pain the first time, but the subsequent times just become copy/paste/edit. Something didn’t work well? Change it! The goal is to have institutional knowledge that’s not locked away with one particular person. You don’t want to ever be in a position of asking “how did we do ___ before? I don’t know, Johnny always did it but he’s gone now.”

Keep your old CAD models around. Keep your software on GitHub as separate projects for each year’s robot and build upon your previous work. Our autonomous modes this year build a lot on the work that was done last year, and so on.

  1. Be social!

Get your name out there – name recognition builds excitement and goodwill in your community, attracts sponsors, mentors, even students, and could be a source for outreach or fundraising opportunities. It’s also a way to keep students involved when the robot building season is over, and helps you build leadership and planning skills into your students which will translate into your future build seasons.

Get to know other teams, whether in your community or on social media. We’re very active on Twitter and it’s a lot of fun interacting with other teams. It’s fun, it gets your name out there, you learn stuff, it looks good - everybody wins.

Good luck!

for us CAD has been really important. A few years ago, people just wrote/drew down their designs on pieces of paper and as a result our robots were not that great. This is the first year that we have actually had full cad, and as a result our robot was significantly better than in years past. I know this can seem like a large task for a newer team, but it can make a lot of difference. even if you just have some cad, it can help a lot with getting key dimensioning worked out. It also makes it a lot easier for the build team because they have nice looking printed drawings

This is personally a big one for me. While talking to teams, I’ve run into many that will wordsmith sooooo hard in an attempt to make their robot look as good as possible. Makes the team very undesirable to work with, due to lack of good communication.