I’ve seen a lot of posts about people having issues connecting to the driver station/uploading code this year.
For example, we have to constantly restart the robot radio and disable/enable my wifi adapter in order to access the robot wirelessly, which is something we didn’t have to do last year.
Does anyone know why this is happening? And does anyone have similar experiences?
Our team apparently experienced something similar to this today.
We don’t have any further insight; we first tripped on it with the very latest radio firmware, and felt that reverting solved our problems. But today nothing was working either, for no good reason. It’s almost as though something is preventing the UDP packets from flowing. For us, we can deploy code and the smart dashboard works, but the driver station simply will not connect.
I’m told that it happened without the radio (i.e. direct ethernet connection), which would seem to rule out the radio. We did wire up a complex CAN chain; that’s the only major change we’ve made in wiring. I don’t think anything has changed on the driver station, unless the radio update changed something else we haven’t figured out.
So we’re baffled as well. Not sure if that helps, but the more I ping this, maybe the more someone else who knows the answer will see it and chime in :-).
Cheers,
Jeremy
We’re having many troubles also.
After updating eclipse, all the driver’s stations, firmware, and radios, we received an error saying that plugins were not compatible with our roboRIO image, so we updated the rio on our practice bot.
After competition, we we could connect to the rio through the web interface and the driver station, but could not upload new code nor connect through SSH when using wifi. An ethernet tether did allow us to use SSH.
Downgrading our radio to previous firmware and configuration lets us communicate through wifi again.
Also (and this may be unrelated) we have a thread on the rio that is receiving UDP packets. After the upgrades this code failed saying that port 1735 was already in use. Setting this thread to be a daemon thread solved that problem. Apparently the thread was holding a connection to port 1735 and did not die when we reloaded code.
We had a full day with no issues today.
We are suspecting CAN bus; we ran the first half of the day without changing anything, but also without running any devices off of CAN.
We did have a conflict; the pcm shared an id with the pdp. We did change that half way through the day, and continued to have no errors.
So can’t say for sure that was the issue; figured I’d report in in case of the slim chance that it helps someone else.
Cheers,
Jeremy