|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||||
|
|||||
|
Re: Build Timeline
I believe Andy Baker did a nice presentation on this in Atlanta a few years back for the championship. I'll see if I can find a link.
It seems we've always gone with this on 269. Day 1
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
This definitly varies from year to year, but this seems to be the best starting point. Some years like last, we worked on the drive all the way into week 4 and really didn't finish assembling the robot and uploading the finished code until people were sitting there yelling at us that we needed to crate the thing. |
|
#2
|
|||||
|
|||||
|
Re: Build Timeline
You guys are fast! It only takes two weeks to build a robot, IF you have planned carefully. A typical season for 330:
Kickoff--see the game, read the rules, discuss with as many people as possible. Week 1: During the weekend of Kickoff, simulate the game at full scale if at all possible. Analyze options. Figure out a winning strategy. (Repeat last step as necessary--If you can beat a winning strategy, you probably have a better winning strategy). Week 2: Finish any loose ends from Week 1. If the requirements list isn't finalized yet, finalize it ASAP once the loose ends are tied up. Mockups are made and evaluated. Start design if possible. Week 3: Design the thing. Get materials. Week 4: Build. Week 5: Build. Week 6: Finish build and get to the programmers early. (At least, that's the plan--it has happened on occasion!) End Week 6: SCRRF Preship Scrimmage. Ship. We do fudge it a bit, notably in 2005, when we cut our first metal at the end of Week 4 with the robot completely designed and an arm being evaluated, and 2007, when we had our strategy in about two days and a practice robot by Week 3--but part of the robot hadn't been designed yet (something about "that's a secondary function, wait for the primary to be complete first")! We still had the whole thing just about ready by ship. |
|
#3
|
|||||
|
|||||
|
Re: Build Timeline
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. |
|
#4
|
|||||
|
|||||
|
Re: Build Timeline
Quote:
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.) |
|
#5
|
|||||
|
|||||
|
Re: Build Timeline
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.
|
|
#6
|
|||||
|
|||||
|
Re: Build Timeline
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. |
|
#7
|
|||||
|
|||||
|
Re: Build Timeline
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.1 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. Last edited by Karthik : 02-01-2008 at 02:14. |
|
#9
|
|||
|
|||
|
Re: Build Timeline
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. |
|
#10
|
|||||
|
|||||
|
Re: Build Timeline
Quote:
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 Last edited by AndyB : 02-01-2008 at 04:52. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| vex timeline? | Morenoh149 | FIRST Tech Challenge | 2 | 17-10-2005 17:50 |
| Timeline, The Book | LBK Rules | Chit-Chat | 6 | 07-12-2003 09:31 |
| timeline | archiver | 2000 | 1 | 23-06-2002 22:08 |
| Regional Timeline | archiver | 2000 | 2 | 23-06-2002 22:08 |
| Timeline? | Pengiun Joe | Chairman's Award | 2 | 27-01-2002 16:35 |