Quote:
Originally Posted by Tom Bottiglieri
We ended up ditching the HTTP-over-field-wifi solution in favor of Network Tables as last year we had a bunch of connectivity issues on the field, especially when it came to Web sockets.
We now use a python->js gateway and our web app talks to a local server running on the laptop, which in turn talks networktables to the robot. It seems reliable. We also do some of the things mentioned in this thread like echoing the selected auto mode to another control and showing a robot generated timestamp to validate connectivity.
|
I had heard through the grapevine that you had changed your approach to use the networktables.
I really wanted to be able to leverage object serialization so I continued on the road you guys started down.
We were able to side step a lot of the FMS network issues by taking slightly different approach on the general network architecture. We have an onboard laptop that actually runs the server and acts as the middle man. That way the FMS doesn't interfere with communications between the Rio and the Auto Manager. Basically when a socket is opened we send the latest selected auto, so just declare the auto while you're in queue and you're should be good to go.
If the drive team needs to, they can change the auto from the DS via a web dashboard, and the server can broker the change to the Rio. As you suggested though, this can often be a headache because of the FMS wifi setup.
We actually leverage this same general architecture for generating trajectories on the fly and for vision processing as well. Being able to use Jackson or Gson for object serialization makes life sweet when programming in Java. It made re purposing the general idea for multiple purposes fairly straightforward.