View Single Post
  #15   Spotlight this post!  
Unread 23-09-2006, 21:57
KenWittlief KenWittlief is offline
.
no team
Team Role: Engineer
 
Join Date: Mar 2003
Location: Rochester, NY
Posts: 4,213
KenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond reputeKenWittlief has a reputation beyond repute
Re: Designing the Robot

Quote:
Originally Posted by InfernoX14
Is it everyone who does the most detailed Brainstorming?

Do the non-robot oriented team members take part in either Brainstorming?
On a professional project most companies choose engineers with a wide range of experience: HW, SW, mechanical, interconnects... and call them system engineers. These are people who understand the entire system that is being designed.

The systems engineers are normally the ones who take a new project through the first few steps of the design cycle. They work with the customer to understand what problem they need to solve, why its a problem, and then they put together the system requirements spec (everything the system is required to do to meet the customers needs). They may stay in control all the way up to dividing the system into subsystems, at which point the SW is handed off to a SW group, the HW to the EE's...

Then the systems engineers will be there at the end of the program to conduct the final testing, to make sure all the requirements have been met.

This would be a good approach for a FIRST team, to have only the experienced team members work on those parts of the design cycle, if your goal is to build the best robot in the shortest amount of time.

But..... ! Thats not what FIRST is really about - we want the freshman students, the rookie team mates to see what its like to be an engineer, so you have to include as many people as possible in as much of the design cycle as possible.

Quote:
I'm trying to get specifics including numbers of people who are involved with the design process because when we have everyone do it, it doesn't seem to work.

This is what we did last year

1) Recite the rules
2) Play games with students as robots
3) Split of and design sections of the robot
4) Present ideas

After that it's just arguing over who's is better. It was down to belts as our shooter vs 1 vertical shooter. We didn't even split off and design the loading mechanism, the hopper, or the gathering mechanism. It just sort of fell into place.
over the years engineers have worked out ways to avoid the arguing phase and the followup finger pointing phase. There is a process called Data Driven Analysis that helps you sort out complex issues.

your first step: recite the rules. Thats the normal place to start, but dont leave it at that. The games are often complex and confusing. You need to map out, chart out, graph out all the possible ways of scoring points, against the number of teams on the field, and maybe one or two possible starting conditions, and see what your possible score will be depending on your strategy. For example, in last years game if you built a shooting robot there was one possible high score, if you build a side goal scoring robot, you had a different possible high score, and if you built a goalie robot that could climb the ramp....

and the starting conditions would be things like: all 3 robots on your team are shooters, or all goalies... or all other possble combinations. This is starting to sound like a big task? Yes it is. But you can usually put together a spread sheet, or someone can work out the equations and you can graph it all out, for all to see, which strategy is the best one.

This will clearly point you to one big WHAT for your robot - what you want it to do, in order to win the game. That whole issue is put to rest (its done!) and there is nothing to argue about.

Likewise there are ways to analyze design ideas. This has been talked about in other threads. The output of your free flowing brainstorming sessions should be evaluated one by one and ranked (scored) for design criteria like: simplicity, robustness, ease of repair, need for custom parts, need for invention (you have an idea but you dont know how to do it), cost, time to build, interdependance on other subsystems....

then each design idea ends up with a score. The one with the highest score is the best approach for your team. And once again, when you are done, you are done with this part of the design cycle, and there is nothing to argue about, unless someone wants to argue that 27 actually is higher than 93!

Last edited by KenWittlief : 23-09-2006 at 22:05.
Reply With Quote