We have a workaround currently but we were wondering if anyone else has run into this issue yet.
After changing the battery in our robot we are unable to reestablish communication with the driver station until the Classmate is completely restarted. In previous years we could turn off the robot and then power it back up and it would reinstate communication in a reasonable time without having to do anything with the driver station.
It is not a show stopper right now but it does slow down our power cycle capability and seeing as we are gonna need maximum time between matches for compressor running, this could be a problem at competition.
I haven’t had any problems with that over a wired connection. It might be something funky with the wireless AP dropping out and the classmate not wanting to reconnect. Or better yet, the classmate might be connecting to another wireless network after the robot one drops out. Try doing this in Developer so you can monitor what the classmate’s Wifi is doing and what network it’s connecting to.
Didn’t think about it swapping to another network, I will definitely check that out tomorrow and see if that could be part of the problem. Thanks!
It was not connecting to another network and still gives the original posts symptoms. Any other ideas.
I think it’s just a “feature” of the software this year. For us, the driver station won’t automatically connect to our bridge. Any time we reboot the bot, we need to go to the developer account and reconnect. But it only happens over wireless.
Good to know I guess. We have just been rebooting and restarting everytime. It is a real pain in the booty. If that is a “feature” I would really appreciate them removing it. It is nice that it might work fine on the tether. I will have to give it a try.
I don’t think this is a feature. It is Windows that connects to the DLink and the dialog has an auto-connect option. The DS just looks for a robot IP. It isn’t choosy about whether it is over ethernet, bridge, access point, infrastructure router, etc.
Greg McKaskle
as far as i know it is not a feature. we are having the same issue. ours reestablishes once we restart the driver station software. As far as I can tell, it is reconnecting to the bridge, but not getting to the rio. secondly, once we reconnect to the bridge, we can ping it, but we are unable to ping the rio. we close the Driver station software, and our pings start to get through.
Thats what data we have collected thus far. hope it helps! keep us posted!
If you have a sequence that gets it into this state, here is what I’d like you to do.
Click on the DS Diagnostics tab. The Communications LEDs on the central column are mostly ping results. The DS is pinging one a second and showing the results. Please report what you see.
Go to the taskbar and hover over the network icon and see if the laptop is connected to a network that makes sense.
Next, launch a command prompt, ideally as admin. Enter the command
arp -av
and copy/paste the results for a post. Then try an arp -d and see if that enables the connection to proceed.
Finally, please log into the DLink and see if mac address cloning it on or off.
My suspicion is that the boot order and boot time are causing the DLink to build a routing table that is incorrect. The DS actually looks for this and invokes the arp -d to try to correct the issue, but I think the OS may now require elevation to do that.
Please report back with what you find along with the step by step procedure you use to get your robot into that state.
Greg McKaskle
Our robot got bagged yesterday and it is complete so the control system is out of my hands. By the time I can touch it again there is nothing I could do to help with the troubleshooting.
Maybe one of the other teams having this problem has a practice robot that they can use to diagnose with the instructions you provided.
Thanks!
we have a test bot that we are still in possession of. Our team recently bagged and tagged, but we are reconvening on Saturday. I will post the results of that test afterwards.
Two other things to test if it is repeatable. The OP was rebooting the DS to get it out of this state. Please do isolated reboots of the other elements. Disconnect and reconnect power to the DLink and see if the connection is reestablished. Also press the reset button on the cRIO. Please report back which isolated reboots got the system out of the noncommunicating state and which didn’t.
Greg McKaskle
Alright, good news and bad news…
bad news first, have ever hard we tried, we could not reproduce the problem.
good news, this narrows down the reason for the problem. there are basically three things different between this bot, and the actual robot we shipped.
1: this is an 8 slot rio, while the other is a 4. they have the same image ((this one modified for 2CAN)) and the same code though
2: this is an older D-Link ((this is my main hypothisis for the problem))
3: this is imaged for 2CAN and runs through a 2CAN while our main bot is directly connected to the D-Link
as i said, my main idea is the problem is in the D-Link, but since ours is bagged with our robot, there is no way to be sure… sorry, hope this helps.