[Dave Scheck]

Originally Posted by Marc P.

By the same logic, how many students know anything about embedded processors and microelectronics? What do students learn from Innovation First's robot controller designs? Should teams be expected to build their own operator interfaces/robot controllers/radio modems?

I think you may have misinterpreted what I was saying. My point was that if the interfaces are defined well enough, the internals of the module don't necessarily need to be known in order to incorporate it into the system. With the RC example, in the typical case, you don't need to know the exact details of what's going on inside in order to program it. Obviously there are reasons for wanting to learn, but every detail isn't required. The nice thing about reusing code (not binaries) is that you have access to what's going on under the hood if you need to know more than what the interface provides.

But to preserve complete customized team modules from year to year in a copy-paste fashion seems to defeat the purpose of having a programming team for each year. All it would take is one original team to write the code, then hand the flash drive down from season to season.

I disagree. The chance that the entire codeset will be used from year to year is extremely slim, but the chance that a team will need to count wheel ticks from year to year is more feasible. There will always be customization that needs to be made, but the internals of the low level building blocks could stay the same.

But you can't honestly compare custom robot code to globally standard library files or universally accessible code in terms of carrying over from year to year.

Why not? If a team writes a library that will simplify the interaction with a sensor, I see nothing wrong with using it from year to year. Instead of interacting directly with the sensor, future programmers would interact with the library (to which they would have the source code for reference).

The purpose of the rule is to prevent teams from maintaining the same code base from year to year, thus putting programming groups out of a job.

Your statement would also be an argument for not releasing default code because it would put teams that only need the default functionality out of a job.