How are final decisions made?

[sanddrag]

How does your team decide on things? I'm mostly looking for robot related things but I guess we can discuss all things.

[Koko Ed]

We do brainstorming as a team and as a team come a conclusion to what direction we want to go (via a hand count vote).
The Integration team then implements how the idea that were stirred up will work for the robot. After 15 years we've gotten pretty good with the process and got the efficiency part nailed to a T. We may not build the best robots but they they will be built on time and they will be a quality machine and that's all you can really ask.

[=Martin=Taylor=]

"Officially" my team decides things through votes. But I don't think we've ever come to a solid conclusion this way. I don't know what we do wrong, it just seems that no one is ever willing to except the outcome.

Has anyone else had this trouble with the voting system? I personally don't think a robot should be built based simply on the will of the majority...

IMO the best way to come to conclusions is to test everyone’s ideas and decide what works best. After a little CAD work and a few prototypes it quickly becomes apparent what works and what doesn't. The only problem with this method is that there is rarely enough time to test everyone’s ideas.

[AdamHeard]

Originally Posted by Hachiban VIII

"Officially" my team decides things through votes. But I don't think we've ever come to a solid conclusion this way. I don't know what we do wrong, it just seems that no one is ever willing to except the outcome.

Has anyone else had this trouble with the voting system? I personally don't think a robot should be built based simply on the will of the majority...

IMO the best way to come to conclusions is to test everyone’s ideas and decide what works best. After a little CAD work and a few prototypes it quickly becomes apparent what works and what doesn't. The only problem with this method is that there is rarely enough time to test everyone’s ideas.

Yeah, we had the same problem this year. Didn't come up with a Jam proof hopper until week 4. It didn't Jam, but it really slowed us down :/.

[Donut]

Everyone makes lots of suggestions (and then tries to prove them) on our team, then eventually we vote on what we want to do. Usually the better option has the most convincing arguments for it, so it sways a majority of people to it. I'll admit we've done some aspects of the robot in ways I didn't think would work (and sometimes they don't), but I'm not the sole designer so that's really not my job.

[JohnBoucher]

We try and discuss every decision. Some decisions do not lend themselves to discussion.
We firmly believe that this is the students robot. The role of the mentors is to the best of their ability build the robot to what the students want. The role of the mentors is to guide the students, not lead them.

[Tim Baird]

Atleast in terms of the robot design, we get everyone together in a big room, shoot out ideas (students & mentors alike) and write them on a big long Ishikawa diagram. Then we continue to add ideas until they get ridiculous and people run out of ideas, we go home and think about them, then come back the next day and start knocking off the undesirable/unrealistic/impossible ideas until we have about 4 potential mockup robots. The mockups are built over the next few days and then tested, broken, rebuilt, rethought, broken, and rebuilt again until each subteam is happy with them. They are then tested at our field/shop and then voted upon by the team.

Granted, the mentors might pull a little more weight due to years of experience because they can spot potential issues and problems in a design ahead of time. However, everyone gets a say as to what is done.

[Billfred]

I worked more this past season with the drivetrain side of things on 1293, so my story will focus on that. After Kickoff, we pretty much threw every single drivetrain concept out there: 2WD, 4WD, 6WD, treads, omni drive, you name it. From there, we started hashing out the pros and the cons of each. Our experiences in 2005 with Ockham's 2WD setup threw that out the window right fast. Omni drive was also dismissed rather early, due to the software kung-fu required for it in some key aspects of the game. (We had a new programmer this year.)

From there, we hashed out the pros and cons of each arrangement. Tracks offer more surface area, but if anything goes wrong with one track, you're driving in a circle for the next minute and a half. 6WD is heavier, but it turns better. 4WD adds some stability at the expense of turning. This pros-and-cons discussion went on for a while, and we kept coming back to 6WD as the setup that offered a good solution to each category we wanted. Would it be the best in a situation? Perhaps not, but we tended to agree that pretty-good across the board beat alternating between superior and miserable.

Most of our decisions tend to work out like that: lay out the options, throw out the ones that we knew could not happen (using six IFI wheels, for example, because of cost reasons), hash out what would work well (use two IFI wheels on the middle, then four Skyways on the corners), then go for it. The result, JVN jokes aside, worked out pretty well for us.

[JaneYoung]

We have something called Drop Dead Design Day (D^4).
After Kick-Off, we have 4 or 5 design leads and the team divides up with each lead, 3 to 6 per group, all students. They each have 3 days to come up with a design and most groups usually meet the Sunday following Kick Off. After school on that Wednesday the team gathers with mentors, parents, anyone interested and each design is presented; our lead teacher and technical mentors usually present one or two designs or ideas at that time. The first time around it is presented by the group using white board, chalk board, mock up, overhead, CAD, whatever the group decides. We go through all the designs, allowing time for questions following each presentation. Then we go back through each design making a list of pros/cons. Lively discussions are usually involved during the process. When all the designs have been presented, questions asked, discussions relatively ended, then there is a vote. Everyone can vote. Often, there is discussion even after the vote and we have been known to revisit the design and stay until everyone is relatively happy. From there the design can continue to change and develop as the team discovers what will and will not work. It can follow the design presented as well with minimal changes, depending on the year, the challenge, the team.

[AdamHeard]

I suggest every team watch this video. It's team 40's video of prototyping with 1/3 scale robots.


It seems especially useful for protoyping and, more importantly, reveals those little aspects about what works and doesn't work in a game (Like how the ramp was more important than stacking in stack attack). It also creates some awesome exhibiton items and a few cool robots to show off in the pits.


My team recently stocked up on vex from radioshack specifically for to do this during the build season.

[Michelle Celio]

We had a fairly interesting ballot system last year.

When it came time to elect officers and such, everyone voted and put thier ballots in a box which was then taped up, and stapled and everything else we could think of. We then went to go eat dinner at the cafeteria, and I was the uh honary box guarder, then one of the team mates stole the box and we spent about 20 minutes chasing him around campus to get it back, we called this "mixing the ballots" for a surprise voting.

When we do ballot voting the mentors get to vote, but their vote is equal so it's a full team decision.

[Madison]

We developed a comprehensive list of functions the robot might have and asked students to rank their importance on a scale of 1 through 5 (where 1 was not important and 5 was very important). We averaged the importance assigned to each function and then I used that to guide the design. It was a good indicator of what the students would support, but it was by no means a design bible, since it ended up that the students ranked scoring in autonomous mode higher than they did scoring at all, for example.

[Jeremiah Johnson]

Well, robotwise we devote a whole week or more to design and functionality of the robot. We vote on the big things, like drivetrain, manipulating mechanism, ect. Then the smaller things are given to Ed our head engineer and he'll find the best way to do them. Some times he will explain what it is that he changed or improved, but other times we just let him do that part. Most of the general stuff is done by students and Ed has the final say on how it's going to be built. Since he's the only one that has the time to CAD everything out and then test it. During those 6 weeks he's 110% devoted to the team, because he's retired and has nothing better to do. LOL But yeah, it's a mixture of those answers. Majority vote, mentor has final say, sometimes we argue to the point where someone gives up but that happens rarely and is usually stopped quickly, and other times it's a compromise.

[KenWittlief]

In my 22 year career as an engineer I have never been in a meeting where technical decisions were made by the design team voting on options.

There are clear processes and measurement criteria for making engineering decisions that are functions of real system characteristics: cost, complexity of design, modularity, weight, power requirements, size, unknowns that have to be resolved (risk), manufacturability, reliability, repairabilty, resources required...

you can make a matrix with each characteristic across the top, and put each design approach on a row, grading each point on a scale from 1 to 5. The approach with the highest score is the best system.

There is no need to vote, unless two approaches come out exactly equal on the evaluation.

We have done this on FIRST teams - it makes a huge difference in the students attitudes. We can honestly say "I think your idea is awesome, but we are doing something different, for reasons you can clearly see". This goes over much better than a show of hands, and the resulting battered egos.

[Hieb]

While our team believes that the robot should be student designed, I voted "Mentor has the final say" simply because our mentors have a final veto power--but only in cases where a proposed design has not been fully thought through and poses a safety hazard. We are willing to let a poorly thought out design procede to serve as a learning tool, but when a small structural change (say from the impact of another 'bot) may result in parts getting caught on a sprocket and becoming a projectile, then we step in. We also try to play the role of devil's advocate in most cases, so usually the students discover the weakness before we have to actually excercise that power.