How do YOU start designing?

[JVN]

Originally Posted by Gadget470

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

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...

John

[Yan Wang]

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.

[KenWittlief]

the engineering design cycle doesnt always work?!

EEEEEEEK!

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.

[sanddrag]

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.

[Gadget470]

Originally Posted by KenWittlief

the engineering design cycle doesnt always work?!
...
but you are right in one aspect - DDA only tells you WHAT your robot needs to do to win - it doesnt tell you how

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.

[Chris Fultz]

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.

[Matt Attallah]

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...

[KenWittlief]

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.

[T967]

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