[gixxy]

Originally Posted by GeeTwo

If it weren't going to be an issue for somebody, FRC wouldn't have made a rule. If you run your network lean, or even fairly wide but smart, you shouldn't have any problem working with it. Rebound Rumble was our rookie year, and we couldn't effectively use the camera, and that was before explicit limits. (I was just a parent, not a mentor that year, so I don't know the details.)
For Ultimate Ascent, Matt programmed a raspberry pi to analyze the image and just return the MBR (minimum bounding rectangle) of the reflector areas it saw. I doubt we would have had a problem at 100 kbps, and everything else worked better as well. Oh, yeah, Gixxy had to put the comms with the raspberry pi on a separate thread so it wouldn't lock up the main thread when the pi went down due to brownouts.
I understand this year that we're planning a camera feed for the driver. I understand that it will not only be compressed, but run at a lower network priority so that it doesn't kill the essential functions.
The bottom line is, figure out whether it will be an issue for YOU and work around it if needed.

The problem in Rebound Rumble for 3946 was not network bandwidth, but the processing power of the cRio. It would take long enough to process an image that we would get noticeable lag in the controls response, due to bad prioritizing in the robot code.