Quote:
Originally Posted by JesseK
This year we did something way different than last year - we setup a web server on port 443 of the driver's station. We could never get it working.
|
On the driver station, or on the robot? If it's on the driver station.. what address are you listening on? If you're listening on 127.0.0.1, the field setup couldn't interfere. We use localhost:8888 with no issues.
Quote:
|
In the end, we swapped to NetworkTables. Sure, it requires a Labview runtime library just to develop with
|
No it doesn't. There are ntcore bindings in
C++, Java, and C unofficial python bindings (
pynetworktables) and C#.
Quote:
|
we can't figure out how to get it above 4hz
|
This is by design and internal to the way that NetworkTables does buffering to prevent users from sending too much data. The python bindings have a setting that you can tweak if you really need to. I'm not sure if there was something exposed in ntcore.
Quote:
|
and it means that without layers of interpreters we'll only ever develop displays in Java - but it works. We run a separate process from the driver's station, so it isn't Smart Dashboard stuff - just read and write to a HashMap by using the NetworkTables framework in your own code.
|
You should checkout
pynetworktables2js. Both of my teams (1418 and 2423) use it to develop dashboards in HTML/JS, communicating back to the robot over networktables.
Both teams had issues with connecting to the robot during their first events, but after switching all devices to static IPs (robot: 10.xx.xx.2, ds: 10.xx.xx.5), we had zero connection issues.