Driver Station fails to reconnect after power off

[Crossle86]

We are seeing an ongoing problem with the 2015 control system. If we are connected to the roboRIO and all is working, and we then power off the robot, when we power back on, the driver station does not automatically reconnect when the robot is back online. This does not happen every time but often enough to make us very uncomfortable. When we fail to reconnect, if we exit the DS back to Windows, we see that Windows is connected to the robot router. If we then restart the DS, it will fail to connect. The work around we are using is to return to Windows, disconnect then reconnect to the router and then restart the DS. After doing this, the DS connects as expected.

In the 2014 iteration of DS and control system, we had no problems with reconnection after power cycle of robot. I don't know how the DS detects the return of the robot after a power cycle but however thats done it seems to not be working nearly as well as last year. I am wondering if the switch to mDNS has something to do with this.

[billbo911]

Originally Posted by Crossle86

We are seeing an ongoing problem with the 2015 control system. If we are connected to the roboRIO and all is working, and we then power off the robot, when we power back on, the driver station does not automatically reconnect when the robot is back online. This does not happen every time but often enough to make us very uncomfortable. When we fail to reconnect, if we exit the DS back to Windows, we see that Windows is connected to the robot router. If we then restart the DS, it will fail to connect. The work around we are using is to return to Windows, disconnect then reconnect to the router and then restart the DS. After doing this, the DS connects as expected.

In the 2014 iteration of DS and control system, we had no problems with reconnection after power cycle of robot. I don't know how the DS detects the return of the robot after a power cycle but however thats done it seems to not be working nearly as well as last year. I am wondering if the switch to mDNS has something to do with this.

Is it safe to assume you are not using a static address on your RoboRio?
Someone please correct me if I'm wrong, but I think assigning IP's to your devices might be a simple and fairly quick test to see if it corrects this reconnect issue.

[Crossle86]

We are using the mDNS scheme as directed by the First Doc. I considered using static IPs earlier when we had a connection issue (taking too long but did connect). Things seemed to settle down for a while but now we are back to the reconnect failure.

I would not be opposed to switching to static ip, but I do not know how the DS connects and if it supports a way to set static ip or a fall back scheme like the Eclipse build scripts do. Static ip won't help unless the DS supports it.

I'm also concerned about what happens when we go to competition, if this issue will be present under field control...

[billbo911]

Originally Posted by Crossle86

...
I would not be opposed to switching to static ip, but I do not know how the DS connects and if it supports a way to set static ip or a fall back scheme like the Eclipse build scripts do. Static ip won't help unless the DS supports it.

I'm also concerned about what happens when we go to competition, if this issue will be present under field control...

The DS automatically assigns a static IP to the laptop based on the team number you enter. I believe it uses 10.xx.yy.5 for the wired and 10.xx.yy.6 for the wireless, but I may have those two backward. Either way, you may only need to assign an IP to the RoboRio.

I'm not the programming mentor this year, so I have not spent a lot of time with the system. So, my understanding may be a bit off with the new system, but this is my understanding of how they work this year.

[Crossle86]

I think I missed the point of your response. I will try switching to a static ip based on the standard numbering scheme and see if it makes a difference. Not sure when I can get time to do that but I will try it as soon as I can.

If anyone knows how the DS software detects and connects to the rio and how it handles loss and reconnect, I would appreciate the info. Would save a lot of time tinkering.

[Crossle86]

Sorry, again I missed your second post. The issue is how the DS determines the roboRIO address and when it does it. As I understand it, the DS does a local network query with mDNS protocol and the rio should respond with its IP address as assigned to the rio by the router with dhcp. The DS then connects that that ip address.

The Eclipse build scripts do this and if the connection fails, it falls back to trying USB connect and then direct ip address using the standard scheme.

So if the DS were to do this, that is detect if mDNS fails to deliver an address or the connection to the mDNS address fails, then use a static ip, that would be good.

I think the key is how the DS detects that the rio is back online and that it should reconnect. Is it polling the network or using some other scheme? And does it mDNS again or use a cached ip address?

[Joe Ross]

Setting a static IP address does not preclude mDNS from working. If you set a static IP address of 10.XX.XX.2, the driver station will still find it using mDNS.

One thing you can do is use usb to connect to the roboRIO and see if it received a DHCP address from the router.

[Alan Anderson]

Originally Posted by billbo911

The DS automatically assigns a static IP to the laptop...my understanding may be a bit off with the new system, but this is my understanding of how they work this year.

You're a year behind the times. The 2015 Driver Station does not change the computer's networking configuration. It's supposed to stay DHCP.

[billbo911]

Originally Posted by Alan Anderson

You're a year behind the times. The 2015 Driver Station does not change the computer's networking configuration. It's supposed to stay DHCP.

Thanks Alan.
I did a quick read after posting that information, but what I read did not cover that detail.

Maybe I ought to stop soldering up "Button Box's" and start reading documentation a bit more.

[Crossle86]

Yes to all that. The question is does the DS fall back to static IP if it fails to get an address from mDNS or fails to connect on the mDNS address. And, how does the DS detect that a powered off robot has come back online and it should reconnect.

[Crossle86]

And, BTW, during robot testing yesterday, we had another instance of the case where the bot is turned off and then back on and while all looks normal, nothing can connect to the bot. Not the DS, not the developer PCs. You can see the bot in the wireless networks on the PC, but connect fails with a Windows error. It appears the bot is there but the connection to the router AP fails. All forms of reset from PC end tried and failed. After another power cycle of the bot, the PCs reconnected as expected. During the course of the testing session there were other power cycles where reconnect happened automatically as expected.

[kylelanman]

I think we have run into this same problem. Our experience is that we can ping the robot using both the hostname (mDNS) and the IP address but the DriverStation won't connect to the robot. Most the time closing and reopening the DriverStation solves the problem. Sometimes we have to reboot the entire DS laptop.

This has us worried as to what happens if the RoboRio resets during a match. Will we be able to reconnect?

[Crossle86]

Yes, exactly! We saw this problem in January and closing and reopening the DS seemed to clear it up but the last few times we have hit this problem closing and reopening DS has not fixed it. We have gone to falling back to Windows and disconnect the router and reconnect. And we had the one case yesterday where that did not work and another robot power cycle was needed. That last case suggests the problem is between the PC and the router as Windows said it could not connect. But, we have also seen cases where the DS won't reconnect but the development PCs do. There seem to be multiple scenarios where there are reconnection problems.

I'm going to go out on a limb and state that we have not seen a case where the bot has been off for an extended time and then we start it up for testing and there is a "initial" connection failure. It only seems to happen after we have been connected and then power cycle the bot.

[Crossle86]

An update on this issue. Yesterday during testing I observed a case where the DS and development PC were both connected to the RR and operating normally. There had been several successful code downloads. Then on the next code download, the development PC could not find the RR IP address via mDNS (as reported by the build script). A ping from devPC did ping the known ip address of the RR. The DS remained connected during all of this. Then as I was contemplating what I had just seen with my devPC, the DS connection to the RR was dropped for no apparent reason. The DS would not then reconnect. Ping from DS to RR was successful. Both the devPC and DS had to have the wireless connection to the router disconnected and reconnected to get them both to find and connect to the RR. Then the rest of the test session there were no problem.

My gut feeling is that mDNS either on the PCs or the RR is failing to respond and report the RR ip address. I am assuming the build scripts and DS do not cache the ip address though mDNS doc suggests that the mDNS service caches. So its not clear if mDNS is failing of if there is a connection issue once the PCs have an ip address either from mDNS response or cache.

If I had more time I would set up network monitoring and try to catch this issue and be able to narrow it down, but our team just does not have time for this kind of thing as we are late getting the machine done. We are planning a major test session tomorrow on a full field so I will collect what information I can if we see this problem then.

[billbo911]

I know in a previous post, I suggested using static addresses. As Alan correctly pointed out, I was a year behind in my thinking.

I just went through the FTAA webinar. One of the troubleshooting steps mentioned was to make sure the DS was set to DHCP. This session was geared toward Competition Field use, but may be relevant here.

Were you tethered to the RR, or wirelessly connected through the D-Link?
How did you configure the D-Link, with the FRC Bridge configuration tool, or manually? 2.4GHz, or 5GHz?

Are all other adapters on the DS and Development PCs disabled except the one used to connect to the RR?