Static IPs on the field

[wireties]

We've been using statics IPs on the roboRio during practice. Can we leave it that way on the field with the FMS etc?

TIA

[Jaci]

It would be best to assume that all IPs will be dynamically addressed. You can use roborio-TEAM-frc.local instead, as it will resolve to the RoboRIO's IP address

[Tom Bottiglieri]

We static our roborio to 10.2.54.2 as mdns sometimes caches addresses incorrectly on our macs. I believe the DHCP server on the field only hands out addresses above 10.x.y.10, but it would be nice if someone with more official documentation could verify this.

[Andrew Schreiber]

Originally Posted by Tom Bottiglieri

We static our roborio to 10.2.54.2 as mdns sometimes caches addresses incorrectly on our macs. I believe the DHCP server on the field only hands out addresses above 10.x.y.10, but it would be nice if someone with more official documentation could verify this.

We ran into this issue at Merrimack this weekend. Our students had set the IP to 10.1.25.72 (for some reason) and the field couldn't find us. Changing it to 10.1.25.2 fixed this issue. From what the folks were saying there, if you are going with static... use 10.xx.yy..2 as it's the fallback. If you have no reason not to use mDNS, just use mDNS.

[Thad House]

It should work.

Because of all of these issues teams are having, I'm actually thinking about sending an email to FIRST after the season, requesting that the RoboRIO only gets moved back to a static IP. You can leave the DHCP server on the radio, and that will properly hand out IP's to every other device. However the DS and FMS could connect to 10.TE.AM.2, and completely skip mDNS. This seems like it would fix almost every issue with the new radio setup, and still not require static IPs on the laptop, which was the goal, at least from what I remember. The only issue this brings up is you wouldn't be able to directly ethernet connect from the RoboRIO to a laptop, however doens't work half the time anyway, so another solution really needs to be found anyway.

[JohnGilb]

I concur - throughout the season, while using MDNS, I have seen situations where one or more of the below things working while the others don't:
- Ping via CMD window
- Ping via Powershell window
- FRC Driver Station
- SmartDashboard
- SFX (SmartDashboard 2.0)
- Deploy code via Eclipse
- roboRIO web portal

It's really a mess. mDNS is great when it's working, but when it isn't, we have to just continuously reboot the robot/computer/disconnect & reconnect adapters/plug in a cable, then unplug it and wait 10 seconds/etc... and just hope that something will work.

Static IPs were inconvenient but relatively bulletproof - and in the world of FRC robotics I often value robustness over feature richness.

[Thad House]

Originally Posted by JohnGilb

I concur - throughout the season, while using MDNS, I have seen situations where one or more of the below things working while the others don't:
- Ping via CMD window
- Ping via Powershell window
- FRC Driver Station
- SmartDashboard
- SFX (SmartDashboard 2.0)
- Deploy code via Eclipse
- roboRIO web portal

It's really a mess. mDNS is great when it's working, but when it isn't, we have to just continuously reboot the robot/computer/disconnect & reconnect adapters/plug in a cable, then unplug it and wait 10 seconds/etc... and just hope that something will work.

Static IPs were inconvenient but relatively bulletproof - and in the world of FRC robotics I often value robustness over feature richness.

Plus if you do have a DHCP server on the radio, you get most of the convenience back. IP's would still get handed out to the DS. Plus mDNS never really has worked on things like camera's and offboard processors, which we just set static anyway.

[Mark McLeod]

That's funny. DHCP always works for me, but I have sometimes had to clear the mDNS cache on my macs, and I've run into team laptops that won't give up an assigned IP address for an inordinate amount of time...

There are other issues with setting only the roboRIO to a static IP, as in it won't work in the pits at competition...I think long term everything will get moved to pure DNS.

[Thad House]

Originally Posted by Mark McLeod

There are other issues with setting only the roboRIO to a static IP, as in it won't work in the pits at competition...

This is already an issue. In fact, I'd say its worse, since it occasionally does work, but not usually. With no DHCP server, it has to use self assigned IP's, which do not seem to work often, especially noticeable with newer computers and OS's for some reason. We exclusively use USB for pre-match tethering specifically because of this.

[Mark McLeod]

Using only a USB tether means you can't use your IP camera in the pit.
For PC's that won't give up the field IP assignment use ipconfig /renew

Most of the half hearted home grown solutions cause problems for teams that copy it, but don't understand how IP works.

There was some pre-ship scrimmage that was surprised when teams got different robot cameras because they used a flat network and all the cameras had identical names.

[rich2202]

This worked in the past (and should currently work too):

1) Static IP Address on the RoboRio 10.x.y.2
2) DHCP on the Radio
3) Static IP Address on the 1st Camera 10.x.y.12
4) Static IP Address for the DS Hard Wire Connection 10.x.y.5
5) Dynamic IP Address for the DS WiFi

The only time DS is connected by hardwire is when it is tethered to the robot, or the FMS system. So, no IP Conflict ever happens.

When the DS is connected by Wifi, it is either to the Robot, or the School's Wifi. Either the Radio or the School's wifi gives it an IP address, so there is no conflict.

If some people use a hardwire internet connection, that could be a problem.

Note: We have 4 DS, and they never talk to each other directly, so there is no IP conflict.

[rich2202]

I asked a Q&A to be allowed to go back to the old method of Static IP addresses.

Q901

[rich2202]

Originally Posted by Thad House

With no DHCP server, it has to use self assigned IP's, which do not seem to work often, especially noticeable with newer computers and OS's for some reason.

My guess is that your setup is: Dynamic IP address on the Driver Station Hardwire Port.

When you tether into a port on the Radio, everything works fine because it gets an IP address from the Radio.

However, when you tether directly to the RoboRio, it may or may not work. It works if the last IP address it got was from the Radio. If it wasn't then it has a random IP address and can't find the RoboRio.

Newer computers and OS's may be a problem because they may drop the old IP address faster, and give you a random one if it doesn't get one from a DHCP server. Assigning a Static IP address (self assigned) should work regardless of age of computer and OS.

[Greg McKaskle]

When you believe that either IP assignment or mDNS are failing, what type of network connection is it? USB, ethernet, or wifi? I use USB more than the others just because of how I set my stuff up. The team uses wifi almost exclusively -- except for the times when the OpenMesh made a bad channel choice and plays the retransmission game.

It would be good to get a sense of whether this is more common to direct tethered ethernet and self-assigned IPs, or to situations when the OpenMesh is involved.

I'll change my habits and use one of the other laptops to see if I can see this happen. Meanwhile, if you get in this situation, please use a command window and ipconfig to see if your laptop IP makes sense (DHCP should give out addresses above 20 I'm pretty sure, and when the OpenMesh isn't involved, the ethernet should be 169.254.xx.xx. The USB should always be 172.22.11.1.

Also, if you get in this situation, one thing to try is to shutdown other interfaces. Try shutting down wifi to see if direct ethernet works.

And of course, please post things that seem to help.
Greg McKaskle

[dvanvoorst]

Using static IPs was not an issue last year. As CSA I helped a handful of teams switch everything to static to resolve issues with communicating with their Axis cameras. This was done after consulting with FIRST technical support. This provided consistent camera operation both in the pits and on the field.