Our last robot had a few… colourful issues that were never resolved including an issue with our onboard raspberry pi that we used for vision. For some odd reason the onboard radio failed to assign an IP to the raspberry pi. We changed the IP and Hostname to static, but it didn’t fix anything. The only thing that worked was that we turned off the onboard hub, RoboRIO, Pi, and radio then turned them on in a specific order (Hub, Pi, Radio and Rio). We tried this without the hub and we couldn’t get it to work at all. My mentor and I think that the Radio’s firmware searches for the Rio one by one, increasing each time, looking for the Rio until it finds it then stops all together. The solution works, but I’d like a more reliable way to ensure the raspberry pi gets an IP. Any ideas?
We experienced the same issue last year with a Jetson TK1 and were never able to resolve it! I’d say the connection worked 2/3 of the time, but we were never able to pin down the exact method or boot order to prevent it from happening. I would definitely also appreciate anyone’s suggestions on the matter.
I may be completely missing what’s going on, since it has been a while, but if the IP is set to static on the Raspberry Pi then the router shouldn’t have anything to do with it getting an IP in the first place, right? When you set the IP of the RasPi to a static value, it should have that IP permanently on that network interface regardless of what it is plugged into, or even if it is plugged in at all. Now if the router is then refusing to route traffic to that static IP, that would be a completely different issue.
If I remember correctly from my experience with setting a static IP on a Raspberry Pi, it’s not a simple task, and the first method I tried just plain didn’t work. Are you sure it actually took?
Yep, it worked enough to debug our vision setup
My team’s issue, which sounds similar to what @n30b4rt is experiencing, is that when using a static IP address, the radio occasionally seems not to even acknowledge the device’s presence. When issues arise, I’m able to hook up a keyboard and monitor to the co-processor and try pinging the radio and roboRio at 10.25.21.1 and 10.25.21.2 respectively, but they both fail.
When I instead allow DHCP to handle the IP assignments, I don’t receive an IP at pretty much the same frequency as I have trouble with the static IP. This makes it seem that there is definitely some link between the two, but one I haven’t been able to figure out yet after an entire summer of troubleshooting.
Again, the odd part here is that these issues both happen occasionally and at the same frequency, about 1/3 of the time.
In addition, a static requires the correct subnet depending on if you are on a competition field, or at home/pits. On the field under control of FMS, that subnet is a /8 (255.0.0.0), off the field it is a /24 (255.255.255.0).
Here’s the contents of my device’s /etc/network/interfaces, setting the static IP address to 10.25.21.17:
auto eth0
iface eth0 inet static
address 10.25.21.17
netmask 255.255.255.0
network 10.25.21.0
broadcast 10.25.21.255
gateway 10.25.21.1
As far as I can tell, this configuration seems correct for an off-the-field setup. I’m very confused by the challenges faced trying to get the device to reliably communicate with the radio/roboRIO.
Definitely sounds like a firmware issue with the radio to me. Have you guys been able to try with another radio to see if its a setup thing or an issue with the physical model? Not that the radio configuration software really gives you a lot of choices in regards to setup lol
At this point I’m sure I’m probably just restating things that have already gone through your heads in trying to debug this the first time. Hope I’m not being too repetitive.
That’s a really good point – I haven’t tried a different radio, but I have tried re-flashing the one I’m currently using several times. I’m using the OM5P-AC from the 2018 KOP, would be very interested to hear what @n30b4rt is using. I’ll give the 2017 model a shot and see if that fixes anything by any chance! I’ll also try flashing the 2019 radio firmware tomorrow and see if that potentially solves anything.
Also, another thought: have you guys tried hooking up other devices via ethernet to see if they have similar issues when connected to the radio?
That should “just work”. Just for fun, do you have a switch that you could put in there? Have the roboRIO, Pi, and radio all on their own ports to take the radio possibly not routing properly out of the equation. That would at least isolate the radio as the offender.
Thanks for the suggestions! I’ll try these out this weekend and report back any findings. 
We anxiously await the results haha 
Have you checked the logs of the pi to see what’s going on? Is the Ethernet link active but IP addressing simply doesn’t work, or is the link not even working (you should be able to check using ethtool).
I’ve had some issues today as well getting the Ethernet port on older radios to work, haven’t done any detailed debugging yet but I’m assuming it’s because the physical link between the two devices were not successful.
The Pi is, of course, running Linux which is the most exercised network stack on the planet. It is not likely there is something wrong in Linux. The static config above looks correct. Further I would set the roboRio to a static IP address. Then I would look for physical electrical/network connection issues.
Make sure the network mask config matches when the radio is routing or bridging as mentioned by others in the thread. The mask is wider when the radio is bridging. If you can ping the local IP address of the radio ports and not the Pi the problem has to be physical/electrical.
We have a stable test robot with four RPi3s connected through an onboard switch, and has regularly but not frequently exhibited what surely must be the same problem.
If I recall correctly, the symptom we see is not being able to ping the RPi3s at all from the DS, even though they and the RR all have static addresses. If you ssh to the RR you can reach the RPi3s from there (The RPi3s are all of course are connected to through the switch, but I believe the problem is independent of whether the RR is connected directly to the radio or to the switch. I must emphasize this is all IIRC; usually when it happens we’re trying to do something and are focused on just getting the blasted thing to work rather than running careful experiments. Next time we see it I will try to stop and do that. If anyone wants to suggest specific tests to run when we next see it I’ll try to get them executed and post the results.
One of the things I intensely dislike about this radio is the apparent (?) lack of any diagnostic tools. Can you even log in to the thing? I like turnkey black boxes as much as the next guy, but hold them to a higher standard of “it just works”. When mysterious problems appear, whether they’re its fault or not, it offers little assistance in diagnosing them.
I updated the radio’s firmware to the 2019 version last night, and lo and behold, the issue seemed to (mostly) go away! Where the Jetson used to be unpingable 1/4-1/3 of the time, it only happened once in about 12-15 boots after the firmware update. The one time it did happen, all I did to fix it was unplug the ethernet cable and plug it back in.
I’ll continue doing some more testing this evening – hopefully this firmware update resolves the problem!
+100 on this. Debugging any issues with the radio is painful, and has been for at least the last 3 years.
Sweet. Good to know that it’s at least less of a problem with this year’s firmware. Hopefully results from other teams show the same thing.
Also adding my vote for FIRST finding a radio that will actually let us figure out what’s happening when things suddenly stop working.