I’m having a problem where I installed the driver station software on my development computer, but I’ve had problems with getting it to connect to our cRio sometimes (directly wired, so not a wireless problem).
Last night in particular, it refused to do anything other than say “No Robot Communication” However, it’s definitely lying to me. Why do I say that?
I can FTP things back and forth to the robot while it’s saying this
Netconsole works, I can see output from the robot. Nothing strange here
Using wireshark, I can see packets going back and forth rapidly to/from the computer
If I click the ‘Reboot cRio’ button on the driver station software, it works (even though the software warns me that it isn’t connected to the cRio, so I will have to physically reboot the cRio)
The ‘robot’ light in the diagnostics tab turns green for a second or two, then turns off. It also says ‘pinging’, then stops saying that.
VirtualDS 0.7 can communicate with the cRio and enable/disable it with no problems
I reformatted the cRio just in case, and no change. The driver station that I’m using shows version 11.30.11.00, and we’re running with the C++ environment.
I vaguely remember having this problem before, and then it magically fixed itself when there was a joystick plugged in. Is it a requirement to have a joystick plugged in for the driver station to work? I’ll try again tonight to see if that fixes it, as I didn’t have a joystick available to me last night.
What is the IP address of your computer? The DS expects it to be a .6 address in order to use it as a local Dashboard. An easy to fix for this is to set your team number in the Driver Station or you can manually change the IP address yourself.
The DS expects and sets a .5 address on the wired interface.
It sounds like communication may be going from the DS -> the cRIO but the status packets may not be coming back from the cRIO. This would likely be a firewall issue.
I’ve had success using different IP address than the ‘official’ address.
However, I did try setting the team number in the driver station and telling it to configure the network device. Didn’t fix it.
But then why did the virtual DS work correctly?
Also, the Driver Station software asks for administrative rights – presumably this is because it needs to disable the firewall appropriately. I can try disabling the firewall however, that might fix it.
… just looked at my firewall config, apparently I had the driver station set to be allowed on ‘private’ networks, and disallowed on ‘public’ networks. Or something stupid like that… GRR.
Can someone add something to the driver station software to check to see if it’s being firewalled so that way it can warn the user? After all, it does ask for administrative privileges.
I’ll look into it. The DS calls netsh to request that the firewall allow through various programs, but I suppose it could have forgotten itself, it could be getting an error, etc.
Just a bit more background. The terminology of the Robot Comms is a bit confusing, as it really means that the DS isn’t receiving the expected information from the FRC Communications library on the robot. This could be for many reasons, and the diagnostics tab can ping for you and show if that is the issue.
Also, the DS IP is not that important for development. After all, it is very convenient to have dev tools on other computers along with a copy of the DS. But I’m pretty sure that the field looks to talk to the DS at 10.te.am.05.
“In the IP address text box, if this computer is the Classmate and you have run the Driver Station software and successfully set your team number, you should see 10.xx.yy.5, where xx corresponds to the first one or two digits of your team number and yy corresponds to the last two digits of your team number. If this is not the classmate PC you should set the address to 10.xx.yy.6 as the Driver Station defaults to 10.xx.yy.5 for its IP address. In this text box, change the final digit .5 to .6.”