Getting the message “Warning 44002 Ping Results: link-bad, DS radio(.4)-bad, robot radio(.1)-GOOD, roboRIO(.2)-GOOD, FMS-bad FRC: Driver Station ping status has changed. Driver Station ” and though the radio is on and code is deployed, we are getting a no robot communication on the drive station.
Help?
We’re going to need some more information to be able to help. How are you trying to connect to the robot? Can you ping the roboRIO? View the webdash? What have you tried so far to get the robot to connect?
Not sure what other info is needed.
We were using the radio successfully. Student forgot the password (after the summer) so the robot was reprogrammed changing only the password. We are able to connect to the radio, the drive station PC shows connected, secure connection, no internet, which is as expected.
Before we had left the name of the robot empty. I recall the network id being 7509. It appears that 7509 may also have been entered as the robot name and the network id now shows 7509_7509.
That is as much as I can share right now, robot at school, I’m at home.
Thanks for the assist.
So it sounds like you’re able to connect to the radio. From the error message “roboRIO(.2)-GOOD” implies that the computer is able to ping the roboRIO, but no robot communication means that it isn’t being properly identified. One thing that can cause this is if the team number isn’t set in the driver station software settings tab.
When you get back to the robot, I’d try pinging the roboRIO at the expected IP to confirm that they can communicate. Then try to open the roboRIO webdash to make sure that mDNS is working properly and there’s nothing wrong with the roboRIO image. Let us know what the results of those tests are and we can help more.
The driver station shows 7509 as the team number.
How do I ping? the IP address shows 10.75.9.2.
Should the driver station use a fixed IP address or auto DHCP?
In a command prompt, run ping 10.75.09.2 and see if you get a response. You can also try running ping roborio-7509-frc.local which should do the same thing.
To open the webdash, open a web browser and go to https://roborio-7509-frc.local. If you can connect to the webdash, your roboRIO image should be okay.
The driver station can either use a static IP of 10.75.09.5 or DHCP (so long as you’re connecting through the radio which will assign the IPs). You can find the detailed routing info here
Thanks, will give it a shot. I recall last year (and pre-covid) having had difficulty connecting the radio. We have a second radio and I’m not confident that we can set that one up easily - we did try to faithfully follow all the instructions.
My goal is to have one radio for use at the shop and another for competition use. A third (we were given another) radio is intended for a test bench or another robot. We hope to keep both 2022 and 2023 robots operating. (We did not compete in 2022 but did build the 2022 Everybot. Needs some adjustments before the STEMley Cup Championships in late October. Time is now to practice driving and using the intake, shooter and climber. We may replace the passive climber with something more interesting.)
No matter what, you need to reconfigure your radio when you get to each competition, even if you haven’t configured it for home use since your last competition. So I’m not sure what you’d really be gaining by saving one radio for competition.
Hi,
When I pinged 10.75.9.2 no reply.
When I pinged roborio-7509-frc.local I did get a reply.
I can access the webdash.
Hmm… If you can ping the roboRIO with the mDNS address but not with its IP (and you’re connected via the radio not USB B), I would think that means the roboRIO is somehow at the wrong IP address. Either it’s set static incorrectly or something’s up with the radio’s DHCP. Try to check on the webdash what IP the roboRIO is set to. If it’s dynamic, you may want to reimage the radio to fix any potential DHCP problems.
Edit: Also worth checking that all your firewalls are off and the only internet adapter enabled is the one you’re using to conenct to the robot. That can cause weird problems sometimes
There are many free network scanners that will scan the IP addresses on your subnet and tell you what is where. I use them often when I can’t locate a new camera or piece of hardware that I’ve added to the network.
That’s not the correct IP address. You have a typo here or on the actual ping.
Need leading zeros
10.75.09.2
Also you can try deploying code through VS Code. It tries several addresses and may have a better error message.
No ping implementation I’ve ever seen has needed leading zeros… and if it did, you’d need up to 2 zeros, since those are 8-bit fields.
Thanks. My slavish dedication to the instructions 10.TE.AM.2 didn’t let me explore other possibilities.
If the rio is set to use DCHP The IP address is assigned by the radio. I think I was told that the later radio configs are set to assign the rio xx.xx.xx.2 but I never tested that. If not it assigns whatever is in the DCHP pool.
One way to tell is go the rio web dashboard a look at the IP assignment. "roborio-7509-frc.local " typed into a web browser should get you there if the ping works.
He said he got a ping using the mDNS address (roborio-7509-frc.local), but not using the expected roboRIO IP (10.75.9.2). It’s my understanding (and I think supported by the networking guide) that even in DHCP mode the roboRIO is always assigned an IP of 10.TE.AM.2. The only time I wouldn’t expect this to be the case is if you’re connected over USB, in which case it would be 172.22.11.2, but that shouldn’t be the case here.
So if the mDNS address works but the expected IP address doesn’t, that sounds to me like the roboRIO is at the wrong IP. You can check this in a number of ways (on the webdash, using a network scanner, SSHing into the roboRIO and running ipconfig, etc)
The other question is whether it’s an IPv4 ping reply to the mDNS address, or IPv6. If you do ping -4 roborio-7509-frc.local does it go through? I’ve seen cases when the computer and roboRIO are on different IPv4 subnets/incorrect IPv4 addresses/masks such that mDNS IPv6 can be successfully reached, but not IPv4. Checking the computer network address with ipconfig can help verify.
@auscompgeek Thanks for the thumbs up from down-under. I got a chuckle out of that - everything is upside down South of the equator! My suggesting letting VSCode do the diagnosing was brilliant as are most of my posts but not so much do people use the counter - it’s not like StackOverflow here on CD. And obviously my incorrect, harmless miscue was neutral and wasn’t worth anything except I learned something. Keep up the nice comments - it’s all about inspiring people and you certainly did that this evening.
A couple quick network troubleshooting steps (assuming you are on a Windows machine). From a Command Prompt (CMD) - where you do your ping test:
You can then piece together those info to make sure that you are 1st on the same subnet and there’s no additional networks that are using the same IP blocks, etc. (i.e. laptop/computer with more than 1 network active).
Similar to the ping as advised above use the -4 on tracert and it’ll tell you the IP address in the form you might be expecting (e.g. 10.75.9.2 or whatever was assigned dynamically).
ping -4 tracert roborio-7509-frc.local
tracert -4 roborio-7509-frc.local
ipconfig /all