Designing the Robot Schedule

[DonRotolo]

I (and others) have posted on this topic before. Poke around and you'll find a lot.

The short answer is that no schedule can really be kept perfectly, but without a schedule you'll find yourself scrambling more than is healthy.

If you learn anything over the years, it's Design First, Build Second. We all want to get to the solution step, but you need to define what you will do to win the game, what capabilities you need to do that, and what mechanisms you need to get those capabilities.

Only then can you consider building anything.

Give yourself a week to design everything - including prototypes and proofs of concept. Build in weeks 2 and 3, iterate in week 4 to finalize everything. Hand that off to programming, and build another exactly like it but without the 'mistakes', and that's what gets bagged in week 6. If you take 'exactly' to heart, your drivers can practice with that first robot (this is the key to a winning team BTW).

[Doug G]

Originally Posted by DonRotolo

Give yourself a week to design everything - including prototypes and proofs of concept. Build in weeks 2 and 3, iterate in week 4 to finalize everything. Hand that off to programming, and build another exactly like it but without the 'mistakes', and that's what gets bagged in week 6. If you take 'exactly' to heart, your drivers can practice with that first robot (this is the key to a winning team BTW).

Well said. This is the basic timeline for most winning teams.

We make it a pretty big priority to have a 1st robot done by week 4. Even if you don't have much money to build a 2nd robot, just make the first robot out of old parts, kit bot, wood, etc. Then get it right for a great 2nd bot, the one that goes in the bag.

Also reiterating weeks 7-? seems to be a common winning approach these days as well.

[Pault]

Originally Posted by DonRotolo

Give yourself a week to design everything - including prototypes and proofs of concept. Build in weeks 2 and 3, iterate in week 4 to finalize everything. Hand that off to programming, and build another exactly like it but without the 'mistakes', and that's what gets bagged in week 6. If you take 'exactly' to heart, your drivers can practice with that first robot (this is the key to a winning team BTW).

Sure, many of the top tier teams do this. But it is not necessary to be successful. And I would argue that for 95%+ of teams, this is unrealistic. And if your in that 95%+, trying to do this is going to hurt more than help. You will end up rushing your CAD so you can get people to start building. And a practice bot costs a lot of money. It would be better if you just took the time to do things right with one robot. Maybe finish it around week 4-5, and use the rest of the time for programming, driver practice, and iteration. And you can do very well.

[tickspe15]

Our schedule has been evolving over the years but last year we found/stumbled into a sweet spot for our team. During week one we work on rule comprehension, game point analysis, and basic prototypes to determine difficulty of tasks, we also finalize our drive train and order the cots parts necessary During week two we work hard to prototype all the subsystems and determine one or two designs to peruse for each. Then during week three we finish prototyping and create a semi final cad model, we meet less this week due to finals. During weeks 4 and 5 we kick into high gear and finish our practice Bot and weld it in house to improve the turnaround time, then once we know the design meets our standards we make any necessary changes and then send it out to be welded by our sponsor (much prettier). We then have week six to work on programming and driver practice.

the reason we are able to have a seemingly fast build for the final robots is because we use cots products wherever possible. For example we use the kop drive unless we have a very good reason to do otherwise, we have done swerve drives, mechanum, and custom tank drives in the past but have noticed that our robots over the past 10years have been more successful when using a kop or similar drive.

[cadandcookies]

Originally Posted by Pault

Sure, many of the top tier teams do this. But it is not necessary to be successful. And I would argue that for 95%+ of teams, this is unrealistic. And if your in that 95%+, trying to do this is going to hurt more than help. You will end up rushing your CAD so you can get people to start building. And a practice bot costs a lot of money. It would be better if you just took the time to do things right with one robot. Maybe finish it around week 4-5, and use the rest of the time for programming, driver practice, and iteration. And you can do very well.

You would do well to back up your assertions with actual data instead of generalizations.

In product design, there's a triangle of budget, cost, and schedule-- changing any of them affects everything else. Being able to get a robot done (and build a second robot) is about careful management of your triangle-- in order to fit building two robots into your schedule and budget, it might be necessary to cut back on the scope of what you want to accomplish. For most teams, this is actually probably a good thing-- we call it "KISS!" It may also require more meeting time or more work to be done outside of meetings-- something which may or may not be feasible.

Sure, if most teams tried to build 254's aptly named "Overkill," much less two of them, they would most likely not end up in a good way-- but the assumption that you have to build a complex or otherwise "difficult" robot before you can try to build two is one I think is made too often (certainly by me and my team before...)-- if you plan on building two robots before the season starts, it becomes part of your design requirements: "Is this part/mechanism simple and cheap enough that we can make enough for two robots?" Many teams this year probably could have benefited from creating a simple plywood and bucket shooter (like Team 3313's excellent 2013 robot) and building two robots instead of one more complex robot with a larger "scope." I would argue that the several extra weeks of "refine-time" would be more beneficial than adding extra functionality or complexity.

Overambitious project requirements are the bane of both FIRST and real engineering projects. Avoid them, especially when you're designing your own project.

[tim-tim]

As promised earlier, I have found our Training/Planning Brief that was presented to the student leaders and mentors prior to the 2013 build season.

I have also found our Week 1 Requirements document that we made at the conclusion of week 1 discussions. These were our initial reactions and thoughts about the game.

Let me know if you need any further clarification.

[DonRotolo]

Originally Posted by Pault

Sure, many of the top tier teams do this. But it is not necessary to be successful. And I would argue that for 95%+ of teams, this is unrealistic. And if your in that 95%+, trying to do this is going to hurt more than help. You will end up rushing your CAD so you can get people to start building. And a practice bot costs a lot of money. It would be better if you just took the time to do things right with one robot. Maybe finish it around week 4-5, and use the rest of the time for programming, driver practice, and iteration. And you can do very well.

Paul,
We used to believe this as well, but deep investigation found it isn't true. As cadandcookies wrote, simple is the key. But there's more:

We don't have the rest of the team waiting for CAD...everyone is CAD. (But I will admit we build first and document later, kinda backwards from what we would prefer)

The second robot always comes out better than the first, so even if you re-use all the expensive parts from the first robot you would still end up with a better robot in week 6, along with more time for programming. Fabrication goes quickly the second tme.

It is worth repeating: The key to a winning team is driver practice. Good drivers can compensate for a very poor robot.