Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Robot Design: If there isn't a vote, who makes the decisions? (http://www.chiefdelphi.com/forums/showthread.php?t=123383)

weberr 19-12-2013 08:16

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 08:46

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 09:36

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 09:38

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 09:49

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 10:01

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 11:38

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

Originally Posted by cadandcookies (Post 1314389)
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 19-12-2013 12:10

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 12:15

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

Originally Posted by Oblarg (Post 1314607)
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 19-12-2013 12:16

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

Originally Posted by Chris is me (Post 1314565)
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 19-12-2013 12:27

Re: Robot Design: If there isn't a vote, who makes the decisions?
 
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 19-12-2013 12:49

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

Originally Posted by seg9585 (Post 1314609)
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 19-12-2013 13:50

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

Originally Posted by Oblarg (Post 1314627)
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 19-12-2013 13:53

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

Originally Posted by MechEng83 (Post 1314647)
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.


All times are GMT -5. The time now is 08:41.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi