Designing the Robot

[Dan Petrovic]

Not sure what forum this is supposed to be so...

How is your design phase dealt with?

I ask this because the past two years (the years I have been on the team) we have had what we call "design by committee". Groups of 3 or 4 students go off and design certain parts of the robot ie. shooter, gathering, chassis, ect. and then everyone comes back, presents their idea, and we decide from there. The problem we have with this is that our team can't agree on anything. So we're looking into changing the way we designing the robot.

How do you do it, and what are your thoughts on it?

I didn't make this a poll because I couldn't possibly name all of the design styles that teams do. So please specifiy the way your team does it.

Thanks

[Andrew Blair]

Basically, work is prioritized, then attacked by the whole team. Move on to the next prey. Doesn't always work quite as streamlined as it sounds, but when it does, it really flies. But we have a relatively small team, so we need relatively few side projects to keep everyone busy. We can commit and keep people interested.

[chris31]

Last year we let everyone come up with ideas and then everyone vote. This was a tremendous failure for us as everyone had ideas (some good some bad), they all took time to explain them, and then we couldnt agree on an idea. This year I am thinking of a new way to do this process but im not finish figureing out how.

[Adam Y.]

Perhaps what I learned in my engineering design course could help. The trick is first to think of the factors there are. Doesn't matter what goals they are as long as they are factors like cost, durability, ability to throw poofy balls in top goal, speed, or time to build. You next have to assign a number of a scale of one to ten to represent the significane of that attribute in the design with a one being the least important and a ten being the most. Next you come up with a bunch of designs. Rate each design based on the preceeding factors on the same scale based on how well it would accomplish those goals. Multiply the factors by how well each design accomplishes the goals and then add the numbers you get to a total score. The one with the highest score should be the one you should pick. Still pretty subjective but at least it's a way to organize the subjectivity.

[Jeremiah Johnson]

648 is a bit different. Everyone comes up with ideas and sells them to the engineers and pretty much the rest of the team. Then Ed, our head engineer, takes the ideas 10X further and works them out in CAD and Inventor and re-presents them to the team. Then we vote on them. Fairly simple, but it takes about a week and a half.

[Arefin Bari]

Here is how team 1345 designs their robot...

1) Right after kickoff the team meets back at the school, first thing students inventory the kop. Then we have a meeting about what everyone thought about the game and how we should accomplish the challange in 6 weeks.

2) Students are asked to go home and sketch up the idea they have in their mind.

3) Students present all their ideas and discusses with the whole team. The team decides what our robot is going to look like.

4) Students and I go home and come back with cad drawings as we build prototypes.

5) The robot starts to look like the way we predicted it would be...

6) ... and then the beast goes off to compete.

[crazykid234]

Try this and see if you like it:
When you meet to brainstorm, decide first on your strategy. After the whole team decides on that strategy it's much simpler to design a robot to accomplish that specific goal. If you have trouble getting everyone to agree, you may want to designate a tie breaker aka team captain, mentor, lead engineer, etc; someone who will finish the debate.

[Al Skierkiewicz]

We start brainstorming at kickoff as soon as the event is complete. Everyone is required to read the game manual (we recommend once each day). Then we break for luch and begin again. Same on Sunday and Monday, our general team meeting day. Parents are invited to give ideas as well. We also make up a model playing field and begin to play the game. Brainstorming continues everyday for the next week until we have a concept which we also test on the game board. Then we go into "What would Beatty Do?" mode, wondering what the other teams will do and what defense will be like. (This list grows longer every year!) By the end of the week we have a good idea what the robot should be able to accomplish and what kind of mechanism and drive system will be most effective. Startegy starts to get worked out here and then we go to the design board and other start building a proto robot base so we can proto design ideas as they are built. It also gives the potential drivers the chance to practice.

[Tom Bottiglieri]

Originally Posted by Budda648

648 is a bit different. Everyone comes up with ideas and sells them to the engineers and pretty much the rest of the team. Then Ed, our head engineer, takes the ideas 10X further and works them out in CAD and Inventor and re-presents them to the team. Then we vote on them. Fairly simple, but it takes about a week and a half.

I'm not quite sure I agree with that. While it is good to involve the whole team with decisions about the robot's main strategy and basic build features, it may not be best to leave a technical decision up to a commitee of people who really have no business voting.

I'm not saying that to put your methods down. I'm saying that because I have too many times seen a poor design win one of these so called "elections" due to people on the design team talking up their particular idea to others, or one design simply looking better than another in the CAD models.

[KenWittlief]

When engineering students first graduate and land their 1st job, they very often fall into a 2 step design process:

1. This is what we are trying to do
2. This is how to build it

after you have been an engineer for several years, and you work with senior engineers, maybe take some requirements specification training, design spec training, continuous process improvement training, then you eventually learn than design follows a cycle, the engineering design cycle.

Hooray for the CD search function! (I posted the text below previously so I dont have to type it all again)

the engineering design cycle:

1. there is a problem to be solved. 1st you must clearly define the problem (understand it), understand WHY this system you are designing is needed, and specify WHAT your system will need to do in order to be an effective solution. (example: our bot needs to pick tetras up off the floor and place them on the goals, and it needs to do this 10 times within 90 seconds - this is WHAT our robot will do) note that this is all focused on the game (in our program). how do you play the game? how will you score? how can you get the best score? The reason you must do this now: many teams will jump into the middle of the design of the robot in the first few days, and then a few weeks later they realize they are designing the robot to do the wrong thing.

2. you brainstorm ways to create a system, and you decide HOW your system will do the WHAT. (example: we will create a robot with two wheel drive that can move and pivot quickly, with an arm that raises up and down in 2 seconds or less, and with a claw that can grab a tetra from the top. This is HOW our bot will pick up tetras and place them on the goal). This is top level design - at this point you are not writing code, or choosing materials, or selecting motors.

3. you break up the system into mechanical, electrical, SW, sensors, user interface, and go through the WHY, WHAT and HOW for each of these subsystems. Each subsystem now looks like a smaller version of the design cycle. This allows people to focus on smaller parts of the big system. The person designing the claw doesnt have to worry about how the tires will get the best traction on the carpet. The subteams know what they must do to meet their part of the system design requirements, and how it will fit in to the rest of the system.

4. you create drawings and SW algorithms, wiring diagrams, sensor schematics... of what needs to be built. This is what most people think of as design (this is what new engineers want to do on day two of the project!)

5. you have your subsystems fabricated and assembled: this is finally the build stage.

6. you test the system to see how it works, and if necessary go back to any previous point in the design cycle to make adjustments or modifications, but only if necessary to make the system work as intended (not to change what it does).

BTW, there are 6 steps here, and for a well disciplined team, each step should take about a week! You could push the first 3 steps into two weeks, and allow yourself 2 weeks for build. I know some people are reading this and saying "thats impossible - how can we build the robot in only two weeks?" the answer is: How can you build the robot when you have not figured out WHAT its going to do yet, or HOW its going to do it?

The reason this is called a cycle: when you are all done with the last step your system is deployed. In our program this means it goes to regionals and plays in matches. At that point you will see new problems to be solved, things that could be done better, additional things that might be added to allow you to score more points, or play better defense. Then you go through the whole design cycle again for those improvements and modification - you dont jump back to the 2-step approach.

The main reason you follow this method is a human brain can only think of so many things at one time - and not many things! When you are still deciding how you want to play the game you cannot be writing SW control system loops. When you get to the test phase (last of the six weeks + your 1st regional) that is not the point to be thinking "we should have designed a shooter instead of a goalie - how can we change our goalie robot into a shooter robot....?"

One last rule for this: When you are done with one phase you are done with it - no going back, no changing your mind 3 weeks in. If you want to add stuff or change stuff it has to be on the next loop through the cycle.

For FIRST teams that means either after your FIRST regional (see how the robot performs in action 1st, then consider whether you want to change it) or its means storing up ideas for next years robot.

I know its tempting sometimes, usually around 11pm on a saturday, when something is not going well, to start thinking "instead of 2 wheel drive we should change to 4 wheel, or tank treads". Its temping but dont do it - starting over takes you back 2 or 3 weeks - you cant add two or three weeks to your schedule. Work the problem, dont flush the design and start over. If you do your next design may be worse than the one you abandoned.

One last thing I would add personally: Dont judge your teams efforts on whether you win or lose events - judge your team on how well your robot does what you designed it to do. Celebrate your accomplishments and take notes and learn from your mistakes.

[KenWittlief]

regarding how engineering design decisions / selections are made, there were some great examples in the linked thread below.

Most engineering groups follow a process to decide which design approach is the best, and its almost never a matter of people taking a vote:

http://www.chiefdelphi.com/forums/sh...sign+decisions

[Lil' Lavery]

Step 1-Analyze the Game
Step 2-Analyze potential game strategies and decide on strategy(on day 2 of the season, we meet and play "StuBots", where the students act as robots to try and get a feel for possible gameplay and strategy)
Step 3-Basic Design Brainstorming, make sure the whole team is involved
Step 4-More Detailed Brainstorming (start taking into account what is plausable and what isnt)
Step 5-Preliminary Designs, decide on conceptual robot
Step 6-Detailed Mechanical Designs
Step 7-Begin to Build

[Dan Petrovic]

Originally Posted by Lil' Lavery

Step 1-Analyze the Game
Step 2-Analyze potential game strategies and decide on strategy(on day 2 of the season, we meet and play "StuBots", where the students act as robots to try and get a feel for possible gameplay and strategy)
Step 3-Basic Design Brainstorming, make sure the whole team is involved
Step 4-More Detailed Brainstorming (start taking into account what is plausable and what isnt)
Step 5-Preliminary Designs, decide on conceptual robot
Step 6-Detailed Mechanical Designs
Step 7-Begin to Build

Is it everyone who does the most detailed Brainstorming?

Do the non-robot oriented team members take part in either Brainstorming?

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.

[Billfred]

Last year on 1293, we did a big read-through of the rules, then rattled off all the potential strategies we could think of for each aspect of the game (autonomous, offense, defense, and attributes desirable in all three). You can see my chicken scratch here. Once we settled on a general direction (in our case, a Kitbot-based 6WD shooter that could conceivably dump and load from either source), we more or less left each group to handle their part of the actual implementation. Since the whole team worked at the same times, we stayed in constant communication about what needed to change, what needed to be fixed, what parts were coming, what was missing, et cetera. The shooter group got delayed a bit, which prevented them from working out some bugs, but overall the arrangement worked pretty well if you ask me. Could it have been improved a bit? Sure. Do I lose sleep over it? Not really. Every season we learn a lesson (usually on Friday at Palmetto, in our case), and we come out better for it.

[KenWittlief]

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.

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!