This is a great way to open things up, in the open source sense of the word.
In fact, the next time the control system is updated, I think a very good architecture would be to have a custom and closed radio for FRC, but to open everything else up 100%. Actuators would be the exception, but even these might be opened up at some point in the future.
The radio would be hardened for FRC, would have several 1G Ethernet ports (industrial connectors), and would also have several “safety” CAN ports (more below). The radio would support quality of service and enforce a per-priority-level bandwidth limit on the wireless transmit side (the field would do the same on it’s wireless transmit side). Because it is expensive to get FCC certification, the radio would be built around an off-the-shelf WiFi module and would likely have firmware based on OpenWrt.
The radio could also have antennas selected for optimal performance in the context of FIRST and would continue to handle things such as encryption. In addition, the radio would support connectivity between Ethernet and CAN, with quality-of-service and bandwidth management. Because of where it sits, and because it is closed, it could ensure no spoofing of safety packets on any of it’s CAN busses.
There would be a “standard” compute module which most teams would very likely use, but the safety case would not rely on any level of trust outside of the radio. The driver station S/W would have support for collecting diagnostic information from the radio, and also probably from the standard compute. For example, this module could be a future NI RIO. Significantly, something like CANifier could handle all of the I/O for things such as sensors, replacing the need for a custom FRC compute module with dedicated I/O pins.
All actuators would be required to be controlled via CAN, and to automatically disable within a short amount of time if they are not continually receiving enable packets on the CAN bus – there might not even have to be an explicit disable packet, but one could be defined.
At this point, the safety rule becomes that all actuators have to have their CAN port connected to a CAN bus with only approved CAN devices and a CAN port on the radio. Note that multiple CAN busses are good for reliability, especially in the face of wiring problems, and also for increasing the overall CAN bus bandwidth.
Any compute with Ethernet connectivity is allowed (weight, power, etc. rules still apply). It gets an Ethernet network on the robot and with connectivity to the driver station, and can also get to one or more CAN ports to communicate with actuators. Now, any compute is legal and safe.
At any rate, things done by teams along these lines will provide more of the good things that are part of the FIRST experience. I’m hoping things will explicitly move more and more in this direction. I’ve tried to send these suggestions in to FIRST previously, BTW. But, I’ve not been in a position to respond to any control system RFC, when these have been issued. However, I’m very happy to explain how this would all work, for anyone who is involved in things on this side of FIRST.