7mb/s, Will it be an Issue?

Does anybody believe the bandwidth limit will be much of an issue? What kind of visual feed resolution/refresh rate should we be able to get after factoring in the control signals.

I don’t know of any people having issues with it last season. There’s a recommended frame rate for camera transmission which is more than adequate.

However, at some events last year(mainly early weeks), there were instances where the required framerate/compression rate was smaller/different than the FIRST recommended.

To give you a reference, DTV with multiple MPEG streams, with up to 10 channel audio and data services is limited to 19.1Mb/s. We are broadcasting one 720P HD channel with 8 channels of audio and 2 SAP audio, plus three 640I channels with english and spanish channels plus some data services in our 19.1 stream. So 7 Mb/s should give you no problem. However, if you use a high resolution video with high refresh rate, MPEG4 cameras will eat up a lot of bandwidth. Keep to the recommendations and should have no bandwidth problems.

Also, please try to size your use for your actual need. No one needs to see the goals in 720p video with no compression. In the past the FTA’s have had to require teams to play with all video streams and cameras turned off because some teams were using far, far too much bandwidth (for no good reason). Use common sense and minimize your usage.

Have you read the FMS White Paper? It includes suggested camera settings. The Control System documentation has instruction for measuring your bandwidth usage.

7 mb/s is not an issue. It’s the latency that comes with running near above 4 mb/s, and the fact that you don’t always get 7 mb/s, and no matter what FIRST says, having an alliance partner using two cameras WILL lower your availible bandwidth

For those with past experience, what was the (even estimated) lowest bandwidth you observed? We talking 5 mb/s or < 1 mb/s, etc?

Similarly, what kind of latency should we plan for, worst-case?

At the Buckeye regional we had issues, but it was likely us streaming at a resolution that was to high or them having a lower framerate/compression rate. We ended up just removing the camera.

How does this compare to previous years? Has it always been 7Mbps, and this is just the first time it has been explicitly stated, or is this a change?

There is even more documentation:
(I suggest the second version where you use WireShark)

Think about the driver psychology before the programming, it might be a good idea to put some sort of display on the robot. Like what boom done did.

The same as last year. Last year was the first year of an explicit bandwidth limit.

Hey FIRST… Gigabit Technology… Just Sayin. :stuck_out_tongue:

I did a bandwidth test and found that streaming from two cameras with 38% compression, 640, 480, 600 KB/s were following through the network, which equals to 4.8 mbps. That means that the 7 mbps might a problem of you are using two cameras. We used an M1013 and M1011 for this test

The issue is 802.11 WiFi, gigabit would not change anything there. They are already running 802.11N and cannot use more than 1 channel due to the number of fields running at the Championship.

If you honestly need more than 7 mb/s you are doing something wrong.

I think it, s time for the umblicals again, this time for LAN :smiley:

I’m going to throw a blanket statement RED Flag on this one.

And, sorry yash101, you get one too.

My point is not that you are wrong, but you didn’t include any qualifiers. If you limit your comments to only one configuration, image processing on the DS, then your comments are fair. That said, you may want to consider alternatives.

My example is going to be my own team. Two cameras this year. One USB, processed on-board with a PCDuino. (BTW, the total cost for this set-up is almost half the cost of an Axis camera alone.) The other is a Axis 603, again processed on-board by the cRio, but for only one or two 320X240 frames at 30% compression, then turned off.

Essentially 0Mb/s bandwidth used with two cameras. There are ways to get around the 7Mb/s BW limits w/o disrupting the WiFi network.

Mr. Bill, I was pointing out a typical situation, where a robot will have one or two cameras, with the feed going directly to the DS, and no processing would be happening. Certainly, in your situation, the bandwidth would be low, but not every team processes images onboard. We won’t be because it is now to late to order an onboard PC like the PandaBoard. BTW, how long does the PandaBoard typically take to ship?

Understood. The only reason I worded my comments like I did was that the two references I was “calling a red flag” on, didn’t specify the configuration, it was only assumed.
Basing your comments on the configuration you just spelled out makes your comments 100% legit.
Please understand, no offence was intended.

Sorry, never used a PandaBoard, I can’t answer that one.
We are using a PCDuino sourced from SparkFun. Delivery is usually within 5 days.

Based on withholding amounts, I believe you should be able to order one now, develop your code off the robot, and bring it to the first practice day of your first comp. and install it there. That would buy you at least an extra week or so, at minimum. Please check me on the rules here, I don’t want to mislead anyone.


If you watched this was not entirely true. See channel bonding.
It was originally off last year and then turned back on later in the season.
The thought was it impacted the ‘christmas tree’ issue with the robots before the matches.

It was single channel in Mount Olive, NJ but later matches at other events were allowed to bond.