Static IPs on the field

[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.

[Alan Anderson]

Originally Posted by 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.

A counterpoint from another CSA:

I too helped a few teams go full-static IP in order to get their Axis cameras to work in the pit. In some cases this caused them to fail to get an FMS connection on the field until they set the Driver Station back to dynamic, though we never pinned down exactly why it wouldn't work. The defaults and fallbacks should have made everything happy.

The more stable fix was to keep everything dynamic and reconfigure the camera with the expected "axis-camera" name. This never failed on the field. It was only an issue off the field if the team's computer was one of the few to be unreasonably reluctant to release a DHCP-assigned ID, and the workaround of disabling/reenabling the Ethernet device always worked in that case.

[Fauge7]

yeah last year was funny...I made my team use a static ip because my vision program didnt like the non static. we NEVER had any connection problem but some of the other teams did when they had a non static ip. I told them to switch to static and helped them do it and boom, they had a working robot again! I was even told by a fms guy that if we had any connection problems it would be our fault...well we didnt...I would go with the static ip and will probably encourage my team to do so...

[cbf]

People -- the OpenMesh OM5P-AN radio can run a DHCP server. Enable it!

Then set a DHCP reservation to put your Robrio at the .2 address (e.g. for us that's 10.28.77.2). Set a reservation for your IP camera, if you have one (I think the old convention was the use the .5 address for the camera, or was it .11?). The OM5P-AN should be at the .1 address of course.

This is much better than statically assigned addresses because you don't have to worry about manually changing the Robrio, drive laptop, and/or camera back and forth between static and dynamic address assignment when you're testing, or at the competition -- or simply moving the laptop connection from the robot to your local WiFi because you to look something up on the Internet.

[RufflesRidge]

Originally Posted by cbf

People -- the OpenMesh OM5P-AN radio can run a DHCP server. Enable it!

Then set a DHCP reservation to put your Robrio at the .2 address (e.g. for us that's 10.28.77.2). Set a reservation for your IP camera, if you have one (I think the old convention was the use the .5 address for the camera, or was it .11?). The OM5P-AN should be at the .1 address of course.

This is much better than statically assigned addresses because you don't have to worry about manually changing the Robrio, drive laptop, and/or camera back and forth between static and dynamic address assignment when you're testing, or at the competition -- or simply moving the laptop connection from the robot to your local WiFi because you to look something up on the Internet.

This will not work at the event. Your radio will be programmed with a password by the radio kiosk at the event and you won't be able to enable the DHCP server.