[EricH]

You forgot one.

Gotta make sure that it's simple enough that a bunch of mechanical types can use it--at least at a basic level--without too much hassle. Not all teams have an army of programmers... I'll drop that in the very last spot, though.

Anyways, the topic at hand.

1) Reliable radio connection. Until FRC goes fully autonomous, if the radio isn't working, the robot isn't working. If the radio isn't working, you paid HOW much to sit there?*
2) Durability. A banged-up controller doesn't do anybody any good, and FRC hits hard.
3) Price. Cheap enough that just about any team can get another, via discount if need be.
4) Boot time. Note that this is of the system and of individual components. If one component takes 2 minutes to boot, and the rest is under a minute, replace that component with a faster bootup!
5) Software reliability. Lots of libraries, not a lot of bugs, as bulletproof as possible to guard against the aforementioned mass of mechanicals pressed into service as programmers.
6) Processing speed--needed for more complex instructions.
7) Code space--large user code, or lots of libraries loaded, need lots of space.
8) Code download time--can you load code between finals matches if you need to?
9) Compactness--as a mechanical, a small control system is a good thing, because we don't have to work around it. Or, failing that, small components that can be spread out throughout the robot--sometimes it's a lot easier to deal with a flood of small items.
10) IO capabilities. More ports, more motion, more feedback, better control.
11) Radio bandwidth. (insert geezer comment about back in the day when we could only dream of robot-eye-view in the driver's station here, you don't know how easy you kids have it, etc.)
12) Tie: User RAM and clean programming interface.


*A common point made when dealing with dead robots that may have been the field's problem--you pay $5K for the first event, $4K thereafter. Roughly $400 a match at minimum, not counting all robot costs. Too high to just sit there...