Quote:
|
Originally Posted by Don Rotolo
Complexity for the sake of complexity is the wrong path.
If the simplest way to do something just ahppens to be complex, then, well, complexity wins.
For example: Controlling the speed of the shooter. You can use a gear tooth sensor in a feedback loop to maintain a certain speed, or just let it run open loop with a fixed value to your victor. Both accomplish the task, and unless the open-loop version has a quantifiable drawback significant enough to affect performance, it is the better solution.
Rememberm adding complexity also adds to cost, time, and detracts from reliability.
My 2 cents advice is to define the tasks, design the basics as simple as possible to accomplish the tasks, verify the system, and go. IF (and only if) there is still time (and weight!) you can 'fancy up' the system.
For the learning experience, that's what the off season (i.e., right now) is for, sop you don't have to figure out how to make it work during build season. Get the GTS code working now, not in February.
Don
|
You are making very important points. The complexity of the robot should not be the top priority.
The team should decide on tasks that they want to accomplish and then they need to figure out how they want to accomplish them. Once they come up with some ideas they will see which ones are complex and which ones are not. It is up to them to make a conclusion on the road that they decide to take.
The game each year presents teams with enough of a challenge that they do not need to go out of the way so that their robot can be too complex. This also applies to the amount of tasks a team attempts to accomplish. For it is better to do one thing very well than it is to attempt to do many things at a lower caliper.