[Ken Streeter]

Originally Posted by Greg McKaskle

I understand that static IPs are a solution of sorts, but they introduce other issues, especially when that robot shows up at an event. The robot won't connect to the field, so the CSA or FTA discovers and changes the roboRIO and DS laptop settings. But that may break the programming laptop connectivity, so the team may change it back again, ...

Are there problems with using the *correct* static IP for the roboRIO (10.te.am.2) or are the problems only when using a non-standard static IP?

We used mDNS dynamic IPs for all of the beta testing season and it worked very well as long as we used that computer only as a driver station, where the only active network interface was connected to an SSID "1519" Cisco router, with the OM5P-AN in bridge mode.

However, if we changed to our preferred situation of having two active network interfaces: (1) a physical ethernet cable to an SSID "1519" Cisco router, and (2) a WiFi DHCP connection to a different WiFi network for Internet access, we would get very unpredictable results.

Switching to a static IP address (the correct 10.te.am.2 address) helps a lot with the issues we've been seeing.

For what it's worth, we competed at the "Week Zero" scrimmage event in NH with the real FIRST field using the correct (10.te.am.2) static IP address and encountered zero problems.

Call me paranoid, but I remain a big believer in using static IP addresses for the roboRIO, the OM5P-AN bridge, any other IP devices on the robot (we use 1 or 2 Axis 206 cameras), the driver station laptop, and (when at our build area) the router which serves the "TEAM" SSID network (e.g. "1519").