[cgmv123]

Originally Posted by apalrd

Since we're (mostly) engineers on CD, let's think of this as an engineering problem. There is a supplier-customer relationship where FIRST is the supplier (of the control system) and the teams are the customers (of the control system).

The customer must have requirements for the supplier. The basic requirements for an FRC control system by a team are:

-Must be easy to setup for a very inexperienced team. Even if the manuals are clear, complex systems are inherently easy to misconfigure even if the directions specify how to do it.

-Must have a boot time of no more than (x) seconds for the entire system. I would be willing to exempt the DS only because I know how slow Windows is. This time limit is to the advantage of teams who want to run quickly, and the field crew which can recover from errors more quickly.

-Must have a certain amount of minimum functionality that can be achieved with minimal computer skills by a team - I would include a requirement for a certain amount of default code, at least mapping JS axis/buttons to motors and solenoids, since I know how many teams previously relied on default code. For some reason, the current control system lacks this and I don't really like it.

-Must be protected from unauthorized interference - I believe this requirement previously existed but was not fully met. I will discuss this later.

-Must have certain safety checks implemented - Specifically loss of communication with driver station, crashing of team code, and network error. Currently the first two are not implemented well, the third is implemented with a packet CRC which is good.

Good requirements? I think this covers the basics.

I think you're forgetting advanced functions, speed and customization for advanced teams. It can't be so simple that advanced teams can't take their robots to the next level.