1.
New 2009 Control System: The new control system should still run (or be able to run) with the C-programming used in the current controllers. Right now, with the Vex controllers having very similar architecture to the FRC Controller, the programmers can write and debug code (especially for advanced sensors like CMUcam) without having to worry about a 50lb FRC-scale test chassis running out of control.
1a. If the new controllers for 2009 will not run C, then a low cost alternative processor (similar with the Vex/Robovation controller) should be available to teams, and should be cross-compatible with the Vex/Robovation hardware for prototyping.
My suggestions for the new controller would be a basically upgraded version of the current controllers, with a more powerful/faster processor. A radical change in technology should be avoided, since many teams may not prototype ideas and advance their knowledge during the off-season if they suspect that all their work won't have any impact on future games.
Also, if new control system could adapt a new way of storing its onboard program that would be cool. Serial cables are becoming harder and harder to find on computers (especially laptops), and a new technology would be nice. One thought that came to my head is storing the program on a SD card, as many laptops and computers nowadays come with built-in memory card readers, and SD cards are one of the most common types used. (Idea being to plug SD card into computer, download code to it, pop SD card into controller, turn it on, and go!)
Or the SD card could also be used for more advanced CMUcam features, where images of what the camera sees (with crosshairs of the object centroid and a timestamp superimposed onto the image) could also be stored onto the card, to be viewed later on the computer.
2.
Sensors: Sensors are good! (If anything is to be changed about the sensors, add more of them to the KOP). Especially the gear tooth sensors, the gyro, the accelerometer, and the CMUcam. Maybe if one or two IR short/long sensors could be thrown in as well, that would be awesome.
3.
Code development environments: Defintely keep EasyC PRO. If someone is looking for a more textual-based IDE, then MPLAB is fine. If anything occurs here, a Mac (universal binary) or Linux compiler would be a nice addition.
4.
CMUcam: Keep this as well, but include an "alternative" technology for autonomous. A good example was the 2004 season, there the IR beacon or line following could be used to get to the 10-point ball. However in future games, the use of the CMUcam to find the "better scoring" target, and an alternative technology to a "lower scoring" target, would be a nice compromise.
5.
Inter robot communications would be fun to tackle, but standardizing communications of some kind would be necessary. If every robot could broadcast a standard set of parameters* to be readable by other robots on the alliance, they that could open up some interesting ideas and concepts. (After all, drivers/coaches can plan and coordinate their actions before the match with the other alliance members; robots should be able to do the same thing for autonomous.)
* A short example of autonomous mode parameters: (most are 0 or 1 answers)
ATTEMPT_AUTONOMOUS = [0 or 1; yes = will try to attempt autonomous]
RUNNING_AUTONOMOUS = [0 or 1; yes = autonomous code is running]
AUTONOMOUS_GOAL = [pre-definied by game design committee. in this year's game, it could be something like 41, 42, or 43 if you were scoring on column 4 in row 1, 2, or 3.]
EXPECTED_SUCCESS = [0 or 1; if the robot thinks it successfully scored.]
et ceteria, et ceteria