Over this weekend’s Orlando regional we took a look at some data and noticed we experienced packet losses. Is it normal to experience some level of this with some standard deviation? If not, what is the best way to isolate this issue and what source factors into the actual measurement? Is it packet loss to and from Driver station to the robot? To and from robot to FMS?
One observation from the pic below is that the highest spike in loss correlates to a spike in latency at the beginning of the match (in auto I presume)
I don’t know what numbers are normal because I don’t have our DS logs in front of me this morning but 20-25% does seem high. Packet loss did cause us latency at champs last year so if you had latency it was likely the causse. Our issue was a bad ethernet cable.
The best way to track down packet loss issues is to start swapping out the pieces in your network path. The cables from the radio to the rio, maybe the switch if you have one, and the radio itself. Also which port on the radio are you using? The recommendation is to use the one by the power port because the other one has issues.
After champs last year we bought an ethernet tester to verify our cables. Since then it has detected no bad cables though.
1 Like
We are using the port closest to the power port of the radio. We are also using PoE for the limelight and are using the 2nd port in the radio. In taking a close look at the blue Ethernet cable, I actually don’t like the bend radius on it. I’ll have the team perform some experiments with some new cables, and also look into getting a tester as well.
Don’t use the second radio port, get a network switch. The second radio port randomly fails to work (it’s a hardware/firmware bug, affects all radios and is unfixable). This wouldn’t cause the packet loss issues, but would cause far more frustrating issues if it happened on the field.
3 Likes
Will do, thanks for the recommendation. Is that a Pinned post somewhere or in another article/thread for reference?
We also had major packet loss on Thursday due to high bandwidth usage. We were using 2 cameras on our robot, a limelight and usb cam and we forgot to limit the stream quality and fps on the usb cam. This caused packet loss across the entire alliance this could have caused this issue or just a bad ethernet cable.
It’s worth mentioning that this is almost certainly irrelevant to the OP since the rio is connected to port 1 and the packet loss shown in the logs is specifically measuring DS<->Rio control packets. That said, the advice is generally good for reasons mentioned in the linked post.
It’s also worth mentioning that the “lost packets” measurement is FAR from perfect. It will report a packet as lost if it’s simply late (by a certain margin that I don’t remember offhand), but may still act on the data of that packet after it arrives (therefore not actually lost, just delayed)
1 Like
That spike at the beginning looks like it correlates to the driver station connecting (ie, 100% packet loss immediately before the log starts)- there is no other data before that point, and the robot does not look like it’s enabled at all in that image.
The rest of your log looks pretty good in terms of packet loss. I wouldn’t be too concerned about it, some sporadic packet loss is to be expected.
2 Likes
If you see this when you are at an event, feel free to go to the question box and ask to see the match on the field monitor. That will let you see whether the issue is independent or correlated with other teams in the match.
