Quote:
Originally Posted by MrRoboSteve
What effects would this change to the rules have on software quality?
H. Teams may operate their ROBOT for the purpose of testing software updates.
I purposely left out fixing the robot in the new language.
|
Minimal, at best, and it might actually make it worse.
As pointed out, no fixing (or other electro-mechanical work, presumably) would be allowed, thus as soon as something broke, no further testing of software could be done.
But... most upgrades of software tend to work with (and follow after) upgrades in hardware. No upgrades in hardware mean software doesn't need upgrading.
And there is one other item that I can see happening. This is why I think it could become WORSE code, not better.
--A team could, theoretically, upload a base code right before the bag that has driving disabled, make one upgrade (enabling the drive code), and spend the rest of the allowed time "testing the upgrade"--which to everybody else is "driver practice". As a side note, a good, practiced driver can often do at least as well with lousy code as with good code--just a touch of compensating needed maybe.
__________________
Past teams:
2003-2007: FRC0330 BeachBots
2008: FRC1135 Shmoebotics
2012: FRC4046 Schroedinger's Dragons
"Rockets are tricky..."--Elon Musk
