Well, i was sitting at home literally just staring at an open driver station window when an odd idea came to me. Is it theoretically possible to port-forward or somehow give the robot bridge an external IP, and then access it from over the web, and perhaps, drive it? (regardless of lag) would/could it be possible with out large amounts of software modification?
As long as your connection has enough bandwidth and low enough latency to keep the FMS packets getting to the robot before the time out. The answer should still be yes. I actually made this work with a cRIO at one time.
The challenge would be to control it over the Internet where you are effectively blind.
I recently installed an XFinity cable modem that got 180Mbps down and 12Mbps up (for $100 a month) and with some infrastructure I could likely make it work on that connection with the risk of the robot occasionally getting disabled if too many packets were delayed or lost.
Keep in mind you need a low enough latency so something like Hughes DirectDuo satellite Internet won’t cut it. POTS modems are out as well (the actual bandwidth needs of FMS are small compared to an Internet camera and even compared to network tables).
I would propose though a more interesting solution:
Don’t control the robot directly. Control a computer local to the robot which is the driver’s station because then you have something with some brains and the connection between the FRC robot and driver’s station is not in jeopardy at all.
This challenge would be similar to using a co-processor for video on the robot. Build a web interface and host it on the driver’s station with the controls or rig the driver’s station to have a REST API or something like a realtime Javascript backend (NodeJS/WebRT probably with some queue like Redis). If you rig the driver’s station to have a REST API you could wrap a nice little interface on the remote computer or mobile device. Pulling off this would allow you to have joysticks, touch screens and other gizmos on the remote computer and forward the control information to the driver’s station on the local network with the robot. Kicking off autonomous functions is obviously even easier because you just need to select the autonomous function and execute it.
The web interface is likely superior to using something like RDP which can be swamped because it is sending all the extra graphical data from the driver’s station remote display and depending on how Window’s GDI/Aero is feeling RDP can be sort of painful (try using Microsoft Word over RDP and type a document you’ll see the issue). It may be this feature could exist in some of the nonFMS control software a few teams have opensourced over the years (I haven’t really played with most of them).