How do YOU start designing?

No team knows the “right way” to start a design but everyone has an “our way”. What’s yours?

By the “silent vote” I mean something like what team 470 does.

After all rules are read, and questions answered, we are all given a small pack of sticky notes and asked to vote on generalized aspects.

For example in 2003, after the questions, a quick presentation was made using an Excel spreadsheet displaying the importance of being King of the Hill in a given match. Then we each were given a vote on:
“Stack Making” - “King of the Hill” - “Stack Smashing”, and combinations thereof. Stack Making got ruled out with most votes going into KotH and Smashing combination.

The next vote was on the general design. “Expand”, “Bulldoze”, “Flailing” were on the table. “Expand” and “Bulldoze” were close in running and “Flailing” was ruled out.

Next a large sheet of paper was rolled out over the table and everyone drew out non-scaled sketches of what they were thinking on how to expand and bulldoze. Mechanical know-how was not important. Then we had the “Cup of Speech”. (A red plastic cup). If you had the cup, you could speak, if not, you must be silent and listen. (This prevented pre-mature shooting down designs, and hurt feelings). After a quick explination of the sketch, we went around the table giving questions if we didn’t understand the concept, or pointing out a rule that would be broken (such as metal spikes on tires, for example).

When all designs were completed, many were very similar and each were given a number, in this instance we had 4 types. A vote was placed pitting the 4 against eachother, and we came out with a ‘winner’.

Our next step was “Make this design work” by the mechanical team. (Our mechanical team is composed of veterans and rookies who have mechanical experience and know the feasability of components, in terms of manufacturing ability, weight, and size constraints). After the mechanical team came up with a rough sketch, it was presented to the group for Q & A (Q & A was the first time mentors/engineers were a part of the design phase, as Questioners after students asked all of theirs).

Then we went to a redesigned robot from things pointed out by the team, and displayed a new product which was agreed on. Then we went to work and got the bot built.

As to the gearbox, it was a quick vote of “Power” vs “Speed” (since we weren’t going to be shifting), then the mechanical team made the gearbox by the result of the vote.

heres how 350 does it

  1. learn the game.
  2. everyone discusses what the best strategy is for the game
  3. split into groups (everyone is involved) to come up with a few different designs
  4. choose a design (based upon which is the simplest to make, which would work the best, etc)
  5. give the design to the mechanical team, who then does what I call “detailed design”. Detailed design is just what it sounds like. The mech team takes the basic design and figures out exactly how to build it. They make to scale drawings, labeling each part, including every measurement, etc. Basically the build the robot on paper (or on the computer).
  6. After detailed design, the mech team, captain, and assistant captain go through it once more, checking to make sure nothings missing. Then we start building

I have to disagree with your statement - there IS a correct way to implement a design - engineers usually use a design cycle that may have 5 or 8 steps to it.

To analysis what your robot need to do, there is a technique called Data Driven Analysis. for the FIRST program its easy to implement, because the problem is already defined (winning the game within the requirements and limitations imposed by FIRST)

so all you need to do is analyize the scoring system. Up until now what happens during the game is of no concequence to your score (unless you are disqualified) - so the only thing that really matters is where your bot is at the end, and where the scoring objects are at the end.

Its not hard to put together a spreadsheet that will cover all the possible combinations of scoreing - best possible score and worst possible score - for example, last year - if you had all the bins on your side, and in the scoring zone you got one point for each - if you built a stack that was the mulitplier - and you can graph out all possible combinations, including the extra points for KOTH

and you could also graph out your qualifying points (your score plus twice your opponents if you win, your score if you loose…)

then there is nothing to decide or vote on - the DATA DRIVES your design - the DATA tells you what will give you the most bang for the buck, what the most important function is, the second most, the 3rd most…

for most teams if you focus on two primary functions you will do well (the top two). If you have a larger team and more resources you might try to implement three functions

for last year the data told us:

  1. we had to get to the wall quickly and knock more than half the bins on our side - this is because the basis of the best possible score was having more than half the bins on your side of the playfield - this defined the two most important functions: A. we had to get to the wall quickly in auton mode and B. we had to have a way to push more than half the wall on our side of the field.

It turns out that being able to push half the wall over also allowed you to push bins around on the field during manual play - and having a quick bot also allowed you to smack bots off the top of the ramp at the end

but the data told us the 3rd most important thing would be to push bots off the top, or to ensure a place at the top for KOTH.

If we had followed this approach last year we would have done very well - We had the top two functions covered - but a couple people on the team also wanted to be able to build stacks, and we gave into them and let them design a simple stacker

the result of this is that the stacker never actually was able to stack any boxes in any matches (or maybe we built a stack of two in one match). but the frame of it made our bot a little top heavy and easy to push over

because of this we were tipped over several times during auton mode and didnt do as well as we could have if the stacker wasnt on the bot. but it was an integral part of the frame and we could not take it off.

Data Driven Analysis is what engineers use to figure out what the system must do to meet the requirements and be successful in the real world. I strongly recommend that you use it, and STICK to the direction it drives you to. :c)

Yes, I do know of the Engineering process, but what I meant by “No Right Way” was that the way for Team X won’t always work for Team Y, sorry I didn’t clarify. Also, using the established Engineering process won’t always work.

then there is nothing to decide or vote on - the DATA DRIVES your design - the DATA tells you what will give you the most bang for the buck, what the most important function is, the second most, the 3rd most…

I do understand this concept, but it doesn’t always work right. The most ‘bang for your buck’ relies on being able to do the ‘big bang’ effieciantly and effectivly. Have a huge stack and being able to reach KotH was the 1-2 Punch to a win. But was nearly impossible.

The step after compiling the data is to see what is feasible. Because you really can’t get the Home Run bot (Master of all aspects), you do have to vote on which is easier to do effectively.

Since this is a public poll, I suppose I should justify my response before getting creamed for being the only “engineers make the decisions” person.

Well, in the past (in a nutshell):
As a team we analyze the game, then we basically brainstorm in small groups, then present ideas to the team as a whole. Then as a team we talk about pros/cons to each strategy.

Then we start breaking out some bot concepts, general ideas to fit each strategy.

Then, using a Weighted Objectives Table, the CU students make most of the design decisions. We present everything to the HS students, and usually they like what we’ve done, and where we’re going.

The Enginerds (or enginerding students) do the engineering. We show the HS students what we’re doing, and involve them whenever possible. Then we present the final product to the ENTIRE team, and see what everyone thinks… if we get the greenlight, we build.

This is just general idea of the way we’ve done things in the past.
I imagine things will be changing (again) this year.

Do it however it works, always strive to make it better.
Good luck to everyone in 2004…


Students spend one week designing.

We start out by going over the game and make sure everyone understands it.

Then we break off into small groups, each led by at least one veteran member. For a week, these groups brainstorm and come up with game strategies and robot designs to complement them.

The ideas are usually presented on Friday and the team basically finds a general design it likes then.

At night, the engineering mentors and some veteran members stay and finalize a design, making changes where needed.

the engineering design cycle doesnt always work?!


to use data driven analysis you have to design to the worst case scenearo, NOT to the best case / homerun / max possible score - that is not the proper way to use data driven analysis

but you are right in one aspect - DDA only tells you WHAT your robot needs to do to win - it doesnt tell you how

last year if you didnt get to the wall first and knock half the boxes on your side, you would have an uphill battle for the rest of the match ( you would have to get bins from the other side, where you cant see very well, and bring them to your side - very tedious and time consuming)

but if you cant figure out HOW to get to the ramp fast or HOW to knock half the wall over - thats another problem (step 2)

fortunately data driven analysis works here too - you can graph out how fast you can get to the wall with the amount of HP you have available for a 130 lb bot down to the min (50 lbs maybe?) you can graph out your acceleration for a curved path, a V turn, jumping over the railing…

you can perform tests and see if its better to hit the wall high or low, if you need something like wings or if a bar will take the whole wall down - to get some of the data for the design step you will need to do some experiments

but I guess thats what the whole program is about, right? if you know what the most important function is for a robot to win, and your team cant figure out how to build such a machine, then the better team will beat you - the team that can design one.

This is how our team does it.

On Saturday, we watch the kickoff, learn the game, and then open the kit of parts. The last thing we do on Saturday (about 5-6 PM) is split the whole team (11 of us this year) up into 3 groups of students. On Sunday, we come in at about 12:30 PM and stay till about 5 or 6. Each of the three groups starts working on what we call a “well developed conceptual design”. By well developed, we mean they should know what motor they are using for what mechanism and how it will “attatch” to accomplish the actuation. They should also be able to describe how each subsystem will fit in relation to all the others and plan for how much each subsytem will weigh. These three groups work independently with little or no comunication. Our teacher is always available and our engineer is sometimes available to help any of the groups.

The three design groups continue work on Monday and Tuesday afterschool from 2:30 until about 6. They make drawings, simple CAD models, and cardboard and wood mockups.

On Wednesday, the veteran members in each group make sure that the rookie members have a really good understanding of the design. This is because at about 6 PM on Wednesday, the rookie members from each of the three groups must present their design to the rest of the team. This is done so so that the people presenting are not so persuasive - rookie members generally aren’t since they don’t know that much about it yet. The presentations usually take about 45 minutes for all three.

Then, with our teacher and engineer(s), everyone talks about what is good and bad about each of the three designs. We talk about weight, space, cost, implementation, scoring, and performance. It usually takes a couple hours but then we pick from #s 1, 2, or 3, or make a #4 that implements subsystems from two or all three of the conceptual designs. By Wednesday at 9:30 PM, we have a FINALIZED conceptual design and have split the members into subsystem groups.

On Thursday, we begin detailed plans, models, and all that stuff. We are usually beginning calculations and exact measurements on Saturday (1 week from kickoff).

What I have just described above has been the best thing our team has ever done during the build. Week one was like easy as cake for us.

And then the next week it is rush to the catalogs to buy some parts. In week two, we usually spend at least two full days hashing out which wheels to use. The design of everything else usually depends on the wheels; at least on our team it does. By the end of week two, everything that will be making it on the robot is mocked up, calculated, measured, and integrated with the rest of the systems. Also, the basic structure of the chassis gets built in week 2.

Week three is machining/fabrication and some other stuff (I can’t remember what else since I do machining)

Week 4 is same as week three

Week 5 is assembly and temporary electrical. By End of week 5 the robot can drive around well enough and do something else too.

Week 6 is testing, programming, breaking, and fixing.

And that is our six week build! After like the first week and a half, it all becomes a blur to me and that’s why I couldn’t describe the rest better.

EDIT: One thing I forgot to mention is that somewhere along the way we do built field parts. But what else I really wanted to mention is that we draw a big chart of TO DO’s on the white board. It has the things to do, who will do it, and what time it will be done by. We also do a chart of subsytems that shows the cost, weight, space, time, people, and all that stuff.

Ok, I made my comment before figuring out all of my own points. The point I wanted to stress but didn’t is the Time factor for using DDA. 6 weeks isn’t enough time to use “Educated guess based on data” and check. You may have been able to stack in 2 seconds, and it seem like perfection, but it can come down just as easily.

My point is DDA and the Engineering Cycle takes Raw data and makes a path for a first draft of an idea. Then Real data is taken from the performance of the idea. Then the bell-curve is shifted from “Maximum” towards “Feasible” and a second draft is made. From this draft, new Real data is taken and compared to the first and the decision must be made for a 3rd draft. The 3rd draft is usually tweaking the second for better effiency and looks far different from the first.

How many drafts are made depends on a few things,

  1. Time
  2. Budget
  3. Profit Margin
  4. Manufacturability

With FIRST, most teams have a small budget where building two robots is unlikely or impossible. Also, we only have 6 weeks, which is usually time for tweaking a first draft. “Profit Margin” in this case would be chance to win matches, i.e. would it be worth it to try and build a whole new bot and maybe win 5 more matches through the season. Manufacturability is the “can it be done”. Amazing designs can be thought of, but having to use a “screwdriver as a hammer” won’t always work. (Using wrong tool for the job).

Next year, almost any team could make the “perfect” robot for the 2003 competition because there were 700+ “drafts” which real data can be pulled from.

Ken- can we start a new thread should this need to be discussed more? It’s Off-topic, but worthwhile.

Cyber Blue (Team 234) works this way.

We all attend the kickoff event to see and hear what the game is firsthand.

We then meet Sunday evening and talk about the game, the rules, the assumptions, scoring, etc. Our only focus is on the game and rules.

The next 2 - 3 days we begin brainstorming. All students have input. All ideas are written down. Once we have exhausted ideas, we break into smaller groups and each group prepares their best choice for a robot.

All of these groups then come together and each group presents their robot. We discuss, critique, review and try to identify strengths and weaknesses of each idea.

Then we form a “Rubric” - a grid of each feature and its’ importance to the game and the way we want to play. This helps identify the most important features and we set a priority of capabilities for our robot.

From this, we agree as a team on the path to build. Sometimes the engineers lead this final step to be sure we have something buildable, but we work hard to keep all students involved.

Sometimes we do preliminary design and build work on systems ‘just in case’. Some of these end up on the robot, some do not. (for example, in 2003 we had a brake mechanism that worked really well but fell to the weight reduction sword about week 5).

We then begin formal design and building as subsystems are completed.

We continue to regroup and talk about what is working and what is not and trade-offs that have to be made.

For 2004, we are implementing 4 mini reviews. A concept review, preliminary design review, critical design review and production review are planned. All but the critical design review (CDR) are informal. The CDR is a formal event with the students making a complete presentation. We invite a team of senior engineers (not associated with the program) to conduct our reviews.

Each team has to find what works for them and their ‘culture’. THis process has worked for us in the past and we are implementing a few enhancements for 2004 to make it better.

Basically - we write down ALL the ideas - than play the 'Round Robin game until we are left with one…

Atleast that is the way they did it when I was still there…:slight_smile:

I think we are talking about two different things and calling them Data Driven Analysis

simply, it means instead of sitting down and taking your best guess as to what you should do, you analyise the available data and let that make the decision for you.

For the first step, the data is the scoring of the game. There is only one way to get the max score under the worst case sceanario - and thats WHAT you design your robot to do - its primary function

it doesnt matter how well your bot is able to do that function - the game is still the game and it doenst change - if you cant do the most important thing then your team is not going to win most of the time.

Maybe I should start a separate thread on what data driven analysis is and how to use it.

What ever looks best when built with duck tape and cardboard!