Multiple cameras on one Robot

We are looking at putting many cameras on our robot, and I have a few questions, because I don’t want us to be that team that shows up at competition and sucks down all of the bandwith. :slight_smile:

  1. I am making the assumption that we should limit camera usage to 6 mbps, leaving 1 of our 7 for direct Roborio communication, is that correct?
  2. We want the option of using 3 cameras at once, and based on this whitepaper on page 7, running our cameras (Axis M1011s) at 10 fps and 30 compression on 320x240 will be well under the 6mbps limit. We have tested this in our shop and it works to our satisfaction. Are these numbers correct and can we use a 3 camera setup this way?
  3. Does the router imaging tool limit you to 7 mbps so we can double check that we are not hitting the bandwith limit in our shop? Or must we manually do this limit in the router? (I think I saw this when looking through router settings before, but I can’t check right now, because this snowstorm has our school closed.)
  4. If we write dashboard code that swaps between camera feeds (changes which camera it is displaying) by putting a case structure over the dashboard image ip-address box (we are a LabVIEW team) and changing the ip-address it is connecting to, will that make the system act as if it is connecting to one camera for bandwith purposes?

Thanks for any knowledge

  1. I am making the assumption that we should limit camera usage to 6 mbps, leaving 1 of our 7 for direct Roborio communication, is that correct?

From what I know, your number are about right. But from experience, I would recommend reducing camera usage as to the minimum necessary. Based on Page 9 Figure 3 of the white paper, I would recommend keeping it below 6mpbs total (including control packets).

There are a number of tricks you can do to reduce bandwidth usage, the most significant is reducing framerate.

  1. We want the option of using 3 cameras at once, and based on this whitepaper on page 7, running our cameras (Axis M1011s) at 10 fps and 30 compression on 320x240 will be well under the 6mbps limit. We have tested this in our shop and it works to our satisfaction. Are these numbers correct and can we use a 3 camera setup this way?

Those numbers seem to match past experience. Bandwidth usage will vary based on the image and lighting conditions. There is an option accessible through the axis camera web interface which allows you to hard code in a maximum image size. You may want to use this feature (among others). Not all axis settings are currently available through code.

  1. Does the router imaging tool limit you to 7 mbps so we can double check that we are not hitting the bandwith limit in our shop? Or must we manually do this limit in the router? (I think I saw this when looking through router settings before, but I can’t check right now, because this snowstorm has our school closed.)

The router does not limit it. The limitation is performed by the field network hardware. Also, (as of last known event) the field hardware does not differentiate between camera packets and control packets.

  1. If we write dashboard code that swaps between camera feeds (changes which camera it is displaying) by putting a case structure over the dashboard image ip-address box (we are a LabVIEW team) and changing the ip-address it is connecting to, will that make the system act as if it is connecting to one camera for bandwith purposes?

Yes, but you will disconnect the cameras (network time out). Each time you switch, you will have to reestablish communications (takes a few seconds). If you only need to view one camera at a time, I would recommend writing a program to do the following:

  1. Connect to all 3 cameras and stream to RIO
  2. Allow selection of each camera individually
  3. Forward the selected camera image to the dashboard.
    You’ll effectively be using the RIO as a video router.

I’ll see if I can write this in the next few days. We’re planning to use two USB cameras and the coding shouldn’t be that different.

Just out of curiosity, what would you use 3 cameras for? Last year 1706 ran 3 wide angle cameras to obtain 360 degree vision of the environment to track every pair of vision targets in the corners and determine where we were on the field through 3 separate pose calculations. We also did ball and robot tracking, but didn’t use it.

I don’t suppose you could post a link to those cameras?

I would recommend using a utility like Wireshark or the built-in Windows 7 Resource Monitor on your Driver Station computer to test any configuration of network equipment on your robot that you might anticipate will be used on the field, and measure the actual bandwidth being received by the DS.

The good news is that this measurement will include all of the traffic (including DS<->RoboRio traffic) to give you a really good estimate. Note that the data stream between the DS and RoboRio that is always active (the protocol itself) has changed, and that total bandwidth consumption is down from about 900 kbps to about 1/10th of that (you can do the measurement yourself with a cRio vs. a RoboRio and the corresponding versions of the DS software.) This effectively gives teams an additional 800 kbps of bandwidth to use for custom applications.

Ok, I took a shot at turning the RoboRIO into a video router. The code is in the standard Vision Processing vi location.

A few things of note

  1. I’m pretty sure I used my team number when I created the project (You’ll have to correct)
  2. This is NOT tested yet, so I expect some errors.
  3. Create a dashboard string control called “Camera” and write “Camera A”, “Camera B”, or “Camera C” to it. This should let you choose which camera to use.
  4. I had to modify two WPI files for this. I have renamed them and placed them in the project. The use of these renamed files should not cause any issue.
  5. This only works with Axis cameras right now.
    Everything else should be as per usual configuration.

How it works:
All cameras are opened per normal. The big change is “Camera IP & Dash” was modified and renamed (renamed to prevent interference) to only read the camera and not send the code to the dashboard (send 2 pc). The Send 2 PC code was reduced to what is shown in the loop. It selects the JPG image desired and forwards it to the dashboard.

Theoretically this should keep all cameras open simultaneously and forward the different camera image at the next frame without having to restart the network connection. Additionally, since this is all performed on the robot you are only sending one cameras worth of data across the network to the dashboard.

If this doesn’t work, let me know. I’ll have access to Axis cameras over the next few days. I’m planning on adapting this for the USB cameras from Microsoft which can also provide a JPG without needing the RoboRIO to provide compression. Theoretically I should be able to have this setup to work on a mixed Axis & USB environment.

2015 Camera Router Project.zip (170 KB)


2015 Camera Router Project.zip (170 KB)

The 2013 radio tool enabled QOS on the dlink and set a bandwidth limit of 7mbps. I have not verified whether the 2015 radio tool does the same. However, due to implementation differences, it’s unlikely to work exactly the same as the field limit.

As the packet sizes are now dynamic, I’m not sure you can count on the bandwidth always being around 100 kbps, so be sure to leave margin.

Please explain why USB cameras will not work. Our team has two USB cameras we are trying to integrate, and we would like a little bit more information to go on.

I only set that code up for Axis cameras. Yesterday I posted some code (link below) which will work for two USB cameras.

edit sorry, I realized a better explanation was in order.

The Axis Cameras and USB Camera images are buffered by the Rio. How this buffering is accomplished is very different between the two. The Axis cameras stream JPG images to the RIO over the network. In order to minimum latency and memory requirements, the standard code continuously reads the images from the networkand buffers them. This buffer is passed by reference to the “send 2 PC” vi which transfers the image to the dashboard. The USB camera buffering is automatically handled in the background by either the driver of labview itself. In order to read the image, you just need to call the IMAQ vi which reads the image buffer. The samples provided are each specifically tailored to the camera types. The example provided in this thread is specifically tailored to switching between the Axis camera buffer references and sending this to the Send2PC vi. The USB one provided will close & reopen the camera (not a big issue due to small time delay).

It should be possible to combine the two into one function and automatically switch between them. I just haven’t had the time to do so yet. In the mean time, I can only attempt type specific code. I do plan to improve these samples as I have time, but we have a week 1 event and we’re going to be pressed as is.

Thank you, that helped a lot with our issue

We have multiple USB cameras working on the bot in C++. So far, we’ve only tested two cameras because that’s what we need for our bot. But, it looks like it should be scalable to more cameras as long as you’ve got the USB ports available. I’m cleaning up the code as we speak and I’ll post it for those who are interested. This same approach should work with only slight modifications in Java. As for LabView, I don’t do squiggly pictures. So, you’re on your own.

Mike

so, how much does two cameras effect your bandwidth?:confused: :confused: :confused: :confused: :confused:

Since we’re not sending both feeds simultaneously, no more than a single camera would (~2.3 Mbps at 320x240 ~ 12 FPS).

HTH,

Mike

Mike,
I am very interested in your C++ code to manage two usb cameras.

Hi Gang,

The code is posted in thread:
http://www.chiefdelphi.com/forums/showthread.php?t=133939

HTH,

Mike

Thanks. I have the java code and will be testing it shortly.

1 Like

The Axis camera router for LabVIEW does not seem to be working. I am still only getting feed from a single camera.

Mike,
Thanks for that code. Works perfectly.