Our team has been having periodic communications loss with one of our robots and we’re having trouble figuring out what the cause is.
Within about 5-15 of connecting to the robot we experience a loss in communications. The wifi network remains online and we can see that the radio is fully powered. The FRC driver station software indicates that a loss of communications has occurred. Closing and reopening the FRC driver station doesn’t change anything. Each time this issue occurs we power cycle the robot and the issue is temporarily resolved.
The radio is powered by a standard REV PoE injector which is connected directly to the roboRIO. Because the wifi network never drops out I don’t think this is a radio issue. We tried swapping that radio with a Known Good Radio and the issue persisted. We don’t use the 2nd ethernet port on the radio.
The comm indicator light on the roboRIO seems to be very inconsistent with the actual state of communications. Sometimes the light would be green while the issue occurred and we had communications. Sometimes the light would be off while we were connected just fine. Perhaps I’m misunderstanding what that indicator is for?
The robot was entirely stationary when these issues occurred. We are in our robotics lab, not at an event. When communications actually are working we’re able to deploy code, control the robot, etc. without any issues.
Any ideas of what this could be? We’re having a meeting today and I plan to swap the ethernet cable connecting the roboRIO to the router just in case it’s faulty.
You’re not experiencing any type of brown out on the RIO, correct? I would double check your power wiring to the RIO as well. We saw a few times this year where the RIO was powered from the VRM, and that would most definitely cause RIO issues.
This looks like a situation where the roboRIO is not responding.
Can you ping your roboRIO while this happens? If yes, can you SSH into it?
Also, do have any I2C device connected (or leftover code reading from the I2C port)?
The roboRIO was connected to a VRM instead of directly to the PDP, which was likely responsible for brownouts like you said. We also noticed that in the driver station software the reported battery voltage always seemed lower than what our other robots would report (other robots said 12.5V, the faulty one reported 11.8V).