View Single Post
  #12   Spotlight this post!  
Unread 25-06-2015, 20:57
EricH's Avatar
EricH EricH is online now
New year, new team
FRC #1197 (Torbots)
Team Role: Engineer
 
Join Date: Jan 2005
Rookie Year: 2003
Location: SoCal
Posts: 19,798
EricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond reputeEricH has a reputation beyond repute
Re: On the quality and complexity of software within FRC

Quote:
Originally Posted by MrRoboSteve View Post
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

Reply With Quote