Autonomous chooser not working when connected to the field

[minutebot]

Originally Posted by cpapplefamily

We do have a connection indicator but will have to ask the drive coach and team if they noticed the status. Most likely they did not . The select / reselect was a rouble shooting step attempted yesterday but since today the entire day it was running flawlessly the drivers hadn't been doing this. We also started yesterday with static IP's but after our radio flash that didn't work. The IP was 10.32.44.5 that I believe now was wrong. Should been like 10.32.44.20. Our ip camera is static with an ip of 10.32.44.11 and is lagging but displayed on the SD.
nickbrickmaster love to pick your brain for my own knowledge. You must be here at 10,000 lakes. We have a slow start in the morning. Our first and final quality is at 11:30 ish. Our plan is to re-weigh since we beefed-up a part of our bot with about 12oz and with a 119 lbs bot yep it must be done.

The knightkrawlers fixed our auto chooser problems and 5996's by switching us to static. You seem to have done that part right though, did you also uncheck the box under file-->preferences on the smartdashboard that says use mDNS?

Here's the link they were using but I think you did the static steps right

https://wpilib.screenstepslive.com/s...g-at-the-event

[virtuald]

Originally Posted by MamaSpoldi

We also had this happen to us. It turns our that Windows 10 had re-enable the firewall. Very annoying but at least we know to look for that now.

I had this happen once. Windows 10 displays a message in the corner "your firewall is disabled", and if you click it then it seems that it will automatically re-enable it.

[virtuald]

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.

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#.

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.

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.

[mwtidd]

Originally Posted by JesseK

We code in Java on the robot, and Java on the driver's station.

We've had a LOT of problems using custom network code in the last 2 years. 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.

Following 254's code from last year (https://github.com/Team254/FRC-2015), we implemented a web dashboard. The FMS whitepaper (https://wpilib.screenstepslive.com/s...fms-whitepaper) recommends you use 5800-5810 (web traffic leverages TCP).

The dropdowns in the stock dashboards have caused all sorts of headaches this year.

[JesseK]

Originally Posted by virtuald

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.

We wanted the Robot code to run REST calls with attached JSON data to the webserver on the Driver's Station. We tried DNS names and static IP's. It's for telemetry, not robot control. We followed as much of 1418's setup as we could in getting as far as we did, but Network Tables was the implementation for CHSChamps.

No one on my team uses Python, for better or worse. We have plenty of kids who eventually use it during Cyber stuff, but for FRC stuff we stick to either Java or (eventually) Web. I don't want to get into a language debate - it's just what our team knows and does. I'll check out the links you provided though.

Thanks for the correction on ntcore - some of my info is 2nd-hand since I'm not on the programming team. I took a look at a few things, but it'll take a bit more analysis to figure out where it puts the rate limitation in. If not, maybe next year we'll do something like Pete Lawrey's OpenHFT and then dump the results to the web server.

[virtuald]

Originally Posted by JesseK

We wanted the Robot code to run REST calls with attached JSON data to the webserver on the Driver's Station. We tried DNS names and static IP's. It's for telemetry, not robot control. We followed as much of 1418's setup as we could in getting as far as we did, but Network Tables was the implementation for CHSChamps.

Oh that's interesting, I've not ever tried connecting to the DS from the Robot. I realize that FIRST states that various ports are bidirectional, but I would imagine that TCP connections from the robot to DS aren't done very often... I'll ping Kevin and ask him if that should work or not.

No one on my team uses Python, for better or worse. We have plenty of kids who eventually use it during Cyber stuff, but for FRC stuff we stick to either Java or (eventually) Web. I don't want to get into a language debate - it's just what our team knows and does. I'll check out the links you provided though.

No language debate intended.

The nice thing about pynetworktables2js is that although underneath the hood it uses python, to use it to create a dashboard you really only need to know HTML/JS and how to run a python script. However, it sounds like it isn't really what you're looking for either, as you wouldn't be able to write anything to disk without writing some python code.

[Thad House]

Originally Posted by JesseK

Thanks for the correction on ntcore - some of my info is 2nd-hand since I'm not on the programming team. I took a look at a few things, but it'll take a bit more analysis to figure out where it puts the rate limitation in. If not, maybe next year we'll do something like Pete Lawrey's OpenHFT and then dump the results to the web server.

The limitation is pretty easy to find and remove from ntcore. However, in its current state you need to be careful. If you remove the rate limitation, (which is currently sending every 100ms minimum), you run the risk of overusing the network bandwidth and running into the 7mbps bandswidth limit. This is especially the case if you use many NetworkTables variables and update them often. But this would be the case if you ran your own networking code as well and send data too fast.

[JesseK]

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

1. Power the untethered robot on
2. Ensure official FRC Driver's Station application is running already
3. Ensure Node webserver had no errors
4. THEN connect tether from robot to D/S
5. Wait for official D/S application to get comms
6. Launch our Java process (contains Vision, Auton Selection & Telemetry stuff)
7. 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.

[virtuald]

That sounds like a reasonable flow of operations... If everything was a static IP, that should work... I bet they're blocking outbound connections on 443. Did you try different ports instead of 443?

Also, I misread what you said earlier, I read "4k hz" instead of "4hz". You should be able to get at least 10hz out of ntcore, and 20hz out of pynetworktables. I haven't really benchmarked either of them recently, sounds like something someone could do.

[ShinyShips]

We also had issues with SmartDashboard during our time at the MAR Bridgewater-Raritan event. Our SmartDashboard just would not connect to the field and the match had to be played without our autonomous. From what I remember it wasn't just us either.

We decided that we didn't want to rely on SmartDashboard, so we switched to a wheel selector (Don't actually know what is called, will find out tomorrow). We wired it to three DIO ports and using binary we select our auto. That way when we set up the robot we just move the wheel to the right number and don't have to worry about it.

[virtuald]

Originally Posted by virtuald

I haven't really benchmarked either of them recently, sounds like something someone could do.

Of course I was curious, so I had to write something.

I added a benchmark script to the pynetworktables samples, it should be pretty trivial for someone to port it over to Java/C++ et al.

In it's default configuration, I got around ~19hz running on localhost. I expect that my methodology isn't perfect, but that number is around what I would expect, and varying the write flush period also varied the latency.

I would expect a similar test of ntcore in its default configuration to be around 9-10hz. This doesn't reflect an 'actual' performance difference between pynetworktables and ntcore, but rather just a different default value for the update rate (I chose 50ms, they use 100ms).

[JesseK]

Originally Posted by virtuald

That sounds like a reasonable flow of operations... If everything was a static IP, that should work... I bet they're blocking outbound connections on 443. Did you try different ports instead of 443?

Also, I misread what you said earlier, I read "4k hz" instead of "4hz". You should be able to get at least 10hz out of ntcore, and 20hz out of pynetworktables. I haven't really benchmarked either of them recently, sounds like something someone could do.

Initially the port was 5800, but since it was a web server someone thought it would make a difference to put it on 443. Not sure why 443 over 80, but I wasn't around for that decision so there may be more to it.

Around this time last week someone on the programming team said they clocked Network Tables at 4hz - it matters at the moment since that's how vision sends parameters back to the robot. I'll examine how they benchmarked in more detail then. 10Hz is more palatable for post-match analysis, but in the shop I'd like to bump it higher so we can track some of the sensor outputs better.

Thad, I'll look for the rate to remove it. Thanks for the tip!

[Greg McKaskle]

Does the ntcore implementation have a flush command? This is a good way to keep a relatively low rate of transmission, but ensure that when you want lower latency, you can do so.

And just to confirm what was said earlier, there have always been different, but compatible network table implementations. Unless you are using the LV implementation, you do not need the LV runtime engine. The Java and C++ ones are now a common implementation.

Greg McKaskle

[Thad House]

Originally Posted by Greg McKaskle

Does the ntcore implementation have a flush command? This is a good way to keep a relatively low rate of transmission, but ensure that when you want lower latency, you can do so.

And just to confirm what was said earlier, there have always been different, but compatible network table implementations. Unless you are using the LV implementation, you do not need the LV runtime engine. The Java and C++ ones are now a common implementation.

Greg McKaskle

There is a flush command, but it is also limited to a update rate of 100ms. The issue with making data transmit faster is that most robot code updates dashboard variables every 20ms or faster in the main robot loop, and if you were to run a flush it would send all that data even if you only expected to send a few variables. There is no current way to only send specified keys faster.

[tr6scott]

We are a labview team, and years ago we had issues with making selections on the dashboard, make it to the bot, for auto selections. The fix we implemented back then, and still use today, is that we use joysticks to make the selections, and the dashboard only displays the value. We put the code for the auto select in the disabled state. This forces communication path to the bot be working, for the selection to work.

Like I said we are Labview, but thought that this maybe a simple workaround to make sure the robot is going to run the right code.