Our team is having an issue connecting to the radio with the 2018 driver station. Randomly, both when the robot was enabled and disabled, we lost communication with the driver station although the laptop and driver station both still said we had a connection. We have two robots and this was an issue for both. Both RoboRIOs have been reimaged for this year. We were able to successfully establish connections and use the robot, so we don’t think it is an issue with the radios, but it is definitely possible. Has anyone else had a similar issue or experienced other bugs with the 2018 driver station, as this was not an issue when we tested with the driver station from last year. If not, are then any solutions that anyone can recommend to solve the issue.
You will probably get a better response if you go through some basic trouble shooting. What messages are you seeing on the driver station? Is it still showing robot code? What do the diagnostics say? Can you still ping the robot? Have you disabled all the Windows firewalls? etc.
Although a different account, this is the same team responding. I am just a graduated student that came back to mentor.
The disconnect is purely a driver station to robot disconnect, as evidenced by the main communications and robot code lights going red. When it disconnects, the robot radio and robot lights remain green on the diagnostic page (and the robot light has the right ip next to it.) We can ping the roborio, access the NI Web Configuration and Monitoring tool, and deploy code to the robot. However, even after doing these things, we do not regain connectivity with the main communications and robot code lights.
The only thing we have tried so far and worked is successful is to reboot the entire robot. When it happens again, we will be just rebooting the radio (and if that doesn’t work just the roborio) to try and trace the problem to a specific component.
If you’re seeing any color comm LED, you don’t have a communications issue. The problem you’re running into is related to your code.
I’m guessing you’re a Java team. If that’s the case, take a look at your console. Odds are you’re running into an error that stops your code. As a result, the Comm LED turns red to show you there’s a connection. But, your code isn’t running.
Or, do you mean the lights in the Driver Station showing communications there? In that case, the Comm LED should also be off. Which of these scenarios are you running into?
So we are having the same issue. Here is what we have found out through trying to debugging:
Robot randomly disconnects when disabled and enabled.
The driver station says its connected to the robot radio, the robot and the wifi. We have also tried connecting over USB and ethernet and the same issue occurs.
We can still deploy code and connect over ssh, however no driver station connection.
We’ve had the same issue. I’ve attached a screenshot of our DS. We can also ping the roborio and connect to the web dashboard. However, when we deploy code, it gives the error in the second screenshot below.
So I noticed my firewall light was also not green and I did disable the windows firewall and defender. I also allowed the driver station ports through in the windows firewall center.
I also noticed sometimes right before the driverstation disconnects the battery voltage graph will stop and then “catch up with itself” quickly before it disconnects. I have no clue on that one…
The text next the firewall light says “Firewall(Dom)” am I missing a setting?
Note that there are actually 3 levels of Firewall to disable on Windows 10 (and also Windows 8). “Dom” refers to the Domain profile which is hidden in the advanced settings. If you look at this post from last year, there are screen shots and some description of what the settings are: https://www.chiefdelphi.com/forums/s…9&postcount=13
Ok I got the firewall light to be green however, we are still having issues where the driver station seems to lag behind and then disconnect. Like in my previous post where the battery indicator will lag behind and then catch up after it disconnects
I’d suggest trying a different laptop to see if it’s specific to that particular PC.
It be that there is a local PC process that is blocking the network connection periodically.
For example, any automatic update checker could be doing this. AutoDesk updater was a classic example of this.
On Tuesday, we were having an unusual spate of disconnection, much like as described in this thread.
That was a change; we had been running fine; we’re a beta team, so we’d been running for weeks on the software.
Our programmer had made some changes to the code; some around some PID and motion profiling work, and then just some debug prints around encoders. That is, she had added debug code to print to the console (i.e. System.out.println) every time in teleop; so spewing to the console, a relatively standard practice for our team.
On a hunch, she commented out those prints and we did not lose connectivity after that.
So it seems as though the new logic to handle the console may trigger a crash somewhere in the rio image. If we get time, we will try to probe this further, if for no other reason than to make sure it’s not a coincidence.
But I figured now was a good time to post in case it helps another team.
Right, so we disabled firewall so the firewall light is green, along with all of the above lights in the above post. However, we’re still getting the same problem - we see that we have comms on the DS, but when we go to deploy code, it says that the target was not found. We’ve tried setting the target to both 10.45.57.2 and roborio-4557-FRC.local .
I submitted github wpilibsuite/allwpilib issue #889 to have this problem fixed, I am hopeful.
I was then asked for tests related to the interaction between the Riolog and the FRC Message Console. I found cases that never failed and cases that always failed for me. Those have been added to the issue. The comments below probably aren’t pertinent (ancient history now) - check issue #889 for the latest information.
I found the pattern of successful runs and failed runs.
I can run indefinitely (for several hours) viewing substantial amounts of Java console output in the Eclipse Riolog. There have been no sudden connection failures without error messages.
Turn on the DriverStation View Console - FRC Message Console and the DriverStation claims loss of connection to the roboRIO within a minute or two of turning on the console. [version 18.0 of the DriverStation]
Below is the original post of some of what was tried to find the error:
Here’s a Me Too!
Java code displaying gyro heading to the console often crashes at random times from 20 seconds or more after enable but has run a few times more than 2 hours before manually stopped.
No error message on Java output console except the DriverStation bad ping disconnect. DriverStationn has red lights for Comm and No Robot Code. We can logon the roboRIO terminal and ping RoboRIO through Windows command prompt with no problem. RoboRIO lights appear correct and the user program appears to still be running on the roboRIO (using linux top or ps commands).
Must hit reset button (or cycle power) on roboRIO to get DriverStation to work again.
Tried multiple PCs and multiple roboRIOs and multiple Ethernet cables and multiple USB cables (not using a radio at the moment).
Got a Windows Message Analyzer output from one session but we’re not experts at wading through tons of messages and nothing popped out as being a problem.
We’re out of ideas of what to check except we can remove the console output.
We’re a “me too” on this also. Has anyone found a root cause or solution other than removing all console output? And is this only burning teams using prints to the console or pushing data via NetworkTables to the SmartDashboard too? We were primarily seeing the former over the weekend but saw at least one disconnect just sending data to the SmartDashboard too (unless there was a rogue cout hiding somewhere).
So after a couple of hours of work we isolated the problem down to the RioLog feature in eclipse. Renaming the JAR file and causing it to stop running has solved the disconnect issue for us. Can y’all try it out and get back to me. I’m interested to see if it solves the issue for you too.
For those of you not following the Issue in Github I’ll summarize my finding:
I can run the Riolog or the FRC Message Console but if I start both at once I can’t restart the roboRIO without getting the disconnect failure in a minute of two unless I stop one of those logs/Consoles first.
If you like the Message Console then close the Riolog in Eclipse and that state persists until you show it in a view again.
I like the control buttons on the Riolog so I’m sticking with that one and leaving the FRC Message Console closed.
My team had the same issue. We found it is fixed when we reboot the RoboRIO. We think it’s because WPILib now automatically opens the Riolog whenever you deploy code, and that makes everyone have their Riologs open. This overwhelms the RoboRIO and causes the driver station to lose Coms despite still being connected to the robot Wifi. Our fix was to disable the Automatically Connect To Robot option. It’s the button with two yellow arrows pointing left and right. Unfortunately Eclipse turns this back on when you restart it, so you will have to remember to turn it off again.
