RoboRIO / FMS / mDNS / lessons learned

[Mr. Lim]

Originally Posted by Alan Anderson

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.

But the RoboRIO does get its IP address from the FMS's DHCP server. I think it may be possible (although I have personally never done it) to configure a DHCP server on the RoboRIO to only hand out leases if there isn't already a DHCP server on the same network. If it detects another DHCP server (i.e. the FMS's) on the network it simply won't do anything, and let the existing (FMS's) DHCP handle everything.

Redundant DHCP servers that are configured for failover have been around for a long time. Maybe this is an approach worth exploring:

https://kb.isc.org/article/AA-00502/...-Failover.html

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.

[plnyyanks]

I thought I'd write up some of the things I saw as FTAA at NYC this weekend.

Major Things:
- UPDATE YOUR DRIVER STATIONS/FIRMWARE. We still spent way too much time running around updating teams' laptops. Save everybody the time and update it before you compete (and you'll pass inspection that much faster)
- PUSH IN THE PDP FUSES. Offhand, I think at least quarter of the field connectivity issues we saw involved robots with the fuses not pushed in all the way, which increases the likelihood of power issues elsewhere on the robot (brownouts, reboots, and whatnot). Look at them sideways, if you can see the contacts between the top of the fuse, and the PDP, it's not in all the way. Push harder.
- CHECK YOUR ETHERNET CABLES. I was surprised at the number of times the ethernet connection to the roboRIO was not plugged in all the way, not plugged in at all, or nonexistent. If you unplug the ethernet cable in the pits, make sure it gets plugged back in (and verify the link lights on the port when you turn the robot on)
- DON'T TOUCH THE BRIDGE/AP MODE SWITCH. Once you configure your bridge, there is absolutely no reason to move the switch on the bridge back to AP mode until after the event. Wifi isn't allowed in the pits, and it wont' work on the field, so it's not particularly useful to touch...
- BUY A BATTERY BEAK. Power brownouts are no fun, and pretty common. Load test your batteries so they don't happen.
- HAVE YOUR STATUS LIGHTS VISIBLE. Both bridge and roboRIO. If I can't see the lights from 20 feet away, I can't help you debug when your robot drops.


General Field Connectivity Notes:
- Connectivity seemed pretty good this year, once a robot linked up, they very rarely dropped (and the vast majority of those were caused by something above). So if you don't want to drop, do all the above things and you should be fine.
- Driver stations were sometimes slow to connect (probably related to some of the mDNS issues above). It works the best when the laptop is plugged in after the field has completed prestart - you know this has happened when the stack lights on the scoring table turn on blue and red to signify the field is not ready.
- If you have plugged your driver station in, and it's not showing a connection, the fastest fixes were to either close and reopen the DS program, or to change your team number to a different one and back to your (both of these worked equally well for us). Then it should link right up. If not, run through the list below.
- An alternate would be to not open the driver station program until the field has been prestarted and the stack light is lit red/blue

Common DS Issues:
- Version. Update it.
- Wifi on. It shouldn't be. Turn it off.
- Firewall; just disable it.
- If no robot connection, close/reopen or change team number briefly
- If still no robot connection, restart NI mDNS Responder Service

Overall, things ran pretty smoothly - just keep an eye on the things above, and nobody should have any problems.

[fovea1959]

Originally Posted by Mr. Lim

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?