[David Brinza]

Originally Posted by Dave Flowerday

On one hand, I'm relieved, but at the same time, I'm worried. Again, I think this is a rule to attempt to level the playing field, but really I think it just helps more experienced teams that are better equipped to get their robot done early to allow software testing.

I also want to know more details: are we allowed to tweak our "practice" software then show up at competition and "redevelop" those same changes on our "competition" software? How does this compare to the mechanical side? Mechanical groups are allowed to design new components, build and test them, even though they can't bring them to the event. I hope the same would apply to software, although it's more of a fuzzy line. Is thinking up a new algorithm without implementing it considered "software development"? I know it is as far as my employer is concerned.

I think FIRST is going to have a hard time defining "software development" - especially with an English-like scripting language available to the teams. The gamut for software development runs from defining software requirements or problem-statements (just thinking about what the new software will need to do), to writing a "psuedo-script" (documenting the solution to the problem statement) ,to actual coding and compiling (performed in the IDE), to test/validation (running it on a robot).

There's no way that FIRST members aren't going to spend time in the first phase of software development (can you really NOT think about how the robot will be more effective in autonomous mode after shipment or between competitions??) If you write down your thoughts on how to run your robot in autonomous mode (and English is your choice of language) - you've developed a pseudo-script. The actual coding and compiling are now just a stone's throw away. Finally, there is testing...the part of software that seemingly never gets done well enough because there isn't enough time.

There's one aspect about testing autonomous mode software that really needs to be considered - safety. There's a need for a really safe environment for teams to test new code. The practice field and other space at regional competitions aren't as easy for a team to control as their own robot development space. If a robot makes a wrong turn with a tetra in its grip, someone near the field might get whacked (if they're not paying attention).

Teams like ours that have built code from scratch have learned the hard way how dramatic the result of a minor bug can be. That's why we built second robots for driving practice and software testing and everyone pays attention the first time new code is executed.

It will be interesting to see how this topic evolves...