Unable to connect to Raspberry Pi at competition.

We had everything communicating well at the workshop, but when we configured the radio at competition, it stopped communicating. We are able to connect to it if we run an Ethernet cable from a laptop to the first Ethernet port on the radio, and an Ethernet cable from the second port on the radio to the raspberry pi.

However, when our drivers connect on the field, if they ping the IP address, we get no response. Has anyone had this problem previously, and/or does anyone know how to fix it?

Hi. We had a slightly similar issue last year.

The networking configuration is different between home, pits and on the field. The following articles can help explain how they are set up - This one on networking basics: https://wpilib.screenstepslive.com/s/4485/m/13503/l/696075-networking-basics and this one on the configurations at competition: https://wpilib.screenstepslive.com/s/4485/m/24193/l/319135?data-resolve-url=true&data-manual-id=24193 .

Personally, I think that teams should set everything to static if their network set up is anything more than the minimum (a RoboRIO and the driver station).
I would set up your network according to how the “IP Networking at the Event” suggests for the static configuration. i.e.


Static (workaround configuration)

It is also possible to configure static IPs on your devices to accommodate devices or software which do not support mDNS. When doing so you want to make sure to avoid addresses that will be in use when the robot is on the field network. These addresses are 10.TE.AM.1 and 10.TE.AM.4 for the OpenMesh radio and the field access point and anything 10.TE.AM.20 and up which may be assigned to a device still configured for DHCP. The roboRIO network configuration can be set from the webdashboard.

    OpenMesh radio - Static 10.TE.AM.1 programmed by Kiosk
    roboRIO - Static 10.TE.AM.2 would be a reasonable choice, subnet mask of 255.255.255.0 (default)
    Driver Station - Static 10.TE.AM.5 would be a reasonable choice, subnet mask must be 255.0.0.0
    IP Camera (if used) - Static 10.TE.AM.11 would be a reasonable choice, subnet 255.255.255.0 should be fine
    Other devices - Static 10.TE.AM.6-.10 or .12-.19 (.11 if camera not present) subnet 255.255.255.0

.

If you do make your devices static, everything must be made static or else you will have problems (i.e. the RoboRIO, the Driver Station and the RPI).

If you do make things static, you will have to use their static IP’s rather than their mDNS names, so “roboRIO-TEAM-FRC.local” will become “10.TE.AM.2”

Note: A guide to setting static IP’s on RPI’s can be found at https://www.modmypi.com/blog/how-to-give-your-raspberry-pi-a-static-ip-address-update
Setting a static IP on the RoboRIO is done through the web dashboard (click on the blue Ethernet cable icon.)
To set a static IP on the driver station, right click on the WIFI symbol in the task bar, go “Open Network & sharing center” then “Change adapter settings”, right-click on the adapter (i.e. Ethernet) then Proprieties and double click “Internet Protocol Version 4 (TCP/IPv4)” then select “Use the following IP address” and set it to what the ScreenSteps guide says to. Post-competition to access the internet, set it back to “Obtain an IP address automatically”.

mDNS and statics are not mutually exclusive. You can statically IPs and the mDNS address should still resolve. However if you assign statically you might as well use the IP address rather than the mDNS address.

This is my regular advice every time this issue comes up.

Move to Static IP’s

DS 10.TE.AM.5
RoboRio 10.TE.AM.2
RPi 10.TE.AM.10 (Although .11 works too.)

Ah wish id known this before the competition. Of course, sadly thats my own fault :frowning:

Agreed. But refined here. This clarification matters when connecting to FMS, .

DS 10.TE.AM.5 with mask= 255.0.0.0 (MANDATORY)
RoboRio 10.TE.AM.2 with mask 255.0.0.0 (to ensure lan-ARP results get resolved every time)
RPi 10.TE.AM.10 (/8 mask suggest for consistency)
RPi2 10.TE.AM.11 (/8 mask suggest for consistency)

I, personally, liked using static addressing on the bot. But FIRST seems to prefer DHCP and mDNS, so I’ve been slowly moving to it. It has been a lot more trouble free than I expected. And it works fine on the field. And you can mix static 10.te.am.nnn addressing on the field. BUT NOT IN THE PIT, where there is no DHCP server handing out 10.te.am.0 addresses. If all your devices in the pit use DHCP, then they can all go to the IPv4 link local 169.254.0.0/16 range. Last year, I loaded up an OpenDHCP server; this year I just lived in the 169.254.0.0 space in the pit. One laptop was particularly slow to give up on DHCP and switch to link local, but otherwise, the RPi, the RoboRio and my laptops chatted quite nicely.

What burned me most at this last regional was forgetting that 22 was a blocked port on the field, so we couldn’t log on to the RPi to check on a missing process on the field. I had to move SSH somewhere else on the RPi. Oh, and not wanting to unplug a device on which I’m loading firmware. Geesh.

My observations from Week 1.

  1. L.V. teams should look for a patch if they show a camera stream on the LV dashboard.

  2. Be SURE that you wait for the succeeded/failed message when you perform the FMS-radio setup.

  3. (apparently new with 2017 radios?) Be sure to connect your rio to the Ethernet port next to the power-pole. Yes, unlike the image in the radio-setup instruction. Not doing this has a random chance of not connecting before each match.

  4. If you have trouble with DHCP/mDNS off of FMS, then I don’t know of any reason that static doesn’t work when it is setup correctly. When it is right it connects every time and the FTA team won’t advise otherwise.

  5. If you have a connection and you lose it - you likely have a power loss or a bad port/cable, recheck wires to everything.

This is actually true for both the 2016 and 2017 radios, but new this is year is a rule enforcing it (R63).

Both ports should work, and often times they do. However, in some cases the roboRIO just doesn’t cooperate with the other port, so it is safest to use the one closest to the power jack.