Very cool if you can help us solve this. It was a common way to execute a few different things, and write all of the data to disk on the driver's station.
Here are the streams of data through the architecture. Note - Node.js also splits off a MongoDB write of the data it receives:
- Robot Data: RoboRIO -> FMS Network -> Node.js on D/S -> Java or Web GUI
- Vision: Camera Image -> FMS Network -> Vision Process on D/S (Java) -> Node.js on D/S -> FMS Network -> RoboRIO
- Autonomous selection: Java or Web GUI -> Node.js on D/S -> FMS Network -> RoboRIO
I'm not sure if everything is pub/sub, or if some things just poll the node server for the 'latest' data when it is needed. I do know that they had all three of these working at the school and in the pits, but not on the field since the RoboRIO could never get to the Node server on the laptop.
We had re-try logic in the RoboRIO, Node.js hardening for sudden stop/starts of connections, CORS, etc. We took the system through the flow of
- Power the untethered robot on
- Ensure official FRC Driver's Station application is running already
- Ensure Node webserver had no errors
- THEN connect tether from robot to D/S
- Wait for official D/S application to get comms
- Launch our Java process (contains Vision, Auton Selection & Telemetry stuff)
- Select autonomous after camera connects and hit 'Push to Robot'
I don't remember for sure if the exception on the RoboRIO side was "Connection Refused" or one of the other socket/network-related errors. I can ask though. FWIW, total network bandwidth using a 15hz update rate on telemetry and a 30fps rate on the camera (320x240) was about 3.5Mbps.