According to Deep Space R37B:
B. Bandwidth: no more than 4 Mbits/second
Then according to the FMS whitepaper (Under Network Bandwidth) :
The FMS Field Network has limited bandwidth available. There is an imposed 7Mbit/s limit for each team via the robot radios to ensure no one team overloads the system, causing packets to drop for other teams
Both documents are updated to 2019.
Am I understanding this improperly, or is there a discrepancy?
It seems as though some pages on screensteps say they are updated for 2019 but are actually not. I would trust the manual.
Ahh, nevermind.
Left side of the FMS whitepaper:
Last Updated Jan 05, 2018
I guess 4mbit/s is the new limit
Indeed, the “New for 2019” page on screenstepslive says:
- Bandwidth - Bandwidth limit has been reduced to 4 Mbps. Like airline and hotel booking, the 7 Mbps limit included some assumptions that not all teams would use it. With the Sandstorm driving expected camera usage, we have lowered the limit in attempt to limit the likelihood teams will need to reduce below the limit at an event.
I meant to start a thread on this yesterday. Cameras that are running 640x480 @ 30 FPS will use as much as 5 Mb/S.
The robot control traffic gets priority, but if the channel is full it is still slowed.
What I see on the FMS at that point is your trip latency going up. It can go from 5 to 50 milliseconds. I’ll routinely inform the CSAs when I see that happening, but every team is better off not running into that problem in the first place.
Everyone will be using a camera during the sandstorm this year, so I expect to see a lot of teams that don’t normally use cameras bringing robots with poorly tuned cameras to the field.
How do you define this, and what affects it? I find the wording of the rule very dissatisfying. It says clearly you can’t use more than 4Mb/s, but adds the disclaimer to the effect that NOTHING is promised.
This is not just an abstract question. Last year 2077 used multiple cameras, carefully configured to run a total of 3.2Mb/s - under half the old limit. The system worked well in all our testing and practice, but was terrible in competition.
Assuming the FMS hasn’t been downgraded, the drop of the legal limit from 7 to 4 seems to acknowledge that 7 was never really supportable. Last year problems like this may have affected only teams pushing the limit (if half the limit counts as pushing!) but with this year’s rules almost mandating camera use any problems are likely to be very widespread. What CAN the FMS reasonably be expected to support?
Without guidance as to what’s actually available in practice, designing camera feeds isn’t engineering, it’s guesswork. “No more than 4, but we can’t tell you how much less, or any way to control it,” isn’t much to go on.
To me, poorly tuned means that the cameras are transmitting to the Driver’s Station using TCP rather than UDP and they are trying to use more than the allocated network capacity.
TCP is a guaranteed delivery protocol, it’s designed so that all packets eventually arrive and all packets arrive in order. If a packet is dropped, at the TCP level it will be retransmitted until it arrives at the destination, or the connection is dropped.
UDP is best effort, if a packet is dropped it simply never makes it to the destination.
As for field specific variances, that’s for the most part venue dependent. I’ve seen matches that have the robots consuming 30 Mb/S and no issues and I’ve seen matches/locations where you were lucky to get 10 Mb/S. That’s entirely dependent on the local environment and how crowded the 5 GHz spectrum is.
My recommendation is to go as low as is feasible for your use case. Whenever I saw a team pulling 7+ Mbps, I recommended that they lower their settings to avoid dropping packets. None of the teams I talked to noticed a meaningful difference for their use cases, and usually only minor adjustments brought them down to the 2-3 Mbps range.
The two variables teams typically tweak are the framerate and the resolution. For reference, TV shows in the US were historically shot at 30fps. Do you need higher than that for FRC? Probably not. In terms of resolution, consider what your drivers are looking at along with the size and resolution of your screen. 1080p is certainly not necessary, 480p is probably still better than you really need.
Unfortunately the nature of wireless communication and the variety in FRC event venues makes guaranteeing any specific number (without a disclaimer) difficult.
I can tell you that with the new radios it was rare that I saw bandwidth issues at regional events the last couple of years. The championship events can be tricky to deal with, but not impossible. The lower limit is to help guarantee that teams can get 4 Mbps without much trouble, and the caveat of not being able to guarantee it in all situations is there to protect the event. With some particularly hostile WiFi environment, it simply may not be possible to delay matches until all teams can get a guaranteed 4 Mbps. I don’t expect many events will run into that, but if you do your FTA should work with you and the other teams to come to a resolution.
These are certainly fine recommendations for teams at a competition who are experiencing problems, but that’s not where we are now. This is day 2 of the 2019 season. The “use case” of which you speak hasn’t been defined. Video feeds are a possibility, the maximal and effective use of which can be a competitive advantage. What’s adequate depends on what you’re trying to do with it, and what you try to do depends on what’s technically feasible. That’s the question I’m asking.
For CSAs, Shuffleboard will let you tune the stream from the dashboard. In a pinch, you can change compression level, resolution, and FPS without needing to reprogram the robot. Stream and camera settings should be tuned in the robot program afterward, though.
Smartdashboard does not do this, and I don’t know if the LabVIEW dashboard has similar functionality.
With all of that said, I think the wise option for strategizing regarding these things is to leave them a possibility, but not bank your entire strategy on them. Plan on devoting time to an autonomous routine and keep video control open as a backup. If you plan on using it to line up throughout the entire game, possibly look into a vision tracking system that doesn’t require a video stream, but leave the option of streaming a webcam open for the chance that it does end up being more effective during competition. I think the keywords here are that it “can be a competitive advantage”, but it’s not certain enough with bandwidth limits and issues to guarantee that it will be. Redundancy saves lives.