Multiple Cameras and How they work

Hello, our coding team and design team is trying to figure out how to run multiple cameras on our robot this year WITHOUT lag. We have tried this in the past and failed very quickly. Are there any suggestions or resources that someone might suggest. We have used and may use a Limelight this year but need a secondary camera. Thanks in advance!

Others will be better equipped to help with multiple cameras, but if you’re not liking how a single camera setup is operating (specifically, too laggy), then multiple cameras are just going to make that problem way worse. In previous years, what model was the camera and what were the settings you had the camera at (fps, resolution), and were you doing any vision processing with it, or was it a standard camera feed for the drivers?

1 Like

Never had issues with lag with a single camera and not doing any vision processing.

The issue with LAG is resolution and frame rate. FMS only provides 4Mbits of bandwidth to a driver station. If your resolution is too high or frame rate is too high, you will quickly overload your available bandwidth.

You either choose great picture with LOW frame rate, or HIGH frame rate with low resolution.

PS, you can use Limelight for simple 2 camera setup (using USB connector for the second camera). Limelight auto sets resolution and framerate to work with FMS effectively.

Corrected 2 to 4, THANKS @MikLast

1 Like

Per R704, it actually provides 4 mbit/s to the driver station, but its good to keep in mind that everything (controls and vision) all need that bandwidth.


R704 makes it very clear that there is a hard cap of 500 kiobytes/sec bandwidth per robot. Most cameras, natively, will do a lot more than that. And, part of that bandwidth is used up with normal communications. Two video streams does not easily fit into that bandwidth, even if you do the normal tricks of reducing frame rate, resolution and color depth.

One approach is to only have one camera broadcasting at a time.

@CEF I think you may have some incorrect information. Per the FMS documentation, you get 4Mbit/sec

Critial change of units, with conversion not quite done properly.

But, generally, yes - there is a cap, and it’s too low to not think about. Streaming more than one camera at a reasonable resolution is probably fraught.

The RIO/cscore does support switched streaming.

1 Like

I think the conversion was correct, according to the Wikipedia article. 4 Mb/s, according to that article, is 4,000,000 bits/sec. And, according to that article, 500 kilobytes/sec is 500,000 bytes/sec * 8 bits/byte = 4,000,000 bits/sec = 4 Mb/s.

Don’t get me started on the “Mebi” and “Kibi” prefixes. Do engineers actually use that today? I remember scoffing at them when they were first proposed.

Yes, shockingly, there are situations where a 2.4% difference is significant.


Little snarky there. Not suggesting that the difference isn’t significant. But, there are other ways of specifying without using those prefixes and, in many places, convention tells you which one you mean. For example, 1 GB of RAM is 2^30 bytes, and nobody asks “Do you mean gibibytes or gigabytes,” because memory is always in powers of two – only a real pedant says “I just bought a 4.2495 GB memory chip.” (And, anyway, it’s weird to use a 10s based prefix with a word that’s base 2 – a kilobyte, using the SI units, is 8,000 bits, after all. If they want base 10, then they should define a byte to be 10 bits.)

Re-reading, I can concur. Most of my time spent doing these conversions is in relationship to disk space, hence my own confusion.

However, I wash my hands of the matter.