Robot Design: If there isn't a vote, who makes the decisions?

[weberr]

Decisions need to be based on measurable accurate data obtained; not voting, a dart board, human feelings, etc.

Our team works very hard to develop QFD (QUality Functional Development) in the first days so that we have a "metric" to compare all designs to and thus by measuring the designs back to the QFD, we can develop a ranking of the solutions. If possible, we combine best attributes from multiple designs and that in turn yields a better overall design.

Since there is no emotion involved, then we reduce hurt feelings and focus more on the design. Remember, you want the most impact with the littlest possible amount of effort.

http://www.theflyingtoasters.org/#!_...ces/vstc79=qfd

This year we are adding a component called Probably Scoring Rate as part of the QFD.

[Taylor]

Voting for designs is a bad idea. Voting usually promotes what is cool or funny, not what is best for the team.
Like Mr. Cool said, voting leads to animosity, aggravation, and an adversarial environment.
In my experience, deep, thoughtful discussions, usually aided by a version of JVN's WOT, lead to the correct-for-the-team solution making itself obvious.

[Anthony4004]

My team simply discusses the designs we want to try, not vote. Mainly because you get students who simply want to try something because either they thought of it, or they are backing their friend's idea. We instead try to implement the "Engineering Design Process" where we find the pros and cons of designs, not simply oooh shiny......
Plus there are team members who will actually have to build it, so I try to think about the ease, the area the mechanism will take up in the robot, and how well it will work to our advantage at competition.

[BigJ]

In the past, we have used a weighted matrix to evaluate options, but in the end discuss and decide between the top options from the matrix separately based on our capabilities and the complexities of the systems.

[Jon Stratis]

In our handbook we describe out method of choosing captains very clearly: The mentors choose, with input from the students. That input comes in the form of voting. Making design decisions is much the same way.

We empower our captains to make the overall decision of the robot. This occurs with after doing a cost/benefit analysis of all the ideas, eliminating those with too much cost for too little benefit, and allowing the team to vote on what they like best to help give the captains some guidance. They then empower design leaders for each mechanism to make the decisions necessary, which are often reached after discussion (I can't really call it voting if there are only 2-3 people involved!) with the rest of the design team for that mechanism.

[Chris is me]

It's a lot easier to come to a consensus as a team if you make sure you're all starting from the same premise. If everyone on the team is dedicated to building a simple, effective robot that plays a particular strategy, everyone will converge on the optimal solution based on prototyping. We have formally had a six-member "design committee" (half students, half mentors) that picks the direction of the robot, but really it's just kind of a natural process that comes out of prototyping and vision from the lead design people on the team. We had a poor year for robot design when we voted in 2010. We stopped voting and haven't looked back, and with adequate pre-season training no decision has been controversial anyway.

[DELurker]

Originally Posted by cadandcookies

My question is simple: in teams that do not vote on designs, how are decisions regarding designs made?

This link (link) is to Team 75's kickoff week SOP. On page 7, they show how they use a weighted decision matrix to rate a given design.

Our team adopted and adapted 75's method for the 2013 season and we were surprised by two things: 1) A lot of the ratings showed a definite benefit of one choice over another, and 2) Two equally capable design concepts got an equal rating (within 1 point out of 215).

[Oblarg]

I think it's worth noting that while a decision matrix is a very good guide to help a design team come to a consensus, it's probably unwise to take it as an absolute authority on which design "wins." The numbers generated always have some degree of arbitrariness, and so you should be wary of appealing to "well, this one has a higher score" in the place of detailed discussion.

[seg9585]

Originally Posted by Oblarg

I think it's worth noting that while a decision matrix is a very good guide to help a design team come to a consensus, it's probably unwise to take it as an absolute authority on which design "wins." The numbers generated always have some degree of arbitrariness, and so you should be wary of appealing to "well, this one has a higher score" in the place of detailed discussion.

Numbers in a design matrix should not be very arbitrary. If you can clearly rank attributes of designs then do so, if not then mark them with the same value. Establish a tolerance level (ie 50 pts +/- 4) and anything within that tolerance is a valid design which may be prototyped/implemented. Pick one of these or add a tiebreaker attribute.

[Jon Stratis]

Originally Posted by Chris is me

It's a lot easier to come to a consensus as a team if you make sure you're all starting from the same premise. If everyone on the team is dedicated to building a simple, effective robot that plays a particular strategy, everyone will converge on the optimal solution based on prototyping. We have formally had a six-member "design committee" (half students, half mentors) that picks the direction of the robot, but really it's just kind of a natural process that comes out of prototyping and vision from the lead design people on the team. We had a poor year for robot design when we voted in 2010. We stopped voting and haven't looked back, and with adequate pre-season training no decision has been controversial anyway.

Your post reminded me of something one of my profs in grad school said... Individuals are great at finding a local max in a given solution space, but groups are much better at finding the global max. In other words, individuals might each find different solutions to a problem that can't be incrementally improved on (local max, where any change would decrease the quality of the solution), but those solutions may not be the absolute optimal solution to the problem (the global max, where there is no better solution to the problem).

[Jhultink]

On our team we have 4 student presidents: 3 executive presidents, and a "normal president." The three executive presidents have a vote, but the "normal president" (me) does not. The other three all have at least one or two more years of experience than I, so I think it's fair. So far we have always come to a common consensus and have never actually had to vote on anything. I personally like our system.

[Oblarg]

Originally Posted by seg9585

Numbers in a design matrix should not be very arbitrary. If you can clearly rank attributes of designs then do so, if not then mark them with the same value. Establish a tolerance level (ie 50 pts +/- 4) and anything within that tolerance is a valid design which may be prototyped/implemented. Pick one of these or add a tiebreaker attribute.

The problem is that many of the attributes you wish to compare are not easily quantifiable. "Reliability" is not an element of a metric space. It is useful to attempt to quantify these so you can do a rough estimation of a utility calculation, but I would never take that as anything more than a guide for discussion.

[MechEng83]

Originally Posted by Oblarg

The problem is that many of the attributes you wish to compare are not easily quantifiable. "Reliability" is not an element of a metric space. It is useful to attempt to quantify these so you can do a rough estimation of a utility calculation, but I would never take that as anything more than a guide for discussion.

At my company, we have an entire function called "Reliability Engineering" There are ways to quantify reliability in terms of RPH (repairs per hundred) CPE (cost per engine - we make engines, but it could be CPR - cost per robot), and MTBF (mean time between failure). Reliability is very much a metric in industrial settings. Decisions are made and resources are applied based in part on the reliability numbers.

An FRC robot isn't going to have hundreds of like units to generate RPH, but the other items are real things that each team should consider.

[Oblarg]

Originally Posted by MechEng83

At my company, we have an entire function called "Reliability Engineering" There are ways to quantify reliability in terms of RPH (repairs per hundred) CPE (cost per engine - we make engines, but it could be CPR - cost per robot), and MTBF (mean time between failure). Reliability is very much a metric in industrial settings. Decisions are made and resources are applied based in part on the reliability numbers.

An FRC robot isn't going to have hundreds of like units to generate RPH, but the other items are real things that each team should consider.

I should have qualified my post with "in the context of FRC," but I think the point still stands. In my experience, much of the rating in our design matrices essentially comes down to intuition, and anecote because we have no practical way to quantify many of the important attributes (for all of the metrics you've mentioned, I can't think of any for which I'd have sufficient data). They're still useful for facilitating the decision-making process, but they're far too uncertain to rely on in the place of in-depth discussion.