Robots by committee

[Gui Cavalcanti]

This year I've been having some issues with this topic, and I just wanted to get some opinions.

Should a robot be designed by everyone on a team, or a select few? What tests/qualifies "the elite" from everyone else? Is there team bitterness if you have the elite design a robot?

I'm not just talking about engineers designing a robot, I don't want to make this thread into one of those arguments. I'm talking about having a core of people who are acknowledged to be better at design, design the robot, as opposed to every single person on the team having individual input.

I don't know where I stand. On the one hand, there's good old fashioned democracy, everyone has a say. However, if everyone on the team has a different skill level, this can quickly boil down to a haphazard, patched together robot. Then there's the core designing a solid, together robot while other people watch. Argh...

[Jeremy_Mc]

Originally Posted by Gui Cavalcanti

This year I've been having some issues with this topic, and I just wanted to get some opinions.

Should a robot be designed by everyone on a team, or a select few? What tests/qualifies "the elite" from everyone else? Is there team bitterness if you have the elite design a robot?

I'm not just talking about engineers designing a robot, I don't want to make this thread into one of those arguments. I'm talking about having a core of people who are acknowledged to be better at design, design the robot, as opposed to every single person on the team having individual input.

I don't know where I stand. On the one hand, there's good old fashioned democracy, everyone has a say. However, if everyone on the team has a different skill level, this can quickly boil down to a haphazard, patched together robot. Then there's the core designing a solid, together robot while other people watch. Argh...

Typically we group, make designs, then present them to everyone. The nonsensical and unfeasible ones are weeded out semi-democratically. Whoever can find a problem brings it up and it is addressed. If it's a major problem, the design is discarded. Then the designs are narrowed down to 2-3, presented with a discussion of pro's and con's, and voted on.

This process takes 2-4 days depending on how alike your team thinks

[Gabriel]

I think that Churchill said something like "democracy is the worst system of government ever devised except for all the other ones."

Giving everyone input and making decisions by a large committee will enable you to hear a wide variety of ideas and it will make everyone feel good about their place on the team and maybe will give them a better experience in terms of FIRST's goals of Inspiration and Recognition of Science and Technology. On the other hand, large groups take a long time, don't have the experience, or necessarily the brains of a few select individuals and might very well end up making the wrong choice. Which system you use should depend on your goals for the team.

The absolute WORST thing to do is to say that things will be done democratically, but then either reject the groups decision or get fed up with the amount of time they're taking and make the decision yourself. And if you give a few people lots of responsibility - don't take it away from them unless you absolutely have to. I've seen mentors do both these things and the results are disastrous.

[KenWittlief]

there is no such thing as democracy on a real engineering project - why try to introduce it on a FIRST design cycle?!

in the real world you always have a program manager or project leader, who has more experience than the rest of the team, and that person has the final say on everything.

As for designing your robot - first thing (that should have been done 2 weeks ago) is to analyse the game, determine which tasks will score the most points, and decide, in priority what functions your robot will have. Our team decided being able to gather balls from the floor and get them to the human player is the top priority. Second is being able to knock the release ball off the tee, third is being able to manipulate the 2X ball, 4th is being able to do the chinup, and last is being able to drag the mobile goal around.

next step is to brainstorm possible solutions for HOW your robot might do each of these things. at this point anyone on the team can toss up ideas - go through the list of functions your robot will have, and come up with possible ways of doing them

next step is to rate each solution based on a number of criteria. Compair each proposed solution to the others, and rank them according to which is the most effective for doing its assigned task, which is the least technically challenging to build and test, which is most reliable, which will be easiest to maintain and repair, which will take the shortest time to design and build, and which is the most versital and functionally flexible

you can do this by having your team vote on all these items, then see which approach get the best score overall.

And, like magic, your team has chosen its design approach. You might have a team leader step in and say that one particular idea is not feasible, or would be too hard to create, and veto that one idea, but in general your whole team will have walked down a logical pathway together to reach a consenses on what the best concept is for your bot.

Once you get to that point, then a lot of responsibility falls on the engineering mentors and the experienced team members. There is not a lot of time for experimenting and learning - it really is necesssary for the experienced people to take the lead when fabrication begins - but by the time the robot is done the new people will understand things well enough that next year, they can take the lead.

[Spikey]

Last year we suffered greatly from our inability to choose a design early. This was mainly due to our overuse of the committee system which led to designs that would never work being brought up multiple times. We were to democratic which created a 2 week design phase that had accomplished nothing. By the last week our indecision hurt us big time, we tried to cram an overcomplicated drive train onto our robot which had not been tested at all which failed miserably. Two drive trains later we finally built a rudimentary 4 wheel drive system that was very underpowered. It was so weak that the rear wheels could not even pull the robot up by itself. So we learned a lot from last year.
This year we decided on our design in 3 days and our prototyping has been very successful because we have enough time. By weeding our crazy ideas from the start we are getting things done a lot faster

[Rickertsen2]

Originally Posted by KenWittlief

there is no such thing as democracy on a real engineering project - why try to introduce it on a FIRST design cycle?!

in the real world you always have a program manager or project leader, who has more experience than the rest of the team, and that person has the final say on everything.

As for designing your robot - first thing (that should have been done 2 weeks ago) is to analyse the game, determine which tasks will score the most points, and decide, in priority what functions your robot will have. Our team decided being able to gather balls from the floor and get them to the human player is the top priority. Second is being able to knock the release ball off the tee, third is being able to manipulate the 2X ball, 4th is being able to do the chinup, and last is being able to drag the mobile goal around.

next step is to brainstorm possible solutions for HOW your robot might do each of these things. at this point anyone on the team can toss up ideas - go through the list of functions your robot will have, and come up with possible ways of doing them

next step is to rate each solution based on a number of criteria. Compair each proposed solution to the others, and rank them according to which is the most effective for doing its assigned task, which is the least technically challenging to build and test, which is most reliable, which will be easiest to maintain and repair, which will take the shortest time to design and build, and which is the most versital and functionally flexible

you can do this by having your team vote on all these items, then see which approach get the best score overall.

And, like magic, your team has chosen its design approach. You might have a team leader step in and say that one particular idea is not feasible, or would be too hard to create, and veto that one idea, but in general your whole team will have walked down a logical pathway together to reach a consenses on what the best concept is for your bot.

Once you get to that point, then a lot of responsibility falls on the engineering mentors and the experienced team members. There is not a lot of time for experimenting and learning - it really is necesssary for the experienced people to take the lead when fabrication begins - but by the time the robot is done the new people will understand things well enough that next year, they can take the lead.

I can't agree more. I don't think anyone could describe things better. In the case of ruling a country, a democracy might be the way to go, but in FIRST there just isn't time for such a thing and to tell the hard truth many people on a team don't really know what thye are doing enough to make decisions. This doesn't eman that we exclude them. We have a sort of Oligarchial system very similar to what Ken described, and it is workign quite well.

[Gabriel]

Originally Posted by KenWittlief

there is no such thing as democracy on a real engineering project - why try to introduce it on a FIRST design cycle?!

in the real world you always have a program manager or project leader, who has more experience than the rest of the team, and that person has the final say on everything.

Yeah, but FIRST isn't supposed to be just an engineering project, its supposed to be life in a microcosm. Certainly there are many valuable reasons to have an oligarchical system - its very efficient for one, and the right people usually are the decision makers. However, the goal of FIRST isn't necessarily to build the best robot, its to inspire kids and the best way to do that is what Dave Lavery said at the kickoff - don't say "go sit in the corner and watch us and you'll learn something" but give them as much of a role as possible. Each team has to decide how to strike a balance between efficiency and quality and giving kids the best experience, but every team leader and mentor should keep in mind that its easy to praise an oligarchy when you're the oligarch.

[Paul Copioli]

The way Ken describes it is exactly what our team does. Our entire team goes through the selection process of what is important to us and rank the top 4 or 5. Usually the top 3 or 4 make the weight limitation.

After the selection of what, the design team consisting of students and engineers from mechanical, electrical, manufacturing, and software sub-teams figure out the how. About 1/2 of our team actually works on the robot. Believe it or not, the other half wants to do other things like PR, picking out marketing items, community involvement organization, etc. This has worked very well for us the past 3 seasons and we utilized this plan this year.

By the way, that is pretty much how it happens during a development cycle (with a few small exceptions).

[JVN]

Paul and Ken covered pretty much everything I would say, but I just have one thing to add.

In my experience, every major robot design has one "driving force" behind it. Be it one or two engineers working together on a concept. The actual robot usually ends up turning out similar to the "vision" of this "driving force".

Design by committee, hasn't worked out for me. Instead of an awesome unified robot system, you end up with a collection of systems. Sometimes they don't even integrate well together.

With one major "vision" systems can be combined, one mechanism can accomplish several goals. The collection of parts becomes -- "An elegant merging of form and function" (I love that phrase).

$.02

John

[ShadowKnight]

Our team last year made the mistake of going after the actual design and the nitty gritty (kind of) of the design instead of focusing first on what we wanted the bot to do, and deal with the physics later. We also had issues about organization because we had "comittees" but we met at the same times and people intermingled a bit mroe than they should have. The main problem was that we had a group of 30 people deciding whether the best way to stack was using a belt to bring up the boxes or a clamp and a plate to stack. This burns up extremely valuable time. We did not have the vaguest idea about how we would build our robot untill 2 weeks into our timetable, and it was only sketchy at that.

It is my belief that once the team decides on the basic design, those involved in the build team need to split off into their seperate groups and draw stuff out on paper, then come together so that we can combine stuff. This year, that stategy worked very well. We have a drive train and basic frame team, and an arm team, both of which are networked so that we have an idea abotu what the other is doing but we can do our own thign and focus on what we do best. In my oppinion, our team needed desperately thsi kind of organization because without it, we all go our seperate ways and nothing gets done. Ultimately, their needs to be a deciding authority. WHile that needs to be someone either than the mentors, it does need to be a person, or a few people, so that decision can be made, and made within time to implement those decision.

those are my two cents...

[Chris Fultz]

We had the entire team at the kick-off and involved everyone in the concept definition phase. Thru brainstorming and small group work, we have a conceptual design that the whole team has arrived on together. Once we agreed on a single design, we broke into component teams, each with an engineer, lead student, draftsperson and other members. Others are working on drafting parts, macining, electronics development and PR / marketing. The more experienced students work the detailed design with the engineers.

I believe the role of the program manager should be to assure the team is staying on schedule and getting things accomplished - not to make all the decisions.

[ShadowKnight]

our team this year is small so with onyl a few exceptions, practically the whole team is on build anyway...

Aye, I totally agree that those who manage people should not take over other people's job, They should make sure that everyone is directing their ability and potential into the team project so that a finished product will come out on time for crate date.

[Eugene]

I agree with most of the posts on this topic. Here is what has been going on with my team.

There were a few people who came up with designs and tried to push the team to consensus. As always the arguments broke up. The first one was determining if it was possible to heard the balls with the bulldozer. This was crucial because if we could bulldoze the balls then we could also have the space for the 2x ball manipulator. After a few days of arguing in circles I got tired, ran down to the gym and got a few basketballs. By attaching a prototype plow to our old robot we tried to push the balls though a classroom door. Our result was that we only got three balls in ten minutes. That effectively showed a need for a more complex mechanism to deal with the balls.

Nevertheless, there were people who wanted to combine both features. I felt that we lacked the resources to implement both designs. After another day of arguing, I finally sat down and wrote everything that needed to get done this year. In the end there was not enough people to build the 2x manipulator.

Anyhow, here is my conclusion. Usually there are very few people on the team who have engineering experience (that is taking a concept and making it work) and plenty who can come up with general ideas and lack experience. My standpoint is that it is the duty of those few who know to enlighten the rest. When the final decision on the design comes, everyone on the team has to be behind it. It will be tough six weeks. The team needs to act as one. If talk stales, start writing things down to clear the disagreements up. If the problem is that you feel the design or the strategy is unfeasible – test.

Of course, if all fails have a deadline by which the person in charge will make his decision. After four year of FIRST I noticed that in the end it is almost never about which design you pick out of the few general ones, but how well you do it. The more you drag the talk, the less time you will have to perfect whatever you chose to do.

Eugene

[tenfour]

Our team splits up into 3 design groups. AFTER 4 DAYS, we then present the design to the whole team. The vet. members then select one design. It is fair that they vote and not the rookies since they have exp.

THE CATCH IS THAT ONLY THE ROOKIES FROM EACH GROUP ARE ALLOWED TO PRESENT THE IDEAS. THIS KEEPS THEM IN THE LOOP.

[KenWittlief]

Yeah, but FIRST isn't supposed to be just an engineering project, its supposed to be life in a microcosm. Certainly there are many valuable reasons to have an oligarchical system - its very efficient for one, and the right people usually are the decision makers. However, the goal of FIRST isn't necessarily to build the best robot, its to inspire kids...

I didnt give too much detail on the process we followed for the things I listed.

We attended the kickoff at RIT, and our plan was for about half the team to meet in a classroom there after the kickoff presentation to analize the game and scoring, and to have some students attend the various workshops that were being held at the same time (SW, controls, pneumatics...)

we were worried that none of the students would want to sit through the workshops, but the opposite happened, only one student DIDNT want to attend a workshop - so two mentors and one student poured through the manual and got the basics of the game and scoring down, created some graphs, and then when the rest of the students came back we went over the game with the whole team. It was quickly obvious from the scoring which functions would be most important (WHAT the robot had to do to score the most points in the worst case sceneario).

So there wasnt much dictation to the masses there - the game itself drove the conclusions.

At our next meeting we sat infront of a big whiteboard as a team, went over the scoring again, and listed our priorities - (collecting balls was most important...) then we let everyone throw up ideas on HOW the bot could do that, with the rule that no negative comments are allowed (thats stupid, or that wont work, or thats against the rules...).

then we put some meat behind those ideas, gave some thought to how each proposal might be done, drew up some system concept drawings for several of them, and let the whole team vote on the criteria I mentioned in my last post.

so nowhere in this process were the engineers off designing the machine, while the students were sitting in a corner surfing the web. FIRST is about engineering, this is how real engineers brainstorm new systems and reach agreement on how to proceed.

To me, design by committee would be like doing the brainstorming thing, where wild ideas can be tossed up with out critisism, but then not downselecting based on their merits - if you let everyone add their little idea or subsystem to your robot, so that you can be democratic and let everyone design a piece of it on their own, you will start out trying to design an off road motorcycle and end up with a greyhound bus that has ten wheels, 6 engines, and is towing 2 trailers full of subsystems as your 'motorcross' machine.

The number ONE rule for mentors on a FIRST team is this, "DONT let your team fail!"

if you show up at an event with a bot that wont work, or if you fail to ship by the deadline, your team will not be inspired towards anything - they will think engineering is a hairbrained seat-of-the-pants way of doing things that is frustrating, impossible to understand and that it totally SUCKS!

No one is inspired by that.