Camera Lag


#21

Thanks, we did finally get the images to show. I think our issue was that we hadn’t named the 2nd camera, or that we hadn’t changed the team number.

We are having other issues though.

  1. We can’t connect to the frcvision.local wirelessly when we connect to our testbed via the radio. Is that normal?

  2. We have java code to allow for cameras to switch on a button push, which worked when the cameras are connected to the Rio, but doesn’t seem to work since we added the Pi. Any idea what to do to fix that? This is essentially the code we used: 2 Cameras in Java

  3. Also, do you know what settings for the LifeCam works well?

Edited:
If we can’t get the camera switching to work, is it a big deal to stream them both simultaneously since we are using a pi now?


#22
  1. You should be able to. That is the desired way to connect and verify connectivity/performance. Verify if the laptop can ping frcvision.local or the IP address of the FRC rPi. FRC rPi should be connected to farthest ethernet port from the power jack and RoboRio should be connected on the closest ethernet port to the power jack (on the radio). RoboRio will get an IP address from your radio - 10.69.28.2 and FRC rPi will get any IP address between 10.69.28.3 up to 10.69.28.126.
  2. Sorry I can’t help, not a programmer. @Peter_Johnson can probably help, he’s the expert in this thread and he developed the FRC rPi Vision on RaspberryPi.
  3. in Vision Settings (on FRC rPi) we are using 160x120 with 25fps.
    Streaming two cameras simultaneously will consume bandwidth. This year we have 4Mbps. Each camera (setup with 160x120x25fps) will consume about 0.9 to 1.1 Mbps - in upper left corner of the streamed image you will see FPS and Mbps values. Two of them will consume 2 x 1.1 = 2.2 Mbps leaving 1.8Mbps for the robot. It should be enough, however, test your system thoroughly before you go to competitions. 1.8Mbps for robot communications is very tight, in my opinion.

#23

I just realised you’re the “FRC rPi Vision” expert! Congratulations, it’s a great software and it works great for our team. Thank you for creating the RaspberryPi images.


#24

Sometimes mDNS is unreliable. I recommend setting static IP addresses for everything on the robot when using coprocessors. The settings are accessible via each device’s webpage (RoboRio and FRCVision). Set the RoboRIO to static 10.TE.AM.2 and the rPi to static 10.TE.AM.11, netmask 255.0.0.0 and gateway 10.TE.AM.1 for both. You can leave the DS as DHCP or set it to static 10.TE.AM.5.

The FRCVision image can’t access joystick data (as that only goes to the Rio), but it has built-in support for switched cameras controlled via NetworkTables. You can add a switched camera on the Camera Settings tab of the webdash and then use robot code to set the NT value, and the Pi monitors the NT value and does the switch. See my post here for some example code: WPILib FRCVision Raspberry Pi image 2019.3.1 Update


#25

Thanks for your help. We got the Pi to connect wirelessly. I looked at your example for the Network Tables, but I have a couple of questions. We have never done network tables before so I apologize if these are ridiculous questions.

In your example, I see that you used “PiSwitch” as the NT key, but what did you do for the name? Also, if we have 2 cameras, would we have 2 different NT keys, or would we use the same one?

Also, you previously helped us with the code to get switched cameras working on the Rio. Would we need to remove the: server = CameraServer.getInstance().addSwitchedCamera(“switched camera”); code?


#26

On the Pi vision settings tab, you should have two USB cameras and one switched camera. You can name each of them whatever you like. The name is what appears in the dashboard list of cameras. On the switched camera settings you need to set a NT key—in my example this was set to “/PiSwitch”.

On the robot side, you don’t need to use CameraServer at all, just NT. The NT /PiSwitch value can be set to either a string (the camera name of one of the usb cameras) or a numeric index (0 for the first camera, 1 for the second).


#27

Thanks! That all worked.


#28

One last question, how does the Pi determine which camera is 0 and which is 1? Is it determined by the USB port they are plugged into?


#29

No, it’s the order they’re listed in the Vision Settings tab. To avoid having cameras potentially swap places, make sure you’re using one of the “alternate” path options (/dev/by-id or /dev/by-path) for both cameras instead of /dev/video0 and /dev/video1. The mapping of /dev/video0 and /dev/video1 to the physical ports/cameras isn’t guaranteed to be stable. This can be easily changed with the button to the right of the path in the vision settings.