As it seems that this should somehow make a difference, I, as well, write software for a living.
With that said, I have to agree with those agree that software is different than other components. Yes, I agree that software is a part of the robot, and, in fact, it is a integral and critical component. But it is fundamentally different than hardware.
I see a few arguments to that. One being that re-typing the code allows one to support this rule. But how is that really any different than copying/pasting, or checking out a version from your favorite source-code repository. There isn't a difference, other than potentially introducing typos that require more time to debug. This doesn't seem like a productive use of time for teams.
If you have a known good design/algorithm/function, why try to re-invent it. You only have to invent the wheel once, then you use it, because you know how it works. The same goes for Omni-Wheels, Transmissions, etc.
As said before, if the argument is that it is faster for teams to copy/paste or checkout a version than rookie teams, then how is it fair for teams to have CAD files that will generate all the components needed for a mechanical design at a moment's notice.
The rule says this:
Quote:
|
However, the specific lines of code must be customized for each robot each year.
|
Since no game is going to be the exact same each year, this is going to always be true. The code will have to be customized for that game. As Jack eluded to, I doubt there will be PoofBall throwing robots next year. BUT, I can definitely foresee teams needing to track lighted objects on the field. To have to completely re-write that from scratch, as others have inferred, would be pointless AND difficult.
Each year is a learning experience. And each year, teams learn and perfect various pieces of their robot. To have to force team's to re-perfect any component each year, be it hardware or software, seems like a step backwards in where this program is aiming to go... to create those that go one step beyond.
-Nate