Build Timeline

[AndyB]

Huh? Are you referring to us? We try and get ours done in week 4, but it never works out that way...

If you're referring to the prototype, yes, we do try to get a prototype done by the end of week 2. You can see last years prototype below in my signature. (3rd Picture). Its linked to view the full size pic.

[EricH]

Originally Posted by AndyB

Huh? Are you referring to us? We try and get ours done in week 4, but it never works out that way...

Not specifically. You've actually got a pretty decent schedule. It seems that many teams try to have a design by the end of Week 1 or before. You can get away with this, but only if you know exactly what you are doing. (And do a good analysis of the game right after Kickoff.)

And prototypes do need quick completion for a more complete analysis. 330 has been known to have provision for two drive types up to Week 6 on the competition robot--we just planned for both and made room. One system was onboard, the other on Kitbot until we had finished testing. (Not recommended unless you are sure you know what both options will look like.)

[AndyB]

The two years I was involved with the mechanical team (the last two), we tried new drives that we had never done. (06 Treads, 07 Crab). That could explain the reason for us prototyping a drive earlier. Then we can usually mount anything else we need onto it.

[dtengineering]

A typical team 1346 build schedule:

Week 0: (Pre-Kickoff) Carefully plan build schedule so that the programmers and drivers get two weeks to practice. Promise to "keep it simpler this year" and "spend more time on design, less time in the shop".

Week 1: Discover what the game is. Ask "how the heck are we supposed to do THAT?" Throw promise to keep it simple out the window.

Week 2: Start building. "If we spend more time in the shop now, we might have a week for the programmers and drivers to practice."

Week 3: Start re-building. Usually something is moving around at this point that bears some resemblence to the final drive train. Non robotics students are amazed to discover that the shop suddenly has a carpeted floor. Positive karma and good feelings balanced by impending sense of doom when we realize that we're halfway through and have only done "the easy part".

Week 4: Finish first draft of design. CAD team learns what "as-built" drawings are, build team learns that sometimes at 9:30 at night when something just isn't working right, that teachers have a slightly larger vocabulary than they hear during class time.

Week 5: It is all together but doesn't work right. Promise self to never do this @$##@ robot project again. Embrace panic in order to banish despair and frustration. Discover the part that doesn't fit, but has to, that local suppliers are all out of much needed parts, and that we have exceeded the build budget by 20%. Realize that Valentine's day passed without notice. Ooops.

Week 6: Weigh robot. Take it all apart again for speed holing. Put it all back together again. Repeat as needed. Programmers come through with a miracle yet again. Apparently they haven't been sitting on their duff doing nothing for the past month, despite build team's previously expressed opinions to the contrary. Drivers demonstrate that the robot can, indeed, dent lockers and move large tables. The more tools and instruments on the table, the more likely it is to move.

Ship Day: Last minute panic to get everything into the crate and out the door. Much skipping of classes is involved. Remember important shipping documents and customs forms, but still manage to screw something up. Contemplate rest, but realize that Portland is a Week 1 regional and there are still details that need to be attended to.

Promise to do it "differently" next year.

Repeat as needed.

Jason

P.S. That was our "old" build schedule. We're going to keep it simple and be more organized this year so that the programmers and drivers can have two weeks to test and practice.

[Karthik]

Many teams have different philosophies when it comes to managing the build period. Before you can decide on a schedule, you need to evaluate the resources at your disposal. How often and how long is your shop going to be open? How many students and mentors will be participating? Are your suppliers local, or will you be shipping parts in? What's your team's level of engineering experience? Do you need to prototype extensively, or can you trust yourselves to start building sooner? These are just some of the many questions that need to be asked.

The following is a presentation on running a FIRST team, which has a section on managing the build season. A proposed timeline is given, which has been used with much success by many Canadian teams.

http://firstroboticscanada.org/site/...ps/runteam.pdf

It's an aggressive schedule, designed for use by low to medium resource team with a simple robot design. It also works well for a high resources team with a more complicated design. The schedule stresses finishing earlier, to allow more time for practice and tweaking. I've found that the amount of time spent practicing and iterating is directly proportional to a team's success. Teams who are less aggressive during build, often end up using their regional as practice and tweak time.¹ To me, that's an expensive way to spend $4000. (And if you're only going to one regional, like 75% of teams, this is not a good situation to be in.)

The design freeze is much earlier than most teams use, but this a conceptual design freeze. What that means is that you're settling on "double jointed arm vs. linear elevator" as opposed to the specific implementation. This can be determined during the prototyping phase, and modified throughout the practice and tweaking phase. The 1114 robots always undergo significant changes during the final two weeks.

I hope this helps.

1. In 2006, when we were testing our robot in week 5, we realized that our hopper had major issues with ball jams. We played around with it for a few days until we finally determined we needed a new subsystem, an agitator, to clear jams. The agitator worked like a charm, and was a major part of our regional success. At our regionals, we helped many teams design and build their own agitators. These teams discovered their ball jam issues during these regionals, because of a lack of practice and tweaking time. As a result, these jams drastically decreased their scoring ability. Just an example of how valuable tweaking time can be.

[Kyle]

Check out MOE's MOEmentum website. It has a time line for each week during build and even covers pre-season and post season.

[=Martin=Taylor=]

This is all great advice. I know we "try" to follow similar schedules

One thing that has not yet been mentioned is research. FIRST is not a new competition, over the last 13 years thousands of robots have been built. Teams have learned from each other and developed new systems for completing tasks (picking up balls, lifting things, moving around...).

One of the best things you can do after kick-off is go back and look at photos and videos of past competitions and learn from the success and failures of others. If you find a concept you really like, figure out how to make it better.

CD media and the FIRST Mechanism Library are great places to start.

[AndyB]

Originally Posted by Kyle

Check out MOE's MOEmentum website. It has a time line for each week during build and even covers pre-season and post season.

Why didn't I think of that. MOEmentum is one of the best rookie resources hands down.

By the way, here is a really good Powerpoint that Andy Baker put together a few years back for a workshop I believe.

http://first.wpi.edu/2006CON_Design_Process_Baker.ppt