How do successful teams go about designing?

Hello wonderful folks of Chief Delphi. We are currently in the process of trying to improve ourselves, as with every year.

A big problem point for us has always been the beginning of the build season. As soon as we decide what our robot should be able to accomplish, it seems like we cannot design a reliable or competitive system ourselves. Inevitably what happens is that we spend far too long on making wooden prototypes, before deciding late into the build season that we’ll make a derivative of an Ri3D system. Then we end up not getting enough driver practice, and playing poorly.

So my question to you folks, is how do better teams go about the process of designing their robot? What do you look for and what instantly comes to mind during the reveal? And possibly more importantly, how do you teach design to the new members? We have quite a few seniors who are decently good at designing, but every year it feels like a wipe with our knowledge.

What resources do you use to come back to for inspiration and to teach? How do you properly archive older years? I’ve been following the development of FRCDesign.org and I’ve looked over Spectrum’s Training Resource Page, but I’m curious how it is traditionally done.

3 Likes

A lot of the Open Alliance team build threads on CD are super valuable to see what ideas do/don’t work early on in the build season. Keep a close watch on those threads to save yourself some valuable time repeating prototypes that have already been done, and to see some ideas your team may not have thought of. The Open Alliance teams generally also have more effective designs than the Ri3D teams since they have more time to think about the game strategy and develop a robot design without the chaos of a 3-day deadline.

On kickoff, it’s also always helpful to find 1 or 2 past FRC games that are the most similar to this year’s game, and look at how the most competitive robots from that year accomplished the game’s tasks. Don’t try to start from scratch every year!

15 Likes

A bit of advice for projects that has served me well thus far in life:

Pick one or two hard things to do, outsource the rest

What is hard varies from team to team, it may be code for some, logistics for another, or mechanical for another.

The best other simple bit of advice is Karthiks effective first strategies quote, along the lines of:

A robot with 2 functions operating at 100% is vastly better than a robot with 4 functions operating at 50%

Simple will get you a long way, picking your battles will get you even further.

17 Likes

Teams rarely wait for their ‘prototypes’ to be complete and functional before they start the design. Choose one or two paths you’ll try to follow. Start designing the most likely path immediately, while another group tries to do a rough protoype of what you think the biggest pain points are in that design. But in the short time that you have to be designing, your cad team should be forging ahead.

If the prototype finds some major problem, you might have to redesign. If it doesn’t, then you keep going. Most importantly, don’t be afraid to design and fail. Don’t fall into the trap of waiting for your prototypes before you choose a primary direction.

7 Likes

In general, the FRC bot has subsystems that are repeatable year to year. It may have different purposes, but the mechanics have not changed for a long time. Things like Shooter, climber, drive train, intake, Chassis, etc. These are everywhere here from build log to CAD download.

As soon as we know what the bot would need to do, pick one or 2 design paths, base on what you know worked good from previous years or other teams, prioritize it, and stick to it.

Say for Crescendo, if you have system(s) that worked well from Charged up, use it, recycle it, repurpose them. Don’t re-invent it, but perfect it. Steal from the best, invent the rest mentality. Don’t try to get to make your prototype working perfectly. Most of the the time, it took exponential amount of time to go from 80% working to 90%.

The goal should be to have something that drive team can take it for a spin and capable of competing as soon as possible. I would enter the competition as early as possible. Then take 2 weeks off to improve the bot and aim high for 2nd competition. OR ,delay the first competition entry to gather info, then use the feedback to design and improve better bot. I still like my first approach though. Nothing replaces a real match.

1 Like

Weird to reply to my own thread, but to anyone looking for answers in the future, I’ve taken a lot of inspiration for next season from the way Rembrandts does their design decisions. See here: FRC 4481 Team Rembrandts | 2024 Build Thread | Open Alliance - Chief Delphi

2 Likes

Wait for CADs to be released after a season is over. Build it during the off-season, and hope the following year’s game can use some of the subsystems you created before. :call_me_hand:

I think the frcdesigns.org is a great place to check out for ideas and actual CAD releases from teams in a central place.

7 Likes

The REV max tube ecosystem is both easy to build and to prototype with, and we’ve had good success using it for the last couple years. We’ve also done the wood prototype route, but where the wood was honestly in just about good enough shape that we could compete with it (almost had to in 2024 because of the timing of getting the metal part made).

Our 2019 was similar to what you describe of spending a lot of time being indecisive, prototyping things, but then landing at the the worst strategy we could. Since then, we force ourselves to just pick the strategy less than a week in, usually doing almost everything but with some things cut out (2020 color wheel, 2024 trap). And after 2019 we’ve all 4 of our event wins.

We also try to go for something high value, but not be too bold about things I guess? We did do a traversal climb in 2022 (because we were pretty sure we could score it faster than the balls based on testing), but like in 2024 we scored in the amp by shooting down into it and only tried scoring in the speaker up at the subwoofer. It helps if you don’t need to prototype something too extensively to know it will just work.

2 Likes

So this upcoming season is going to be my second year as a CAD Mentor. While I am far from an expert on design, I can tell you a bit about what our team does.

We start by brainstorming 1-2 different ideas for how we can complete the task. We try to keep early designs as simple as possible to minimize the chance for errors. If you are taking too long on the prototypes, you may be trying a bit too hard with your designs and they may be overly complicated or not as effective as another way, at least that’s what we found this season. Our Note shooter from this last season was completely redesigned the week before our first competition because we found a better way to do it, so don’t be afraid to make changes.

Teaching design is another story. We keep previous robot’s subassemblies and prototypes to show off to our new students the days following the reveal to help give them ideas for how different things may work; it helps create discussions to explain way this year’s floor pickup assembly may be different from that year’s and why. Checking out other team’s robots from previous seasons is also a big help for seeing what works and what doesn’t.

1 Like

Learning and teaching design can be difficult because it requires a lot of domain-specific knowledge and practice to build intuition.

If you’re a team that’s struggled with design in the past, I highly suggest downscoping and focusing on 2-4 students (maybe mentors too) to put the time in and learn it by doing. Go through the guide on https://frcdesign.org, practice subsystem design, join the discord and get feedback, etc. For other team members, focus on core prototyping, fabrication and electrical skills.

The last thing I want to emphasize here is the role of prototyping in build season. It’s easy to generalize, but different kinds of prototypes can serve very different purposes. I like to think about it like this:

  • First few days: proof of concept prototypes. What kinds of things actually work with the game pieces? For example, in 2023, it should come clear pretty quickly that picking up tipped cones is very hard.

Use the learnings from those prototypes to develop your robot’s need, want, explore, don’t list. Now, start archetyping. Draw robots on the whiteboard, use KrayonCAD, or do layout sketches for different robots. Make sure they obey the proof of concept prototypes, but don’t worry too much about details. Focus on integrating subsystems to check the most boxes on your matrix with the least amount of complexity by integrating subsystems.

  • After you have a couple of promising archetypes, switch to optimization prototypes.

This is when keeping track of geometry used and recording everything becomes really important. Pretty early on you want to identify the most promising way to do things; like settling on a roller based under the bumper intake. Once you’ve settled there, you can start final CAD in parallel, basing it all off of a core layout sketch.

You can then continue to optimize your prototypes, merging new geometry into your layout sketch and updating the final CAD in real time. Once you’re ready, you can pull the trigger and fab all the parts.

I know this seems kind of complicated but the core understanding here is that proof of concept prototypes and optimization prototypes serve different roles, and your build season can absolutely benefit from parallel work, if done efficiently.

4 Likes

Something I don’t often see brought up, possibly because it’s terrible (not as bad anymore though) is not being afraid to scrap weeks of work. Sometimes that’s to pivot to a totally different robot architecture, sometimes you just need a fresh slate to execute all of the things you worked out in the spaghetti CAD that might have actually been built.

Tldr: be aware of the sunk cost fallacy, and when it actually applies.

Many successful teams have the resources to shred half of the build season’s work, but many also do not and succeed despite what they come to realize is a compromised design. At 330 we usually tossed something like 50-80% of what was ever in CAD depending on the season, and there are years with “old robot” and “new robot” folders.

9 Likes

First of all, you need to start this process in the summer/fall, or at least as early as possible.

As someone who’s been teaching CAD and design for for a while now, I will say that I have huge respect for teachers. Teaching is freaking hard. Teaching students who you only see maybe 1 or 2 times a week (a typical schedule for off-season) is even harder. In my mind the best way to handle this is self paced learning rather individual lectures. This way students who miss any given build session aren’t missing out on crucial information.

Ok great, so now what? Well now you need to actually build a curriculum that supports this. I’ll once again praise teachers, because building curriculum is hard work. In the recent past my team has relied on resources built by others:

  • Onshape courses
  • FRC 3005 CAD courses

This season we used frcdesign.org and I think that resource is the best so far at an approach to a self-paced learning course specifically for FRC CAD and design. I think in its current state (not all the way finished), the learning course has almost all of tools needed to reach a student how to design subsystems for FRC robots.

The final piece of this literally just practice, practice, and more practice. Choose a game and CAD a subsystem or a robot for it. Choose a subsystem your team doesn’t have much experience with and CAD it. Participate in community-run CADathons. Review your past robots to see what worked and didn’t work. Review publicly available CAD from top performing teams to see how they approach design. If you don’t understand something, or why someone made the decision they did, ask them! Be curious.

2 Likes

If you haven’t already, I highly recommend having your team watch the “Effective FIRST Strategies” video by Karthik Kanagasabapathy on YouTube. He’s a brilliant strategist in the FRC world, and his approach shows what matters when designing to compete effectively. It’s one of those resources that’s packed with insights about how top-tier teams approach the season, how they prioritize, and how they evaluate what will actually make a difference on the field. It’s super helpful for both rookies and veterans alike because it reinforces how to make smart, focused choices rather than just designing the most elaborate robot possible.

The design process for successful teams tends to start with clear goals that shape every decision. You might start by asking, “What do we need to be able to do to achieve our goals this season?” That means prioritizing reliability and consistency. One of the most effective design philosophies is to start by maximizing the median score of your robot in a typical match. In other words, aim to make sure your robot performs decently every single time. This is actually harder than it sounds because it forces you to focus on simplicity and robustness. Think of every mechanism and ask, “Will this hold up in match after match?” Reliability should be your first priority because a robot that can score a consistent number of points every time will almost always do better than one that’s amazing on a good day but can’t function half the time.

Once you’re confident in your median score, then you can start focusing on pushing the frontier score—the highest score your robot can achieve in optimal conditions. This is where you add in more ambitious features, but only if they don’t interfere with that base reliability. If you build a mechanism that could boost your score potential but makes your robot more prone to failure, it’s probably not worth it. This balance between median and frontier scores is a strategic way to make sure your robot is both competitive and resilient. A practical way to think about this is by creating a probability distribution of your robot’s scores based on different scenarios. For example, if you’re in Excel, you can simulate match rounds and see where your robot’s scores tend to fall. Aim for a decent 10th percentile score, a strong median, and then push that 90th percentile up as high as possible, knowing it’s something you’ll reach in a perfect match.

A big part of the design process involves prototyping, but you want to prototype efficiently. Instead of spending weeks making endless wooden mockups, try to limit prototypes to only the most essential features. A lot of top teams prototype quickly, test the critical aspects, and move on. The idea is to confirm whether your concepts are viable without getting bogged down. And when you prototype, build field components and run mock rounds. This will give you an idea of how well the design works in a real match setting. Having field elements is crucial because it lets you simulate game play and measure how effectively your robot can score and perform certain tasks.

To help with making design decisions, use a Pugh matrix. This is a simple yet powerful tool where you list your design options, assign criteria (like reliability, cost, ease of implementation), and rate each option against those criteria. A Pugh matrix helps you make objective comparisons between designs rather than relying solely on gut feeling. It’s especially helpful for newer members because it breaks down the decision-making process and teaches them how to evaluate options critically. Encourage them to weigh trade-offs carefully. For instance, maybe a more complex mechanism can score faster but has a higher chance of breaking. The matrix makes these trade-offs more tangible, helping your team prioritize what’s actually valuable for your goals.

For teaching design, nothing beats hands-on experience. Encouraging new members to CAD and even build robots for past challenges is a great way to build their skills (I believe frcdesign.org encourages you to do this, I also recommend you to join Davids Design Server who actually made the website). They get to work through the entire design process, see how real mechanisms come together, and learn from their mistakes without the stress of a tight competition deadline. Design is something that improves with practice—learning from failed mechanisms, understanding what works under pressure, and iterating based on feedback are all crucial skills. The more they get to practice in a safe environment, the more confident they’ll be during the actual season.

It’s also important to keep in mind that efficient work isn’t about clocking in as many hours as possible. Efficient work means that every hour spent is purposeful. This is especially critical in those first days after kickoff when the design decisions you make will set the course for the entire season. The best teams work long hours, but they’re also making those hours count by having a clear plan and sticking to it. Wasting time in the early days on overly complex designs or unnecessary features will just lead to burnout and disappointment later on. Try to keep your design goals focused, your prototyping quick, and your decisions deliberate.

And also, I can’t stress data-driven design enough. Once you have a prototype, try running it through mock rounds and track its performance. Plotting scores on a histogram, seeing how often the robot hits certain benchmarks, and identifying weak points are all part of understanding where your robot sits in terms of performance. You can start to see patterns—where your robot excels, where it struggles—and use that data to refine your design further. It’s a continuous loop: build, test, analyze, and improve. The more structured you make this process, the more likely your team will end up with a competitive, consistent robot by the time competition rolls around.

tl;dr: focus on reliability first, push for higher performance once you have that stability, teach design through hands-on experience, use tools like the Pugh matrix for making smart decisions, and prioritize efficient work. And seriously, take the time to watch Karthik’s “Effective FIRST Strategies” video (I bet you already have). It is the one video related to robotics that completely changed the way I look at things for the better,

3 Likes