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