7mb/s, Will it be an Issue?

[Tom Line]

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.

[Joe Ross]

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

[magnets]

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

[vScourge]

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?

[matthewdenny]

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?

[Joe Ross]

Originally Posted by matthewdenny

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?

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

[thmeans06]

Hey FIRST... Gigabit Technology... Just Sayin.

[yash101]

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

[billbo911]

Originally Posted by magnets

...... having an alliance partner using two cameras WILL lower your availible bandwidth

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

Originally Posted by yash101

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

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.

[yash101]

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?

[billbo911]

Originally Posted by yash101

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.....

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.

Originally Posted by yash101

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?

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.

[apalrd]

Originally Posted by thmeans06

Hey FIRST... Gigabit Technology... Just Sayin.

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.

[yash101]

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

[BBray_T1296]

Originally Posted by yash101

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

Or the overhead mesh used to power bumper cars! (transmitting data would be tricky though)

We have used our camera at 360p 30% compression and 10 fps, and had not even close to an issue, as well as nice response time (low "lag") The camera acted to help our drivers line up with the goal glowing by our bright orange LEDs, and to do on-board processing

For most vision processing, there is really not much of a need for high resolution, as that may increase the computation time per frame, reducing resources all around.

This year we are outsourcing our vision to Raspberry Pi's with camera data captured and processed by them, and due to the nature of this game, a lot of things can likely be done by eye better.

[JesseK]

On the field in 2013 I witnessed the FMS peak at ~2Mb/s by itself for some reason, even though the FMS whitepaper calls out ~1Mb/s. This is included in the 7Mb/s allocation. That meant we basically had 5Mb/s for everything else and even approaching 3Mb/s for our own data would cause latency issues for all robots on the field.

We only focused on FMS bandwidth last year because we really wanted 640x480@10Hz/30% and wanted a baseline bandwidth to figure out the boundary conditions. I was trying to stitch telemetry data with image data. Wasn't worth it, to be honest - we wound up having to go down to 6Hz before the FTA's stopped complaining about latency. This year we're going to try 320x240@20Hz with 30% compression. Hopefully our whiz kid network programming student is making the net code efficient enough for the telemetry data to keep up.