Robot losing comms constantly

Our robot has constantly been dropping communications when trying to drive through radio. Both the robot code and the communications bar alternate quickly between green and red in the driver station. The error does not occur when tethered to RoboRIO. We’ve tried both replacing the Ethernet and the radio, both of which have not solved the issue. Any ideas on what may be causing this to happen?

1 Like

Have you tried to replace the ethernet cable between the Rio and Radio? Also how is your radio powered? Are you programming your radio with the same laptop you’re using for your DS?

We’ve tried replacing the ethernet to no avail. The radio has been powered with both a barrel connector and POE, although the last thing we tried was only the barrel connector as we though the POE cable may have been an issue (which it is clearly not anymore). We did program the radio with the same laptop as the DS.

This years radio programming tool has the ability to create a virtual loopback network adapter which can cause some conflict with comms. Go into the windows network settings and see if there is a loopback adapter there, if there is disable it and see if that works. Also try to run the DS on a different laptop and see if that works to help narrow down the problem.

Also when you plug the ethernet cord into the radio, are you using the port closest to the barrel jack or the one away from the barrel jack?

We’ve found that BSD WiFi interferes with robot communication. Try going to a place where there is no district WiFi and see if that solves the issue.

I’ll take a look to see if a loopback adapter exists tomorrow once I have robot access. We’ve tried running the DS on a different laptop already; it started working fine, but the issues appeared again after a couple minutes.

We are using the closest port for Ethernet, although occasionally we’ve tried the POE cable plugged in with the Ethernet cord in the port beside it. Both seem to have not solved the issue.

We’ll give that a shot tomorrow. Thanks!

Do you have anything other than the radio on your VRM?

We had this exact issue yesterday, and it turned out to be our code – we had some things in execute rather than initialize (like setting stator current limits or brake/coast mode) on several continuous commands, and it was overwhelming our CAN bus and causing comms to crash.

We thought it was hardware, but a code cleanup fixed it right up.

Throwing out one thing that happened to us last year, just in case. Probably not it, but…

For debugging purposes, we had a whole lot of system.out.println() statements. It turns out those are resource hogs. That plus our camera feed was knocking us off the network, with flashing half green half red communication lights.

We had this happen last year during an event. It turns out that it was a faulty contact from the VRM to the PDP. The spring connector on the VRM had worn out. Replacing the VRM fixed it. This year, we are using the jst connector board that Swyft sells.

The only thing wired into our VRM is the barrel connector and the POE cable, both for the radio.

Are you Tethered Directly to the Rio? If so you my not see the brown out while tethered. Have you checked your logs to see how much the drive motors are pulling? You might be experiencing a brown out and the radio is dropping. We saw this over the weekend and had to lower our current limit on our drive motors.

Another thing to try is shutting of the lights in the room. LED’s can have a huge impact on WIFI signals. Especially cheap LED lights. Doesn’t happen often but easily ruled out.

Check your logs it will tell you what’s going on.

From a hardware standpoint:

There are three single point failure possibilities; the PDP (including the terminals feeding the VRM), the cable from the PDP to the VRM, and the VRM (including all terminals).

Are you using old PDP, VRM, or wiring? If so, you might consider changing these out.
Are you using a PCM? If not, you might swap the wire ports used at the PDP (there are two sets of ports to feed both a VRM and PCM).
Double and triple check the 20A (yellow) fuse on the PDP. Make extra sure that the fuse is fully seated in the PDP.

Following @keval_shah’s advice, we moved away from the school, which seemed to have solved our comms issue. However, a new problem has popped up in which the robot pauses often. The RSL appears to “freeze” on a solid light in between blinks. Our Talon SRX’s are also flashing when that occurs. Any idea what is causing this issue?

Does the robot become unresponsive while the rsl is solid?

Yes it does

Tends to be that it’s actually the robot briefly losing communication. Next time you’re having this issue, have someone watch the driverstation and check if robot comms are half dropping. I’ll check what our solution for this problem was tomorrow.

last year, we discovered insulating our radio inside a metal electrical box blocked signals a lot. besides this, you might also check loose connections as we had one on our circuit breaker.

We have our radio on the outside of our robot, so I don’t believe we should be getting any interference there. We did try going through all relevant wires, although we can give it another shot.