roboRIO-4787-FRC.local doesn’t point to the RIO for some reason. We’re still able to connect to the RIO through 10.47.87.2. Pings to roboRIO-4787-FRC.local give “Destination host unreachable”. Pings to 10.47.87.2 give reply as expected.
We’re able to simply build code to 10.47.87.2, but the driver station is a different story. We can’t configure it to look for particular IPs. So as a result we can build successfully, but the “Robot Code” on the DS is red. You would think the Comms light on the DS would be red but it’s green. The COMMS LED on the RoboRIO is red.
So our DS won’t let us enable the robot because it doesn’t think there’s robot code. When I FTP into the robot, there is certainly robot code. (There is an FRCUserProgram.jar with a file modified date from the last time I built the code.)
The wireless adapter on the DS computer is currently set to use DHCP. It’s a Windows 7 computer.
This might be a meaningless detail but it’s possibly related. We discovered these issues when we were demoing two different robots. We turned on our T-Shirt cannon robot and this problematic robot simultaneously. The T-Shirt robot uses a cRIO and a D-Link, it’s 2014 or 2013 hardware. But they both had the same SSID when they were both turned on. I realized they would conflict so I turned one off and I configured the bridge of the RIO to use 7874 as the team number, so that the two robots would have different SSIDs. I didn’t realize that it wouldn’t work since the roboRIO is imaged with our actual team number already. So after that I configured the RIO bridge back to 4787, we turned off the t-shirt robot and kept working on getting this problematic robot working. During this whole affair, the IP of our roboRIO was 10.47.87.59, which might be indicative of something that occurred during the SSID conflict.
Things I’ve tried:
A static DHCP lease for roboRIO-4787-FRC.local pointing to 10.47.87.2 on the OM5P config
Checked the firewall on the DS laptop (everything related to NI and driver station seems to be allowed through)
Disabled all the NICs except the wireless adapter
Made sure the NI mDNS Responder Service is running (it is and has been)
Reimaged the RIO to v19 (it was already on this image but I figured a clean slate might help
Configured the bridge with the Bridge Config Utility a few times
I have a feeling that this could be fixed by adding something to the hosts file on the robot, but I have no idea how to access that file. It doesn’t seem like I can FTP into the router itself (lies at 10.47.87.1, I used root as the password and username)
If any of this is confusing or anything needs to be clarified please don’t hesitate to ask. We could really use some help, we want our robots demo-able soon. Thank you.
It sounds like you might have a few crossed settings, but what you have sounds like it’s working just as it should.
When using DHCP your roboRIO should not be 10.47.87.2, because the DHCP range gives addresses only in the .20 to .199 range. So, when you had that 10.47.87.59 address, that was correct (expect it to change from run to run though). For a list of expected IPs see http://wpilib.screenstepslive.com/s/4485/m/13503/l/242608-roborio-networking
If the DS Comms light is green, but the robot code light is red, then almost certainly your code is crashing just after being started. The Comms light means the roboRIO FRC system code is responding, the Robot Code light means the user code is responding.
A red Comms light on the roboRIO confirms your user code isn’t talking to the DS, but the rest of it is talking.
Sometimes an easy way to tell that your code is crashing is to open the DS Log File Viewer and see if a new log gets created every few seconds. A new log gets created when your code starts, and the system this year automatically restarts the user code whenever it crashes, so you’ll see new logs started everytime the code crashes and gets restarted.
You can get more crash information by trying to start your FRCUserProgram.jar from an ssh command line directly on the roboRIO.
To test with I’d recommend that you create a new project that does nothing or simply drives without any extra code for anything else.
Aside from that, on the Driver Station Setup tab click on the down arrow next to your team number to see what roboRIOs it has detected and choose it if it’s been found.
You can also just type an IP address into the box where the team number usually goes. (But that really isn’t the problem if the Comms light is green)
Your two robot issue is solved by giving one of your robots a different SSID with all the other regular settings expected, e.g., same team number. You do that by using the radio setup tool, then browsing into one of the radios (or both of them), going to the wireless setup page and changing the SSID (we usually make it the team # and robot year-doing it now avoids any conflicts with next year’s robot).
The login is root/root, then on the OpenMesh look at Network/WiFi/radio0/ESSID
Then make your laptop only connect to the corresponding robot wireless, don’t let your laptops default to connecting to both SSIDs.
mDNS is always patchy. Even if it works, DNS requests can take 10 or 20 seconds to finish. We went to our roborio web settings page and assigned a static ip on the network tab (10.te.am.2). We set our smartdashboard 2 to use the static ip and it works much better than mDNS.
I set the roboRIO back to DHCP. It turns out it had been set to use .lan instead of .local when it deals out names. Both the DS and building to the robot are working right now.
Just as you predicted, the code is crashing every time it runs, based on the log viewer. I fixed one thing that was throwing exceptions, but I’m getting a new one, and why it’s broken is kind of enigmatic to me:
Looking at the source code it’s referencing, it seems like the backing library to the FRC-NCLib is literally failing to initialize. I don’t know where to go from here. I thought it might have to do with running it through SSH, but building with eclipse doesn’t fix the issue. It’s still crashing every time it initializes.