I don't see why the communication has to be one (Wifi)
OR the other (900 mHz serial). With the technology available today FIRST should be able to implement multiple communications on the same system.
High Priority Task like the Joystick outputs to the robot, drive commands, Auton/Teleop modes, eStops, etc could communicate over a very fast booting wireless protocol similar to the Old Control Systems. The amount of data is very minimal and wouldn't need a lot of bandwidth. (Synapse or Xbee). I have personally tested a Synapse device, with a simple 2 axis joystick and two PWM outputs, to drive a robot with a boot-up and time to drive less than a second.
Low Priority Task and task that need a lot of Bandwidth could still communicate over Wifi (if teams want this functionality). This information and data would not need to be encrypted because it doesn't necessarily control the robot. If a team's wireless radio fails in a match, teams can still move and drive there robot in a open loop state.
The system could also be setup as follows:
Code:
{Robot}
| ^ |
v | v
Wifi Synapse
| ^
| |
| Commands
| ^
v |
Laptop -> Process Image
For all the computer/programmers, how many bits or bytes of data is really need to send the important data to and from the robot:
-PWM - 20 Channels (160 bits)
-DIO - 26 Channels (26 bits)
-Relays - 4 dual-input channels (8 bits)
-Analog Input - 8 channels (96 bits)
-Analog Output - 2 channels (24 bits)
-Miscellaneous Bits for Auto/Teleop/Enable/Status/ etc (22 bits)
Total = ~336 Bits = 42 Bytes
Seems like Wifi might be a bit overkill for the amount of data need sent from the drivers to the robot.
Personally, I believe that the long boot-up times come from the Wireless bridge/router that we use on the robots.
-Clinton-