People have mentioned having a single person design a robot, and design by committee. Sorry if I missed this suggestion already, but you should try what my old team used to do. After reading the game manual and learning all the different ways you can score and what the max scores will be, then we create robot categories. Each category includes the ability of the robots (just cargo, can also do the rocket, just hatches…) and the anticipated implementation features (elevator, shooter needed), along with the anticipated points that the robot can do alone, how it’ll rank at events, and it’s role on a district or Einstein alliance. The team then votes on a robot category that we think will fit our constraints (budget, experience, expectations for the season). Then finally, we break into sub groups and actually design the robot, which involves looking at past FRC games, and that’s where we vote on implementation details that teams have come up with (oh let’s copy 118’s 2015 intake, oh let’s do a lead screw, oh let’s copy 148’s 2018 elevator, etc…)
This sounds like setting up the team for camps in favor of one design over the other- exactly what they are trying to avoid. In the end, we are still dealing with high school students who attach preferences to “their” design, as much as we can tell them to avoid that. I do not believe that structuring a team into groups and then pitting the groups against each other is an effective way to alleviate gridlock, in fact I think it will worsen it.
As far as the strategic analysis you laid out, that seems fine. But voting as a process leads to debate. The engineering solution is to simply not vote.
OP, I would make a decision ahead of time as to who will get design authority. If team seniors have been around a while, they have seen effective and ineffective designs. Entrust them with the decision, and make them justify it to the rest of the team for buy-in (an important step, for sure). Then start prototyping, designing, etc.
Yes, exactly this process takes place on our team, I just didn’t lay out the full scope & details of what we do, so thank you for fleshing it out fully. At the end of the day though, the decision comes down to the lead designer choosing what they think will be more effective.
You acknowledged that you’re writing from the perspective of a student; here’s my perspective as a mentor:
It’s hard for us to truly diagnose what’s going on with your team over Chief Delphi. I think the most valuable step you can take is to talk to your mentors about it. Approach whichever mentor you’re personally closest to, and (at a good time for discussion, not in the middle of anything stressful or high-priority) ask them for their take on what’s going on the with the team. Not in a “the team isn’t doing what I want!” way, but just express that you feel like the team is struggling, and ask them for their perspective on the reasons. Your mentors probably have insight to what’s going on that you don’t, because they’re behind the scenes in a way that you’re not and have (probably) been involved longer than you have. And you have perspective that they don’t have, because you’ve experienced the seasons as a student and get to talk to the other students as a peer.
One of the cardinal rules in engineering is to put effort into understanding the problem before you start trying to solve it, and the best way to kick that off in this case is to open a dialogue about it with your mentors, because ultimately this is a problem you’ll have to solve together. Once you’ve discussed it together and feel like you have a handle on the root causes, you can draw on the other advice given in this thread to make a plan.
See Mike Corsetto’s workshop on strategic design. Be sure to first lay out your criteria for your robot, then prototype the ideas, and then decide on works best. If anyone proposes a change, ask them how it meets your criteria better than what you have so far. That should keep you from getting too far off track. https://www.citruscircuits.org/fall-workshops.html
Back in 2016 we got tired of looking around at robots and thinking “That’s what we should have done!” We had the capability to make great machines, but kept making incorrect assumptions early on, not managing our time well, and shooting ourselves in the foot because of it.
So, I went and did a bunch of research about how great teams operate. 1114 has a ton of material on their website, and 1678’s workshop series is unbeatable (@Richard_McCann already linked it). JVN’s 148 build blog from last year was the most transparent look at a top team that I’ve ever seen. 254 has a 2017 build blog that step-by-step shows the process they went through to design the last “true” world champion bot. I found additional resources on the team sites of: 33, 1241, 1986, and 2056 (among others, I’m sure).
The concrete actions that I took out of this were:
-
We built 1678’s 2016 drivetrain.
Our drivetrain was such a disaster all year, that we shamelessly built Citrus Circuits’ in the offseason. It was the most brazen act of copying that we’ve ever done, and we learned more about drivetrains and chassis than we had in the previous 10 years of competition. -
We had our first mock kickoff.
We kept mis-judging the game and launching into robot design before we knew a thing about game strategy. So, I defined a procedure for the first 2-3 days of build, and we had our first two mock kickoffs. I led the first one, which was small, ~4 student leaders, ~4 mentors. We grabbed the 2005 manual and followed the procedure to analyze the game, come up with functional requirements for the robot, and brainstormed a few mechanism ideas. Afterwards we watched Einstein champs for an idea of what successful robots looked like, and talked about where our procedure had worked vs where it fell short. Once we’d revised our procedure, the student leaders led the whole engineering team through a second mock kickoff (2011? I think?). The following year we captained our first ever winning alliance.
We’ve done much the same at times. Look at our pass through this year–look familiar?
I feel like I might have seen something like it last year, can’t quite put my finger on it though…
Jesus, the idea of holding a mock kick off is brilliant. Thank you so much for bringing that idea to my attention. This thread is a goldmine for new teams as well.
We definitely didn’t invent the idea, but it was huge for us. I think it’s really valuable to write your own kickoff procedure, but send me a message if you want some guidelines about what ours looks like.
It was immensely helpful. We’d do the mock kickoff for a previous year and then find robots that were close to what we’d come up with and checked how well they did, and if they didn’t do very well (maybe going with an arm over an elevator a particular year) we would figure out why it didn’t do well, and what mistakes we made in our decision-making. We’ve drastically improved since doing this process.
With ever larger teams its good to settle on finite/limited “design criteria’” systems based on the gameplay at hand and then break students into groups to promote various subsystems until final designs are selected.
What gets measured gets done (most of the time) if the subsystem teams do their roles
The advantage is all 70 only work on selecting the subsystems, then break up into subsystem groups…less is more at that point.
The hardest part is ensuring meshing with the final overall design. Yet manageble.
For OP, do you think that your problem this year was in what mechanisms you wanted to design and which ones to skip? Or was it when after you decided what you wanted your robot to do, you couldn’t decide which of several mechanisms to go with?
One thing that our team did during the off-season was to perform a SWOT (strength, weakness, opportunity, threat) analysis via survey of all returning members and mentors. It proved to be very insightful. It allowed us to listen to all voices, and to recognize issues that may not have been voiced during the course of the regular season.
Another thing we committed to was full consensus for decision making. Everyone gets a voice in the decision making process, but decisions do NOT need to be unanimous. As a team, we can agree to disagree during the discussions leading up to a decision, but once consensus is reached, we move forward as a team to support those decisions.
Underperforming during a particular season is a very painful, but also very powerful process. It definitely leads to some short-term pains, as you’re obviously experiencing now. But it can also perhaps be the biggest learning opportunity that you can ever experience. Be a phoenix… rise from the ashes as a stronger and more unified team.
Can you elaborate more on how your team’s decision making process works? To me “full consensus” means decisions do have to be unanimous, but it sounds like it means something different to you. What does it mean to agree to disagree leading up to a decision? If there are two (or more) factions, how is the decision made?
I’m familiar with three models of team decision-making: everyone votes and the majority rules, keep discussing until you reach 100% consensus (no matter how long it takes), and benevolent dictatorship (after some amount of group discussion, one person makes the final call). Does your team follow one of these, or some combination, or something else?
We found benevolent oligarchy worked well. Three people vote in the end to decide what design to use. (Captain, Head mentor, design Head)
Perhaps I should have just said consensus, rather than confusing it with the term full consensus. And we follow a hybrid combination of the processes you mentioned. It’s not a matter of just doing a majority vote on separate ideas, or one dictator calling the shots. Definitely more complicated than that. Nor is it simply a majority vote on who came up with the best ideas.
Please take a look at this attached document which outlines our “Design Weekend” approach that we took, immediately following this year’s kickoff.
Design Weekend 2019.pdf (128.0 KB)
This has worked GREAT for us. In a matter of days we had all members of the team on the same page, fully supporting our approach. And this entire process was fully and completely developed by students on the team.
We just started doing this last year to train our new students in the process.
First of all, I just want to say thank you for all the advice and support came out of this thread. It’s amazing how much everyone wants to help out each other here, and I couldn’t be more grateful.
To answer some questions from previous posts in this thread:
Our main problem was getting people to agree on anything in the first place. Everyone had their own vision of what the robot should do and how it should be designed, so no one was on the same page. This resulted in the team being split up into groups based on who wanted to do what, and our final robot ended up being a mosaic of people’s ideas.
In 2018 (PowerUP), we had people who wanted a small, fast switch/vault robot that could climb for the extra RP, and we had people who wanted an elevator to reach the scale. We also had people who wanted to lift other robots to ensure the RP. So, our robot ended up having an elevator that could just barely reach the low scale (~4 ft. off the ground, someone had to have tipped it in our favor), climb with gearing designed to lift 2 robots (it was very, very, very slow), but the ramps for other robots to get onto were never designed or fabricated. We obviously could do switch/vault as a result, but not that well since our elevator was too slow (as it was geared to lift other robots, not lift cubes fast). Our robot had everyone’s ideas represented in some form or another, but as one would expect, it did not turn out pretty.
For this season, we had people on our team who wanted to attempt the higher levels of scoring (i.e. levels 2 and 3 of the rocket). We had people who wanted to attempt manipulating both balls and hatches with a combined mechanism, and people who wanted to just focus on scoring low. So, here’s what transpired:
Our robot had an elevator with a manipulator that could only do hatches, and on the back it had a small bucket for cargo that could only do cargo in the cargo ship, and only pickup from the loading station (no ground pickup). Needless to say, this cargo bucket was an afterthought, and cargo fell out every time the robot was lightly hit or our driver spun around at more than 30% speed. Yet again, our robot was a combination of everyone’s ideas, and it worked inconsistently at best.
Organizationally, our team is a mess. Our dilemma is achieving a balance of keeping people satisfied (so that we retain new members) but also at the same time not letting that steer us into a nosedive.
What our team does, and it’s similar to what other’s have done, is after kickoff, we read the rules, ALL THE RULES, as a team. We then spend some time getting our game terminology set. Cargo is cargo, not ball, sandstorm, HAB, rocket, cargo ship, cargo bay, hatch panel, cargo line, loading station…After that we figure out all the ways to score points, even some of the fouls and especially how to get the RPs.
Our team’s goal is to be a captain, so we always design our bot to go for 4RP. This automatically meant lvl 2 and lvl 3 rocket as well as lvl 3 climb. It also meant that we were doing both cargo and panels. So our bot needed first of all, DRIVE EVERYWHERE. Then the bot needed:
- A lvl 3 climb
- Hatch panel intake
- Cargo intake
- A method to put cargo/hatch on lvl2/3 of rocket AND the bot didn’t have to turn around. (this was because of 254 last year)
Afterwards each one was split up into needs/wants, like need to have cargo pick up from floor. Touch it own it is a need for any intake every year.
We then told the students to go look at previous year’s games and bring in videos/sketches of ideas. For last year’s game, the students didn’t bring very many ideas in so this year we stressed the importance of bringing in ideas and the students brought in so many ideas that after an idea/video was explained, we had to ask how many others had a similar idea so we didn’t watch a lego stair climber video for the fifth time.
It’s at this point that we, as a team, evaluate each of the many ideas for each mechanism and pick the one or two we think are best and go off and prototype. One of the ideas for the scoring mechanism was a turret, but was rejected because we’d never done one before. Depending on how 254 does this year there might be a lot of teams that try a turret elevator.
As a team we’re very good up to this point. Our problem is between deciding on what to prototype and what makes it on the competition robot. It would be nice to get to 148s level of prototype/iteration but that’s our area of improvement. Next year without bag day I hope we get the bot finished by week 4 so programming has a week and the drive team can practice for a week and still have time to iterate mechanisms that programming and practice have shown need improvement.
You might want to go through the links that BordomBeThyName linked, it will definitely make you think on how your build process compares.