Zed2i Unreliable connection

Software Python
1

my relevant previous post: Zed2i Auto Bus Type Detection Errors - #2 by alassagne
other posts I already read: [ZED][Grab] Detected Connection Failure - #4 by Myzhar , Multiple Cameras in Python , [ INFO] [1670333049.529311801]: ZED connection -> CAMERA FAILED TO SETUP

Setup:

  • python 3.9
  • 2 zed2i cameras with official 5m extender and 3m right angle cables. Validated that all cables and extenders are properly connected physically. Issue has occurred across multiple combinations of cameras
  • Cameras are run in sequence. Not using threading
  • SDK 4.0 - 4.0.4

I’m running into more connectivity issues with our camera setup both in app and in ZED_Explorer. About 5-10% of the time one of the cameras will not start. If I list the connected cameras

cameras = sl.Camera.get_device_list()

I can see both serial numbers. However upon calling

        self.camera = sl.Camera()
        err = self.camera.open(self.init_depth_params)

I get

Error: CAMERA MOTION SENSORS NOT DETECTED

This is reflected in ZED_Diagnostics

        "sensors": {
        }

Any recommendations on improving stability?

Should I add an attempted reboot Camera Class Reference | API Reference | Stereolabs ? If so is there a recommended number of max retries?

1 Like
2

As before with my other post, the issue only ever arises when opening a camera. Once it’s open the connection is stable

3

try using this in your code for each camera

 init_params.set_from_serial_number()  # Replace with the actual serial number of camera 1

and then go on with your code as you wouldve

1 Like
4

@SaifK2049 indeed found out that the initialization form the serial number is more stable. I’m highly interested in knowing if that works for you.

CAMERA MOTION SENSORS NOT DETECTED

is typically a USB issue. It means the the USB2 connection is down, even so the USB3 works (the ZED need both). It’s a problem that we usually have with people damaging there USB cable. Since you have a ZED2i, can you try to change the cable?

5

Thanks for the suggestion; however, we already do open cameras from serial number. Generally some combination of reseating the USB cable and or rebooting the computer fixes the issue. This is a disruptive process which is why I am hoping for some software fixes.

6

I’ve incorporated a ZED 2i on my robot. The camera hasn’t locked up on me yet using the robot, but I can lock it up developing and quitting processes without closing everything properly. Because of that, and in the event it does lock up while autonomous, I installed a powered USB hub and can have an attached Arduino switch a relay to turn the USB hub off and on. That fixes any lockups without having to reboot the computer or pull the cable. I highly recommend it for peace of mind.

7

That’s indeed a workaround.
You can also try software workarounds like this one : How do you reset a USB device from the command line? - Ask Ubuntu

8

Do you expect the linked Ask Ubuntu thread to be a more robust solution than the SDK reboot? Can you provide more details on what the SDK reboot does?

9

Hi,

The C solution from the linked thread is more brutal, and needs admin right. It’s mostly why it may be more reliable. The SDK reboot is more fine-grained and does not need admin rights.

1 Like
10

I’m still confused about why Error: CAMERA MOTION SENSORS NOT DETECTED is the error I got. In the init I don’t explicitly set sensors_required = True . According to the API reference the default for this value is False InitParameters Class Reference | API Reference | Stereolabs

If set to false, the SDK will try to open and use the IMU (second USB device on USB2.0) and will open the camera successfully even if the sensors failed to open

In our code we only raise the exception if err != sl.ERROR_CODE.SUCCESS . Shouldn’t the camera’s still be able to open even without the sensors being detected?

Also related: could bad udev rules lead to flaky connection? We mostly followed the example set here ZED Camera - NVIDIA Docs . Other posts here have indicated copying the udev rules from the installer with Setup the udev rules for the ZED cameras · GitHub could also be good

11

I should also mention that we set depth stability = 0 so it shouldn’t enabling the tracking module as a result of that

12

In my experience this is fairly typical behaviour for the zeds. The solution we use is to put the camera initialisation into a loop so that our app will retry until the zeds stop giving bogus error codes. 5 times seems to be a good number for determining if it’s just random errors from the zed. After five successive fails we do a hard reset on the USB connection with either the code linked above, or a physical unplug-replug.

13

Good to know. Do you put any sleeps or resets between the attempts? And if the first loop of 5 fails does it ever succeed on the attempt after the USB reset?

14

Also listing connecting cameras is not entirely stable. After plugging in a camera it is sometimes not detected for a while. Another issue is sometimes if two cameras are plugged in they get listed with the same serial number.

> python list_zeds.py
"serial_number": "320*****"
"serial_number": "320*****"
> python list_zeds.py
"serial_number": "323*****"
"serial_number": "320*****"

is the output of

import pyzed.sl as sl

cameras = sl.Camera.get_device_list()
for camera in cameras:
    sn = camera.serial_number
    print(f'"serial_number": "{sn}"')
15

Resetting the USB is not a guarantee that it will work first time, it’s just a check that there isn’t a hung USB device at the root of the issue. We do not reset the devices between attempts, it’s just a simple loop that keeps attempting to initialise until the random bugs stop.

As for the multiple cameras, can you share the code for list_zeds.py? I frequently use four cameras on some of my setups and have never encountered a case where they misreported a serial number. I suspect there is an issue in the way you are fetching them.

16

The code snippet above is the list_zeds file

17

I’ve just left that script on a loop for ten minutes with five cameras connected and cannot replicate the bug here. Can you dump the output of udevadm info /dev/video* ?

1 Like