BWixted

  • Dec 1, 2024
  • Joined Aug 8, 2024
  • 0 best answers
  • In X_LINK_UNBOOTED on CM4 - RuntimeError: No available devices

    I've already replicated this, and I think I've realized what's happened - I'd moved the dai.Device() call into a class that sets up the camera pipeline so that I could grab calibration data directly off the camera and set the camera focus. Immediately after initializing that class, its reference to device is used properly (with camera.device as device: ). Closing the code in the (tiny) window between the initialization and the with: appears to be the cause. Closing it after the with: doesn't cause any problems. Closing it prior to the dai.Device() call also doesn't cause any problems. These calls are almost immediately adjacent. Power cycling fixes it, but I don't expect there's any way to do that without physical access.

    • In X_LINK_UNBOOTED on CM4 - RuntimeError: No available devices

      Hi,

      I've got a remote CM4 that is stuck with the above error.

      Attempting to call any method that would try and load a device returns:

      [warning] skipping X_LINK_UNBOOTED device with name "1.1"
      [warning] skipping X_LINK_UNBOOTED device having name "1.1"

      udev rules are correct. device_manager.py suffers the same issue. lsusb contains the "Intel Movidius MyriadX" device

      dai.Device.getFirstAvailableDevice(skipInvalidDevices=False)
      returns:
      True, DeviceInfo(name=1.1, mxid=, X_LINK_UNBOOTED, X_LINK_USB_VSC, X_LINK_MYRIAD_X, X_LINK_ERROR)

      Rebooting the pi does not solve the issue.

      This device has been successfully working continuously for months. This issue has appeared after remotely accessing the pi to run some image/data collection code (which was unchanged from previous runs). The only thing I can think of that could have caused the issue was closing an IDE terminal window while either the device or pipeline was initializing.

      All of the code has been run on an identical device (as identical as possible - same batch, same os version, same libraries, etc.) with no issue.

    • In OAK-D-CM4 PoE Wifi and external SD functionality

      For those who are interested, there is a solution for having both Wifi and external microSD storage on the OAK-D-CM4 PoE board.

      This forum post on the raspberry pi forums contains some details on how to create a new pin overlay, compile it, and add it to the boot config. This has worked for me - both the Wifi and external SD card are functional - though I don't see it being widely useful, since you need a PoE connection to power the device anyway.

      In my use-case, connecting to the camera while on-site is difficult, as the wired network is managed by another party. I have access from the internet to a virtual machine on the wired network from which I can access the camera, but the site has very bad mobile reception, so this solution is patchy if it works at all. Setting up the pi as a wifi access point allows me to directly connect when physically next to the camera.

      • In OAK-D-CM4 incorrect spec translations for depth calibration

        19443010B11F772700
        19443010C145772700
        Both show the same incorrect specTranslation (x = 7.0) for the 1.3cm offset mono camera.

      • In OAK-D-CM4 incorrect spec translations for depth calibration

        This is an issue that I've since resolved, but haven't seen particularly clear explanations of outside of a tangential github report.

        At least two of the OAK-D-CM4 PoE models that I've purchased have had a wildly incorrect spec loaded for their stereo (mono) camera positions. The factory calibration of these cameras has been correct, but by default the stereo depth node will load the spec numbers, not the factory calibration numbers. Most of the others have not had this issue.
        "specTranslation": {
        "x": 7.0,
        "y": 0.0,
        "z": 0.0},
        "toCameraSocket": 0,
        "translation": {
        "x": 1.2537951469421387,
        "y": -0.016799528151750565,
        "z": -0.25653964281082153
        }

        The main symptom of this issue is being unable to align the depth map with the color images, even when using unaltered example code.

        Downloading and reading the calibration file from the camera will confirm if this is the exact issue (or if you need to do your own calibration, I guess)

        Adding
        stereoDepth.setDisparityToDepthUseSpecTranslation(False)
        stereoDepth.setDepthAlignmentUseSpecTranslation(False)
        to my pipeline setup resolved this issue for me without needing to recalibrate the camera.