Persistent inability to connect FRC driver station and robot if radio disconnects eve

Technical Control System
1

Hello, I am a student on FRC team #3459 PyroTech, and we are having a debilitating issue with our routers connecting to our roborio, wirelessly and then using the driver station.

When we first boot the laptop for our drivers station it connects to the roborio with no problem. If the laptop loses the wifi connection for any reason, the FRC drivers station will never connect again until we reboot the driver station.

We are having the same problem when we use a OpenMesh OM5P-AC OR an OM5P-AN. We do not have the problem if we use an old D-Link.

Details:

Here is the copy of past of attempts to ping the OpenMesh OM5P-AN.

The first ping is after a fresh reboot of the laptop of the drive station. The FRC drivers station connects fine, but the ping fails to go through even though the mDNS appears to succeed in obtaining the IPv6 from the hostname. Then see the second ping. It takes place after we disconnect from the radio and then reconnect to it. At this time, the FRC drivers station will not connect at all, and the ping doesn’t even get the ip address of hostname.

Microsoft Windows [Version 6.2.9200]
© 2012 Microsoft Corporation. All rights reserved.

C:\Windows\system32>ping roborio-9999-frc.local

Pinging roborio-9999-frc.local [fe80::280:2fff:fe17:9e36%14] with 32 bytes of da
ta:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for fe80::280:2fff:fe17:9e36%14:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),
Control-C
^C
C:\Windows\system32>ping roborio-9999-frc.local
Ping request could not find host roborio-9999-frc.local. Please check the name and try again.

C:\Windows\system32>

No matter how many times we connect and reconnect to the radio, the FRC driver station will not connect. If we reboot the laptop, then we can reconnect, until the first time the radio disconnects. Then we are back to being unable to.

When we use the OM5P-AC the behavior is similar except that the ping goes through to the radio. But just like with the 2016 radio, when we use the 2017 (OM5P-AC) radio, we fail to be able to connect after the first disconnection.

We happened to have an old D-Link around. We hooked it up. Everything works fine. We can connect and disconnect from the D-Link all day long and the FRC driver station software quickly connects with the roborio.

We have imaged both the 2016 and the 2017 radio with the appropriate firmware from FIRST for “at home” and configured it using the FRC configuration tool to the team number, to limit bandwidth “9999”, and as a 2.4G AP. By “appropriate firmware”, we mean that we used the latest version of the radio configuration tool (2.14.17.256?) and let it update the radio. It reported success.

The windows firewall on the laptop is disabled and the norton install is completely disabled.
We did also remove and reinstall the mdns responder on the laptop. Oh and this plays out the same with 2 different laptops as the drivers station. One with this year’s latest FRC driver station application and one without the driver station update in team update 12.

When wired by ethernet or using USB we have no trouble at all. And it always works if the laptop of the driver’s station is freshly rebooted, until the first time the radio disconnects for any reason (robot reboot, switch to different network for update, etc). Reboots of the robot do no good, nor do reboots of the radio.

Has anyone seen anything like this before? Any suggestions? We’re stuck.
Thanks for any assistance
Keith

2

Up until the final two days, we also had experienced the one-and-done problem connecting to the roboRio. Just before bagging, we tried the following and we were able to reconnect after disconnecting with the robot. With our short tests, I suspect the Apple Bonjour mDNS responder is what helped us the most.

1.) Instead of installing iTunes, the ‘lighter’ way to get Apple’s mDNS Responder is with Apple’s “Bonjour Print Services for Windows”.
https://support.apple.com/kb/dl999?locale=en_US
(It seems okay to have both the NI National Instruments and Apple responders installed.)

2.) Use a DOS command prompt (or desktop shortcut), to ping the robot with forced ipv4 and with the host name; this helped the one time we tried it.
c:\ping -4 roboRIO-####-FRC.local
(I wonder if it would help to just let it run continuously in a window in the background?)
c:\ping -4 -t roboRIO-####-FRC.local

3.) If you change connections from one robot to another, try flushing the DNS cache from a DOS command line, or create a desktop shortcut with this command line. (We ran out of time to determine effectiveness.)
c:\ipconfig /flushdns

3

You should be pinging: roborio-3459-frc.local

My guess is that it is an mDNS issue. Try giving your roborio a fixed IP address of 10.34.59.2

4

All season we had also experienced the one-and-done problem connecting to the roboRIO. At the very end, we tried the following, with Apple’s Bonjour mDNS Responder helping the most.

1.) Install Apple’s “Bonjour Print Services for Windows” (includes Apple’s mDNS repsonder).
https://support.apple.com/kb/dl999?locale=en_US

2.) Plain old ping didn’t work for us, we had to force ipv4.
ping -4 roboRIO-TEAM-FRC.local (add -t to continue running in background)

3.) Did not try this enough to determine effectiveness.
c:\ipconfig /flushdns

5

Something we should have explained is that some of the testing (including when we to the picture of the ping) was on one of our secondary roboRIO’s that had its team number set to 9999.

6

Ok. We have all our roborios set to our team number. We use different wifi SSID to have multiple robots robots going at the same time.

Since everything works with the d-links, it is likely your problem is related to mDNS. When you loose your wifi connection, I’m guessing when the radio reconnects, the roborio gets a new IP address, but your DS is still trying to go to the old ip address. Thus the need to reboot the laptop to clear the mDNS address list. Giving the roborio a static ip address fixes that problem.

7

I recently saw something similar working with another team. The team would connect, and then disconnect and it wouldn’t work again until a reboot. It turns out the RoboRIO still thought that a driver station was connected, even though it wasn’t, so it wouldn’t let another one connect. There’s a status light on the RoboRIO that indicates that.

It turns out the school in question had some issues with viruses on their network, and they ended up installing some software to clamp down on all of the computers. That software didn’t work nicely with the OpenMesh access points, and they ended up getting locked out one way or another. The team ended up going down the path of reformatting and reinstalling on their driver station laptop, and I haven’t heard anything since, but they were functional at week 0 so I’m guessing that fixed the issue.

8

You can test for that by rebooting the robot. A power cycle of the robot would clear that problem.

9

Yes, we also had experienced one-and-done connections to the roboRIO all season, until the last couple days.

We installed Apple’s “Bonjour Print Services for Windows” (includes Apple’s mDNS repsonder).
https://support.apple.com/kb/dl999?locale=en_US

Ping also worked for us, but that took user intervention (command line or desktop shortcut). And to get ping to work for us, we had to force ipv4 (-4 switch):
**ping -4 roboRIO-TEAM-FRC.local **

10

Just a quick update. We did all sorts of things trying to find out what was wrong. (if you want me to explain exactly what we tried I would be willing to).

Long story short, we switched to a ‘dumber’ laptop, and it worked (we tried a classmate with last years Driver Station (DS) ). We also tried it on an older laptop that we had just updated to run the DS version that was in team update 12 ago. Also worked like a charm. Tomorrow I will try using it on a laptop we used for a DS four years ago (after updating it), and maybe updating the classmate and seeing if that will still work.

Thank you for all of your suggestions.

11

If it is unique to that laptop, then it is likely a firewall, or mDNS implementation issue.

12

For our team, the wifi connection one-and-done problem with the robot is unique to our Windows 8.1 computers.

We have no re-connection problems with Windows 7 Pro computers.