Your Design Process?

[HokieTutorunie]

Curious to know what different processes teams use immediately after the kickoff.
If you have a specific process, perhaps with forms or documents, please share!
Do you break into groups or meet with the entire team in one room?
When do you start designing the actual robot?

Looking forward to your responce!

Steve

[ParkerF]

JVN posted this white paper over the design process we use after there was a question of this nature. It's a great read and is a great way to decide on different options. Hope it helps you out.

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

-Parker

[EricH]

I know 330's first step is to read the rules ASAP, often in small groups. The objective is to understand the game. Then it's off to simulate the game and see how it'll play out using different strategies.

[johnr]

I don't know. Considering how fast some teams got their robot done and posted here last year maybe we will just wait and see what pops up. Just joking.

[bigbeezy]

We split up into small groups and first go over the rules. We make sure that everyone is well aware of how the game is played and we look for rules that will affect the design or various strategies. Then the groups bounce ideas off each other and come up with a number of designs and present those ideas to the rest of the team. We usually finish off Saturday by mocking up quick prototypes to test different manipulators. Finally on Sunday we get back together to discuss the ideas again after people have had more time to think about the designs. We usually come up with a general design and then as the week progresses, better prototypes are tested and a more final design is determined.

[Akash Rastogi]

Originally Posted by francistexas

JVN posted this white paper over the design process we use after there was a question of this nature. It's a great read and is a great way to decide on different options. Hope it helps you out.

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

-Parker

I highly suggest this to any team. Try to mix and match techniques accomplished teams use such as 330 and 217 and add it to the pdf JVN posted a while back. We've adopted a lot from these teams and it has definitely helped us. Try it out.

[Paul Copioli]

Here is a Cliff's Notes version of what 217 does. Please note that we have a wierd situation that requires our design team to work in a different location than the rest of the team due to the donated facilities available to us. However, this formula can work even if everyone is in the same location.

Day 1 - Kickoff - Attend remote kickoff and build field (must build the field elements before strategizing). Small strategy sessions, but not really much discussed. Everyone reads the rules multiple times.

Day 2 - Sunday (the only Sunday planned work day) - Finish building field and strategize as an entire team. It is handled like a traditional brainstorming session with all ideas put on the board. We do not talk about designs at all, just ways to play the game and strategic elements we want to accomplish. We try to finish strategy session on this day. Last year was the first year since 2004 that we needed two days for strategy (we were very, very close to doing a mini lap bot).

Day 3 through end of week 2 - Design students (about 10 - 14) and I do robot design at FANUC Robotics product development lab using SolidWorks. We design every part in SW before manufacturing except the part that contacts the playing pieces. In addition, the remaining students work at the Ford Plant (our main home) either doing strategy (i.e. reading the rules to become experts), Chairmans submission planning, WFA planning, or prototyping. The prototyping team is broken into three or four teams to try different ideas for grabbing the work piece. The main responsibility of the prototyping team is to determine the best strategy for manipulting the work pieces. They are in constant communication with the design team. The design team will only design an interface to the grabber / manipulator and the prototype team is responsible for the rest. After the first working prototype is complete, then the design team will model it in CAD to make detail drawings for reference when making spares, etc.

Week 3 - Finish designing some parts and start receiving drive base sheet metal components from our sponsors. Also start manufacturig the shafts, brackets and gear lightening in our shop. We use the internal parts to the AndyMark gear boxes so we also start modifying some of those parts.

Week 4 - Receive manipulator parts and other longer lead parts and start assembling the robots (we build a practice robot). Drive base should already be completed and driving around debugging drive code and autonomous navigation. If not, there is always an old drive base lying around to debug code.

Week 5 - Cable and pneumatic routing and sub-assembly build. Debugging of manipulator code.

Week 6 - Driver practice and autonomous debugging. Driver practice and autonomous debugging. Driver practice and autonomous debugging. Driver practice and autonomous debugging. I think you get the point.

We have followed this model exactly since 2005 as 2004 was a complete debacle from the robot standpoint due to our lack of discipline during the design cycle. It is completely normal for us not to have one thing powered until the middle of week 5.

[Ryan Caldwell]

all of what Paul said

+

If your a rookie team and are going with a drive system similar to the kit bot it may be benificial to debug and test drive with a quickly built kitbot. at the same time doing your main design/prototype/build phase. this way your drivers will have even more stick time.

See what Paul said. Here's what I do for most of my projects, be they FIRST or otherwise.

Step one: Identify possible strategies. (ALL OF THEM!) It's important to nail every single possible method, so this stage should take a good 2 days.

Step Two: Decide on your strategy. For this, I use a Weighted Objective Table. I think there's a whitepaper on here somewhere detailing out how to use these. It's an excellent tool, so I suggest checking it out.

Step Three: Go nuts on a whiteboard. After I've found the general strategy, it's time to decide on mechanisms. Start general and work down to the specifics. First identify what needs to be done, and remember to keep it SIMPLE. If you can't do it in 2 ranges or motion or less, you should probably be re-examining step two. From here, work down to the details. Remember, less moving parts = less complexity and less failures.

Step Four: Sketch time! This is where I take the mechanism I've decided on building, and sketch it out several ways. It's good to take a highlighter to the sketch afterwards, and color code different mechanisms. This paper stage is to help me get a good grasp on what I'm building.

Step Five: CAD CAD CAD CAD! This is an extremely important step, if you'd like to be competitive. From here, I start putting my sketch into CAD one part at a time. It's important to start from the ground rules up. Start with your weight and size budgets, always keep these in mind. It's also important to design within your means while still being accurate. I suggest using the CAD for pre-fabricated mechanisms as often as possible; this will speed your design.

If you've got any more questions about CAD, feel free to PM me.

[mrbob1000]

we discuss what we want our robot to do and narrow it down to a few choices, then we have a table with a control being all zeros and we grade it against the control design with a -1,0,1 scale. Whatever design comes up the best is the one we use and that worked great for 08. My team has some pretty great mentors.

[Alex Dinsmoor]

Here is our (FEDS 201) design/building process:

1. Immediate Planning: After we attend kickoff, we go to an off site facility to go over all of the rules with the team. After there is a good understanding of the rules, we begin to toss around how we want to accomplish the goal at hand.
2. Robot Decisions: On the Monday after kickoff we get our whiteboard out and start drawing and listing. We finalize what we will do this year, and begin to draw out the design of the bot.
3. Physical Testing: When we have the design all made out, we begin to test the best ways to do things. For example, last year we used a plank of wood to symbolize our arm (you do remember that, don't you?), and used tables to hold the ball, and determined the best way to take the ball off of the rack.
4. CAD Team Unite!: Once we have a design down, the CAD team goes to work. They model the robot so we can build.
5. Designing the Code: The programming team creates a large flow chart to decide what they want to do and how to do it. They also create to-do cards. These help tremendously during the season.
6. Preparing the Code: At the same time the programmers are programming last years robot. This gives them a base code to modify for the new robot, so they don't have to scramble to make some code up, with a few weeks left.

Sure, this isn't everything; but it is all that goes into designing the robot.

[gorrilla]

wow, i was suprised that so many teams started the same day

we've always waited untill monday the 5th for our first "build-season" meeting

do you guys think that extra day is really worth it?(to get everyone there is a challenge for us)

[Alex Dinsmoor]

Originally Posted by gorrilla

wow, i was suprised that so many teams started the same day

we've always waited untill monday the 5th for our first "build-season" meeting

do you guys think that extra day is really worth it?(to get everyone there is a challenge for us)

Well the extra day is good to get the team informed about the rules, and their brains thinking. It isn't needed, but it doesn't hurt to start the same day.

And we get everyone there by promising them free food (pizza, salad, pop)

[MrForbes]

Starting the first day is good to get the ideas going, but we usually don't have a practice field element built until Monday...then the real work can begin!