This Tuesday (December 3rd) at 7:00 pm ET, we’re back with a very special episode of FIRST Canada LIVE! Myself and FIRST Canada Youth Council member Danny will be discussing how to build simple and effective robots with a panel of illustrious mentors including:
With the theme of “simple and effective” in mind, what are some systems which are useful to know by name? What I mean by this is year-to-year we get different challenges, but we sometimes see design convergence because many teams know what a “pink arm” is or a “double four-bar” mechanism.
What do you see as a handful of engineering designs that should be known by teams as common reference instead of trying to reinvent the wheel after kick-off?
Super excited to be on this show with Tyler and Adam, two of the all-time greatest on this topic. Kudos to Karthik and Danny for putting together what should be an insightful discussion, I’m sure this episode will have something for everyone.
Keep adding questions in here, we might not have time to get to all of them in the show, but maybe we can organize to answer more questions in this thread after the show wraps up.
Karthik, this is “Effective Robots volume N+1”. Do you observe the message getting through to the general FRC population or only individual teams? (Not to say it isn’t a noble endeavor.) Are the changes temporary, persisting multiple seasons or completely obscured by the challenges each game presents? (I’m too absorbed with my tree to see the forest.)
How many weeks, days, or, minutes into build season do you believe the typical over-ambitious mid+ resource teams make their first critical misstep? Is it 15 minutes after the game animation with too many “needs” vs “nice to haves”, insufficient prototyping before finalizing, too much prototyping and falling behind schedule, or somewhere else. (I’m trying to word this to avoid a blanket “too few resources, not enough institutional knowledge” answer)
What is the least favorite robot you ever built?
Are any of your alumni within 50 miles of my team?
I’d be interested in hearing about how teams effectively create modular designs that allow them to do drop-in replacements for subsystems that are replaced iteratively with better subsystems over the course of the season. Or to do a full swap-out of a broken subsystem with a spare in 5 minutes at an event. (Our kids were impressed 1678 swapping our their intake every match last year as part of the Archimedes alliance, among other things to be impressed with).
I know we’ve had some designs that have tried to reach that goal, but inevitably something happens in our designs that causes some critical part of the robot to be difficult to access and repair/check (this is worst with small robots than big robots).
It was predicted in 2019 by at least one person on the show that the removal of bag and tag would lead to top teams building multiple robots throughout the year. Now we are a little more past the covid years, we are starting to see top teams do this (off the top of my head, 696 in '23, 581 buildseason '24, 4414 '24, 4613 '23-24). How can mid-tier and lower teams best take advantage of the removal of bag and tag to build simple and effective robots?
A couple question options for tonight’s show:
Do you think about the complexity of a robot as more of a weakest-link system (ex. “that wrist system has way too many DoF”) or a sum total of complexity across the robot (ex. “making component A simpler lets us tolerate more complexity in component B”)?
How does your perspective change between evaluating complexity in advance as opposed to retrospectively?
It’s very likely that this season’s game is going to be pick-and-place, and I feel that many teams, especially less experienced ones, struggle to design for pick-and-place games. They tend to demand more degrees of freedom and complexity to create effective mechanisms, especially compared to a game like Crescendo, where robots could be effective without articulating whatsoever.
What are some strategies for designing simple and effective robots specifically for pick-and-place games? What are some common themes among robots that do well in these games? How should teams less experienced with mechanism design approach these compared to teams with more experience?
How does (and should?) advancement (specifically regionals) play into the complexity decision making process for teams?
It seems like a lot of Mid+ to nearly Top tier teams have a really hard decision in a regional model. Assuming their goal is a champs invite, just building a simple effective robot within their capabilities leaves them doing well but not nearly well enough. They often feel they have to “swing for the fences” and while they might often miss the one time they hit it might be with enough power to win. Afterwards when they miss “we” say why didn’t they just build a simpler bot. Even though sometimes that simpler bot wouldn’t have been enough, and even worse sometimes it would have been enough but they will never know.
I believe some “top tier” teams also feel this same way with regards to competing at an Einstein level.
This could be a long topic, so moderator and panelists, plese use your judgement.
Its often referenced that it is better for a team to do three things well, than 5 things poorly. 1 of the 3 is pretty much always “be able to drive around the field really well”.
However, top teams usually are able to do 5 or more functions really well. Could the panelists discuss programs they have seen follow a glidepath to going from OK to good to really good to greatness?
Is it a path, a step function, or something else?
For most years, if a team can gather a game piece, and move it to a more desireable location, and do whatever endgame bonus (often climb/hang), then they will have a robot that will do well and play in the playoffs at most events.
A lot of teams can get to this level and even do some “scoring”, what does it look like to progress from that hump.
Simple and effective robots probably start with simple and effective prototypes!
What systems, hacks and or guard rails on the prototyping process (First 2 weeks of build season) help your teams develop knowledge/mechanisms that evolve into simple, robust and effective robot designs?
As a follow up, which of these knowledge areas should effective prototyping result in? How would you rank them and why.
Thank you Danny, Karthik and FIRST Canada for having me on the panel tonight! Really enjoyed getting to reflect and learn from Adam and Ty. I’m excited to pick up my “DO LESS BETTER” shirt at Champs next year!
Let me try to address some of the questions we didn’t have time for:
To build simple, start by being familiar with all available COTS mechanisms and their names. They can serve as your “building blocks” for getting a simple robot together quickly.
Tube-and-Gusset construction, gearbox plate construction, intake rollers, wheeled launcher best practices, swerve drive/bumpers are some to be very familiar with.
After the first weekend when most teams fall into groupthink and convince themselves they need to do more than they actually do.
Probably our 2020 robot, way too complicated, the turret+going under the tunnel was not the move!
My boss at work emphasizes “focus on the interfaces”. We learned from 2023 that we didn’t want to have to disassemble our “wrist” to swap the intake, so we copied 4414’s 2023 approach with our 2024 robot. It really paid off, would do it again! Sometimes the wrist plate broke, so it was still painful at times. Our design lead Emma was a real champ all year, she must have repaired the intake 50+ times this year!
Don’t score in all scoring levels. Skip one of two game pieces where applicable. Steal everybot intake. That is recipe for success IMO.
It really depends on the team, lots of teams onboard new coaching staff and see a step function from, for example, “OK” to “really good”, in one season. I think getting from “really good” to “greatness” requires a longer path of consistency and hard work.
I hesitate to call out specific examples, but every team has “performance humps” to get over, they aren’t as noticeable at the min/max of the performance curve, but they are just as important.
One guard-rail is actually testing prototypes, versus “babying” them as we often want to do aka avoid testing the limits. A well hashed out prototype can help teams avoid many issues when building their actual robots.
This is a tough question to answer effectively without any proper data. That being said, folks who I’ve talked to who watched my various presentations over the years seem to build simpler and much more strategically thought out robots than those who haven’t. Similarly, the audience at my presentations at Championship is a lot more savvy when it comes to strategic design than they were 10 years ago. So, anecdotally, the people who are getting the information and are in positions to be decision makers on their teams seem to be making an impact. Overall, I think the community has gotten better at strategic design as a whole as well. I think the prevalence of design and prototype sharing in the community is leading teams to make better decisions. It’s a lot easier for folks to ignore the Trap for example, if they see a bunch of teams making that same decision. For better or for worse, group think is incredibly powerful. That being said, old habits die hard, and most teams in FIRST still think they need to do everything in a game to succeed, or are still overwhelmed by the urge to do the hardest challenge no matter what.