Robot Running with 100% Packet Lost Reported by the Driver Station

[zzpDavid2]

In the recent competition, my team has realized the severity of a comms issue with the driver station. The driver station would show a 100% packet lost but the robot will still run. However, this led to disconnections from time to time and the communications bar on the driver station will be half red some of the time.

With the help of a very kind and helpful CSA, we have isolated the issue to be a problem with the code since loading a sample program would resolve the issue. However, we just could not find anything wrong with the code.

Does anyone know a possible cause of this issue? I will be further isolating the problem in the code by uncommenting it part by part. I will post my findings when I do find the issue.

Here is the code for anything who is willing to help find some potential issues: https://github.com/frc3566/2022-Rapid-React/tree/main/SMFRC

[NewtonCrosby]

More than likely you’re saturating the 4MB limit per robot with your camera.

What is your camera setup, and how do you calibrate it or limit the framerate and resolution etc?

[Mark_McLeod]

The bandwidth measurement isn’t on the outbound (highest priority) control packets from the PC, but on the inbound (lowest priority) status packets received by the PC.

So in the case of bandwidth saturation, as Newton suggested (and I agree-it’s your camera feeds), the robot control packets are given priority and get through so robot control can still be normal. The status packets and camera streaming coming into the PC will get dropped first.

The half red/half green indicator is indicating UDP (the green half) control packets are getting through, but TCP (the red half) user packets are getting dropped.
When bandwidth gets really overloaded the control packets start getting dropped too and the robot begins to behave erratically.

Here’s how to measure bandwidth usage:

Measuring Bandwidth Usage

[zzpDavid2]

Thanks for the replies. I did further testing today and the problem isn’t seem to be caused by the camera because it still occurs when the roborio is directly connected to the driver station without the radio, switch, or any camera. Although, bandwidth was indeed a factor that contributed to the disconnection.

By isolating the problem, it seems like the problem is coming from the disabled comment that I wrote to be scheduled in disabled init. There isn’t anything that seems to be improper in the comment, where it’s just setting the motors to zero in the init and end functions. However, removing it altogether seems to solve the issue.

I am also not sure if this is the same issue that we run into during the competition. At the moment, we could only observe packet and ping spiking very high periodically when the robot is disabled. However, the comms seemed to maintain at 100% in both tele-op and disabled during the competition.