How do you make design decisions as a "team"?

[Peggy Painter]

This has been our rookie year and, as of last night, our team is still eating meals together so we're not too bad off.....however, as the group leader (and a NEMO! ) my big challenge has been trying get the group--kids & adults to communicate their ideas and to make group decisions, especially on design matters.

I'm trying to keep our group a kid-led group, however the kids aren't technically skilled enough or developmentally ready to do everything and I'm afraid that when adults make suggestions the kids are reluctant to contribute. And I have noticed that kids & adults (myself included) can get emotionally attached to our design ideas.

How do other teams work through the process of developing a design & build plan?

Is there a standard process amongst engineers for collaborating on team building projects?

Do any of you mentors go to sleep at night after a meeting and NOT wake up in the wee hours concerned about how things went?

[Jim Wilks]

Originally Posted by Peggy Painter

Do any of you mentors go to sleep at night after a meeting and NOT wake up in the wee hours concerned about how things went?

Now that's something I can definitely relate to.

[Techhexium]

I recommend you read JVN's "Using the Engineering Design Process for Design of a Competition Robot" paper. Although there is no "right" way to approach the design process, it will help you gain an understanding of how it could be done.

http://www.chiefdelphi.com/media/papers/2303

Also, his 2010 build journal can show the design process in action. It's a supplement to the first paper.

http://www.chiefdelphi.com/media/papers/2360

[Billfred]

We didn't have a formalized design process, just hashing it out with (occasionally heated) discussion and a blackboard. This does mean the louder voices get heard...but our team seems to attract a lot of loud voices naturally. In the event that we are absolutely, positively deadlocked, the final decision goes to Amadeo, who is the lead college student mentor. (He only really had to break one significant deadlock that I remember, that being the choice of our claw after the full-size prototypes were done in Vex.)

[BJC]

I'll try to give what little knowledge I have regarding design..

1. Figure out what your design goals are before anyone comes up with any designs. It is natural to immidiatly begin to jump to the idea stage after being presented with a problem. Refrain from this, redefine and specify the problem.

2. Make a list of priorities based on your redefined problem. A list of priorities in 2011 for tube hanging would have been: -drive around -aquire tube -get tube into scoring position -release tube Notice how being able to release a tube is useless without being able to effectivly aquire one. Thus aquiring comes first. Many teams fall into the trap of mixing up their priorities and end up with a robot that can't effectively play the game as a result.

3. Refine your problem again. Ok done? Now do it again. This is the most important part of the process. Even the best designed robot performs poorly if its solving the wrong problem.

4. At this point it's time to break out the Weighted Objective Tables. Yaaay! But seriously, use them, they help prevent "my-own-design-is-the-best-osis" and often make seemingly close and difficult choices obvious. USE THEM!

5. At this point you hopefully have a design thought out. Now go and make sure that your still staying true to the origional problem you defined. It probably isn't; fix it so it is. The design will become simpler as a result--that's a good thing.

6. Alright, your done! You have a successful design. Just kidding! Now do this again three times.

Doing these things as a team makes for a very successful robot. Good Luck!

[rsisk]

Probably the best lesson I learned last year from our friends The Holy Cows (1538) is that design follows strategy. Before you even think about design decisions, make sure you know the best strategy for the game. A lot of time knowing your strategy will eliminate a lot of design decisions.

[jamie_1930]

Originally Posted by BJC

I'll try to give what little knowledge I have regarding design..

1. Figure out what your design goals are before anyone comes up with any designs. It is natural to immidiatly begin to jump to the idea stage after being presented with a problem. Refrain from this, redefine and specify the problem.

2. Make a list of priorities based on your redefined problem. A list of priorities in 2011 for tube hanging would have been: -drive around -aquire tube -get tube into scoring position -release tube Notice how being able to release a tube is useless without being able to effectivly aquire one. Thus aquiring comes first. Many teams fall into the trap of mixing up their priorities and end up with a robot that can't effectively play the game as a result.

3. Refine your problem again. Ok done? Now do it again. This is the most important part of the process. Even the best designed robot performs poorly if its solving the wrong problem.

4. At this point it's time to break out the Weighted Objective Tables. Yaaay! But seriously, use them, they help prevent "my-own-design-is-the-best-osis" and often make seemingly close and difficult choices obvious. USE THEM!

5. At this point you hopefully have a design thought out. Now go and make sure that your still staying true to the origional problem you defined. It probably isn't; fix it so it is. The design will become simpler as a result--that's a good thing.

6. Alright, your done! You have a successful design. Just kidding! Now do this again three times.

Doing these things as a team makes for a very successful robot. Good Luck!

This is pretty good, but it's missing one important step and that is to do what you keep saying not to do throughout these steps. After you're done saying that it's not time to put up designs right now we're trying to find what we're doing....you need to put up designs. I feel like every year our team has tried to follow exactly these 6 steps and what we end up forgetting is what is missing from these steps, after you know what you are doing you need to figure out how you're going to do it. And it is because we don't get to the how of things as a group that most people are kept out of the loop of what is really going on with the robot outside of their sub-project, communication is key.

Design is something that people say they want to finish within a couple days or 2 weeks of build season, but that is completely insane. Design isn't done till the robot is done, actually it's still not done then. After that you need to figure out what is wrong with you're robot and fix that too, because design is repeated over and over. It's the whole Design->Build->Break loop that continues until your boss says we need to start making this product ("shoot the engineer"), or in our case competition day (and then after that for many teams the next and next and next competition).

Although what you're referring to is how do we do this initial design. For this, at least for FIRST, you need to figure out what is your goal during the competition....well to win of course (and have fun and learn too). How do you win? There are numerous ways and first you have to narrow down what you're focus is (well most teams will have to do this some teams can do everything, but for most teams just remember "jack of all trades, ace of none"), develop a strategy, how are you going to play the game. Find what kind of strategies will be effective in the game and decide what your path will be, and it may not be what you want to do, but instead think what you should do, what could you're team do best.

For example this year 2228 kept most of our focus on building a robot that we thought would be able to score on all pegs. But anyone who was at FLR noticed that half the time we never moved our arm, it was zip tied down, because every time we tried to use it the thing broke and we were out for the match. Instead we focused on defense, until the last 40 seconds when we lined up for the minibot. The minibot in our initial design meetings was shunned. The mentors wanted nothing to do with it, but being the captain of a local FTC team I made sure we kept it as an option and even though it was our last priority we did it and it's what got us into the finals.

Next once you have figured out what you want to do, often there are several different things and like it was said earlier you need to prioritize these objectives. Weighted Objective Tables are great for this, in most people's opinions I'm not a fan, but they must work if everyone loves them....right? Now that you have you're objectives find out how you're going to accomplish them. This is where you get to have the fun of busting out different designs that you've been formulating ever since the first 5 seconds of the game animation. Then look at these different designs and find out which will be best (Weighted Objective Tables again). Now you should have a basic idea of the robot collage, what's it going to be. Once you have this start to fit together the pieces and make you're finer dimensions.....I hope this helped shed some light on the process, but all I can say is that no matter how you plan, or plan not to design the robot it's not going to work out the way you thought. You have a bunch of teenagers in a room trying to collaborate and they're going to find a way to mess up you're plan (trust me I'm one of them). Just go with the flow and try to stay on track, keep things productive and have fun with it.

For design, know what works, and what doesn't. Prototype EVERYTHING!!!

To find out what works, go to chief delphi! Most people I've talked to from other teams said they got their roller claw ideas and design (down to the shape of the claw and the types of wheels used) from various threads on chief delphi.

After all, we're all FIRSTers so we're here to help you!

[Aren Siekmeier]

As BJC said, make sure to well define the problem you're solving before starting to solve it. Most people would call this your game strategy. There are some useful exercises here, including human role playing, adapting old robots to see what kind of chassis and drivetrain features might be useful in getting around the field.

Once you know what you need to do, figure out how. Inevitably, there will be lots of different, great ideas. Some of these can be weeded out soon on based on complexity or feasibility, while others can stick around to be prototyped. And I'd like to emphasize something I've found from our build seasons: If a student or group of students is advocating an idea, but its still in abstract form, it stands no chance. They need to (maybe not fully, but mostly) spec out how their design will work so that it can be assessed in terms of cost, weight, interfacing with the rest of the robot, and prototyped. This year, I felt that our robot's overall design was very much defined by who stuck around to develop their ideas, rather than what ideas were shown to be the best.

Effective prototyping can help fill in a Weighted Objectives Table in a way that isn't fudged based on people's predispositions. We tried WOTs on day 3 with very little background information, and we had to abandon the results. I have never had a whole lot of success with them, but I believe that is why, so I still have faith in them (if used correctly) as a mediator of all the design ideas that people can become emotionally attached to. A scientific approach saves the day.

[tim-tim]

As mentioned by others, strategy should drive your design process.

How do we effectively eliminate ideas without hurting feelings? Take the "feasible" ideas and put them through a selection matrix with all the factors you are considering. The best solution will become visible through the highest number, and then give you alternatives based on your ranking for each task. This will give you the direction of the best 2 or 3 ideas to prototype and then come back for a second evaluation and make a decision.

Side note: Please don't let the mentors/adults stray to far away. We (the mentors) are there to accelerate the students desire and ability to learn. Otherwise, the students are not benefitting the FIRST Experience as much as they can or should be.

[Al Skierkiewicz]

Peggy,
The suggestions on strategy first are very important to driving design. When discussions get bogged down, prioritizing helps. This year for instance, we discussed the relative advantage or disadvantage to picking up tubes from the player station or from the floor. When we used students to play the game, it became obvious that a human player can be fairly accurate in getting the tubes downfield, which shortens the time to score. Once picking up from the floor became a strategy choice then design followed. Some of you have noticed that we did not use crab this year. Again a strategy decision led us to believe pushing and speed were prime for this game. As a result, platform stability was achieved with wider spaced wheels, allowing for high peg scoring in minimal time. This robot was perhaps our fastest ever. When in the design phase it helps to layout all ideas on a white board and then look at the relative merits of each. Is this design faster, more robust, easier to program, easy to maintain? Some parts need to be prototyped and that is part of the design process. Some decisions are driven by experience either from your own team or those of others. At some point all of this brainstorming causes allows some design ideas to rise to the top. It is easier to make choices when there is less to choose from.

[Emily_2337]

What our team does is when we first get the game we look at it and make sure we fully understand it. You have to make sure you know all the rules, what you can and can't do. Then after we do that our team starts to think of strategies of the game. Offense vs Defense , the different ways to score, and Speed vs Power. You have to focus on WHAT you want to do not HOW you are going to do it. The main thing is let your strategy dictate your design not the other way around. Also you might want to focus on one or two things so you can be really good at a few things then being average at many. Our team has our head mentor call on people to tell the group their ideas so everyone gets a say. After we have a big list of them we put the strategies in most important to lest and we start to narrow them down. From there it's up to your team to talk about how your will design will fulfill your strategy. Team 2337 wishes you good luck as a team.

[mathking]

First I would just like to stress that in my view, the posters who talked about deciding on strategy first are right on target. On the question of how much freedom to give the students a lot of it depends on your team culture. Our team gives the students a lot of leeway. Probably more than most. That's OK for us because it is part of our team's normal operating procedure. We have more than once let students wander down a path I suspected would have to be changed, because all things being equal, they learn more when they fail. (To be fair, I try to always have an implementable alternative ready to go in these cases.) But it is also true that quite a few times something I and the other mentors thought would not work actually did work very well. There are some very smart, creative kids doing FIRST. But you have to be wary of this approach too, if the kids and/or mentors aren't used to it, you can fall behind rapidly or have a lot of hurt feelings and general disgruntlement.

What helps us is having student leaders who help guide the discussion, design and prototyping process. In particular the student leaders work on the proof of concept stage. Once that is passed and we settle on a general design the mentors take a more active role. At least most years. Since we have mostly college student mentors, our mentor knowledge base varies. For example last year we had really only one mechanical engineering mentor, and she was new to ME. Fortunately our student engineering director was one of the best FIRST students I have ever had, and he basically filled the role of a mentor for mechanical stuff, allowing me to keep to the big picture view. In any event, if the student leaders are good, they will help distill all of the ideas into some good, solid designs the team can discuss and choose from.

Which brings me to the big picture view. When you give the kids more freedom, you have to make sure that someone among the mentors is both keeping track of the big picture, and making sure that the kids are thinking about how everything is going to work/fit together on the robot and strategy wise. It is really easy for the designers of each component to be drawn down the path of "it's just one little change" so many times that things no longer work together. (Heck, this happens with engineers too, just less frequently.)

Just remember that you are not looking for the right way to design a robot but a way that is right for your team.

[Mark Sheridan]

Originally Posted by Peggy Painter

I'm trying to keep our group a kid-led group, however the kids aren't technically skilled enough or developmentally ready to do everything and I'm afraid that when adults make suggestions the kids are reluctant to contribute. And I have noticed that kids & adults (myself included) can get emotionally attached to our design ideas.

Since most people addressed strategy, I will discuss the brainstorming after. I notice too, that people get very excited about brainstorming ideas. Students and mentors want to skip the strategy and become very attached to their ideas. I have to hold everyone off to focus on strategy, so when we switch to brainstorming, its like a dam bursting.

One thing I repeat over and over again is that to evaluate ideas independent of their originators. One has to run the balance of recognizing credit when its due and keeping the design discussion objective. I encourage everyone to not be attached to their own ideas but open minded of others. I also encourage collaboration.

We usually have a giant board of ideas. I would suggest you to have people to draw out their ideas on paper so that they can't be erased. I would keep the ideas board up all season, because sometimes you need to revisit ideas later. I also feel this rewards students better, because maybe their idea was not picked but it made it to the board. I encourage my students to generate as many ideas as possible and get as many ideas on the board. They get pretty motivated to help the team fill the board.

I have several rules to keep the discussion harmonious:
1. No idea is a bad ideas. Any ideas can inspire the wining idea. Also "less successful" ideas can reveal potential pitfalls and show us roads we should not go down. It ties in to students creating as many ideas as possible, because more ideas help our team have a more complete picture of possible solutions, even if the quantity is daunting.
2. No torpedoing ideas. All ideas have their pro's and con's but if one is going to be critical, one must have a real justification. (I usually caution students about being critical, most catch on that if they have reservations, they pose it as questions in case their instincts or reasoning are wrong)
3. If you can't draw it or explain it well, it can't be made. One can waste a lot of time trying to figure out what the idea actually is. (this can be a rough one with students, this is where mentors jump in to help the student in question, during a break in discussion)

When actually grading ideas, we use evaluation matrices or pro/con lists generated from the strategy discussion. Usually, we use pro/con to narrow the list and evaluation matrices for discussing the narrowed list of ideas. What surprises me, this has been the fastest part of our design process for the last few years. My students have been very efficient and timely in their discussions. Which is opposite of their mentors.

Lastly, a few tips. I try to come up with the worst ideas possible the break the ice in the design discussion. It lightens the mood and gives students more courage to present thier ideas since they can not do worse than their mentor.

Lastly, every time there is a rule book update, we hold a design review. We are pretty lucky and never had them last more than a hour.

[Grim Tuesday]

Let me preface this by saying that we have a very large, 50+ person team. We pride ourselves by being student run, and students are a driving force behind the robot, building it, and designing it. So much so, that we consider Mentors, while extremely valuable, to be essentially the teams safety net.

We have concepts of Brainstorming to follow, based directly on the PLTW curriculum:

1.) Quantity>Quality; once you have a lot of ideas, you can sort through them to get the best
2.) Piling on; Add to others ideas, don't take possession of it
3.) No criticism; we can pick out infeasible ideas later

Now onto our actual process, on Kickoff day, we recognize that everyone's minds are going crazy with ideas, so there is just a freeform discussion of anything. Groups are broken up into, with between 5 and 7 people, each including a mentor. During this time, we would like people to be thinking of how the game works, but in invariable breaks down into "this would be a cool robot" discussions. We would like to, this year, play a "practice game" in which each person assumes the role of a robot, and the team observes, to see how the game is played, though our team has never done this before.

On the first day of the season, Monday, new groups are broken into, and strategies are brainstormed, following the same rules. At the end of the night, the team votes on which strategy we will go with, prioritizing various areas. Mentors do not get a vote, though they certainly have a lot of influence in the decision.

The next few days are spent in yet new groups again, where each one designs essentially a whole robot. It has various parts. Eventually, these are presented to the team, and the subsystems are broken apart, each one being voted on separately. Eventually, we have a whole robot decided on.