Quote:
Originally Posted by Greg McKaskle
...
To summarize what this says ... The robots in these matches were typically using 10% of the wifi spectrum. The spikes due to a radio momentarily shifting to slower speeds caused a momentary spike to 25%. If this had hit the ceiling and caused other radios to slow, it would have been a Xmas tree event. I logged the entire weekend and never saw a tree.
|
Were the robots involved during this sample sending video and if so how?
As CSA we are not usually asked to find this out.
Perhaps the Robot Inspectors know?
Quote:
|
I have never been at an event where wifi was stressed to its limits. I have heard stories, and I believe it has happened. I do not believe it is common, and FIRST is diligent at using the wifi that is available to run the best matches possible.
|
On this I give FIRST credit. They have acknowledged there can be an issue and they do make an effort to limit the potential. It is hard however, as noted, to get everything in the field area to comply with these desires.
Quote:
|
By the way, I have also seen matches where individual robots are sending 20Mbps HD video. The sky didn't fall. The team was asked to change camera settings. No big deal. The wouldn't be nearly as simple without usage guidelines.
|
I agree the presence of the load balancing does restrict the consequences of a robot operating outside of the reasonable expectations FIRST offered.
Quote:
|
I'm not claiming that things can't be made better, but before we try to fix the problem, we need to measure quantitatively what is actually going on.
|
I have long given up on attempting to catch something like this myself because simply put everyone that tries is doing so at a disadvantage. The field venues change. The field settings could change. The robots can change.
For the purpose of sending the tiny amount of data FMS really needs the WiFi is just fine. Unfortunately with so many people sending video to driver's stations FMS is just plain drown out. Hence the increasing issues noticed the more people have sent video to the driver's station since FIRST started using WiFi. The result at the moment is usually an impact on just the team that needs to adjust their vision system and for that I am grateful because I do not believe it was previously the case before the load balance (call it a gut feeling - I can't go back in time - and now it does not change anything).
In the end WiFi is way more bandwidth than is really needed for FMS. So even compromised quality WiFi would work out if it wasn't for the video demands being put in competition. Even more so if the programmers of the robots make their code keep the robot moving in the last instructed direction/speed/operation until new instructions arrive. Then unless enough FMS packets are missed to disable the robot the robots can still maintain control performance even if FMS is missing some packets here and there. I think that example of dropping 5,000 of 7,000 FMS packets for a team with such software is adequate (this is an example from RampRiot 2014 I presented in another topic).