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.
2 Likes
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.
2 Likes
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.
1 Like
It sounds as though you may not have prototyped all of your proposals. Make that a key criterion–if it’s not prototyped by the end of Week 1, it isn’t going on the robot. If you can’t prototype your idea and no one else is willing to help, it isn’t going on the robot.
4 Likes
If you have the opportunity, I’d also encourage you to sign up for as many off-season events as you can. That’s one thing we did this year after a pretty humbling 2018 season. It was an invaluable experience for everyone. Gave us the opportunity to work through problem areas of our performance, and built great camaraderie amongst our younger members.
1 Like
Or 195’s…
We’re definitely looking into this now. Our local state championship/other offseason events in our state is probably the most feasible for us (given travel distance).
We definitely need to do a better job of sticking to this philosophy, as the end of week 1 is usually where we start falling behind and derailing our entire season as a result.
Again, a sincere thanks to everyone for their advice. I’m definitely looking forward to next season, and I’m excited to see what we can do by implementing the changes mentioned in this thread. 
Do us all a favor and name your robot “Phoenix” next year. Ha
Sincerely, best of luck.
2 Likes
I agree. We’re a small team, and this method have been working for us. Experience is great to have if you want to speed up the designs process. (And by the way, any time we let new students vote on the design, which should be the proper way, we ended up with either poor design or debate for days. Having a senior will solve all dramas.)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.