Chief Delphi - RoboRIO / FMS / mDNS / lessons learned

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Control System (http://www.chiefdelphi.com/forums/forumdisplay.php?f=177)

- - RoboRIO / FMS / mDNS / lessons learned (http://www.chiefdelphi.com/forums/showthread.php?t=135271)

Re: RoboRIO / FMS / mDNS / lessons learned

Quote:

Originally Posted by Mr. Lim (Post 1457828)

Also, if the RoboRIO's DHCP server hands out a bunch of leases BEFORE connecting to the FMS, would this necessarily be a bad thing? I'm not sure there is a downside. All the devices would get proper 10.te.am.zz IPs, and assuming mDNS is still configured, everything should be addressable by hostname, even if the FMS doesn't know everyone's IP address via DHCP.

I suspect this might be a bad thing, everyone would have 10.te.am.zz IPs, but would they be *unique*? What if the FMS assigns an address that the RoboRIO previously assigned, but to a different machine?

Would it be correct to say that anything that (correctly) does DHCP, and falls back to link local addresses, and uses mDNS for name lookups works fine? If so, the setup right now works, we just need to take care of the "not correctly" cases (i.e. reusing DHCP-assigned addresses across disconnects/reconnects). Or am I over-simplifying?

Re: RoboRIO / FMS / mDNS / lessons learned

Quote:

Originally Posted by Alan Anderson (Post 1457767)

The problem is that the roboRIO itself doesn't connect to the FMS, and it can't know whether or not to be a DHCP server until after it is already talking to the Driver Station.

I can't think of a reliable way to have a DHCP server decide to be active only when the FMS is not present. There are too many chances for it to be running before the DS has made the FMS connection. My preference would be for a separate physical device in the Ethernet tether between DS and robot bridge.

I expect the FMS DHCP is in the FMS's radio (access point might be a better name.) Since you are on a VPN at that point, each team would have their own DHCP. The RoboRIO cannot connect to the DS until it has an IP in the DS's subnet so it has to get that from the DHCP first. It would be interesting to know if the RoboRIOs subnet mask was still 255.255.255.0 at this point.

A couple of options for DCHP in the pits would be one on your DS. Probably not a good idea since you would have to remember to turn it on & off. Another would be a wired router. You would have to remember to plug it into the the robot radio before turning it on. Or you could go back to static IPs as outlined in screen steps

Other than it taking annoyingly long, we did not have issues connecting in the pit using to default method.

Re: RoboRIO / FMS / mDNS / lessons learned

Here's an example of the PDP fuses working their way out by the time eliminations rolled around.
They were never pushed in all the way.

Properly inserted there should only be about 1/4" showing, and are not removable by hand any longer.
If you can easily remove the fuses by hand, then they are not seated all the way.

Attached are three variations:
- fuses on a robot in Semi-Finals that have worked their way out
- fuses properly seated
- one good/one badly seated fuse to compare

Re: RoboRIO / FMS / mDNS / lessons learned

We ran into this problem at LoneStar on a regular basis (i.e. failure to reconnect to robot after returning to the pit, Driver Station showing a 169.254.X.X address). The key here (as already noted) is the 169.254.X.X address. Ever since Windows Vista (/ward against evil eye), the Windows IP stack generates the 169.254.X.X address if it cannot find a DNS server. This default address is also sticky and hard to flush from the standard GUI interfaces.

The problem lies with the driver station running Windows 7+. The roboRIO seems to be doing what its supposed to do, its just not being sent a DNS query by the driver station.

The fix - reset the ethernet adapter IP system.

The solution: Generate a batch file in Notepad that invokes the windows command line net shell interface. Use it to reset the IP system.

One line, should read:

Code:

netsh int ip reset

Or you could write it out fully:

Code:

netsh interface ip reset

Save the file as with a .bat extension somewhere handy with a memorable title (e.g. reset_ip.bat). Execute it by double clicking on it or any other conventional method.

Our experience is that this fixes the problem in seconds.

Hope this helps. Good luck in this last week of District competitions and at Championship if you are fortunate enough to go.