[OAK-D Lite] Stereo depth code cannot start the camera after the first run

[LivingWithHippos]

I have a strange problem, I'm using a python script to get the stereo depth, which is a slightly modified version of the one in the examples, and while it always works after boot, it fails to start on successive tests, with these errors:

[2026-07-15 13:10:14.856] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_2_0' (X_LINK_ERROR)'
[2026-07-15 13:10:14.856] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_7__output' (X_LINK_ERROR)'
[2026-07-15 13:10:14.856] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_3_depth' (X_LINK_ERROR)'
[2026-07-15 13:10:14.856] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_0_0' (X_LINK_ERROR)'
[194430107173DD5900] [5.1] [1784113816.224] [host] [warning] Closed connection

[194430107173DD5900] [5.1] [1784113816.224] [host] [warning] Attempting to reconnect. Timeout is 10000ms

[2026-07-15 13:10:19.523] [depthai] [error] Device with id 1944... has crashed. Crash dump logs are stored in: crash_dump_2026-07-15_13_10_19.tar.gz - please report to developers.
[194430107173DD5900] [5.1] [1784113821.532] [host] [warning] Reconnection successful
# keeps on crashing and restarting

crash_dump_2026-07-15_13_10_19.tar.gz

script:

import depthai as dai
import cv2
import numpy as np


def draw_rotated_rectangle(frame, center, size, angle, color, thickness=2):
    # Create a rotated rectangle
    rect = ((center[0], center[1]), (size[0], size[1]), angle)

    # Get the four vertices of the rotated rectangle
    box = cv2.boxPoints(rect)
    box = np.intp(box)  # Convert to integer coordinates

    # Draw the rectangle on the frame
    cv2.polylines(frame, [box], isClosed=True, color=color, thickness=thickness)


def processDepthFrame(depthFrame):
    depth_downscaled = depthFrame[::4]
    if np.all(depth_downscaled == 0):
        min_depth = 0
    else:
        min_depth = np.percentile(depth_downscaled[depth_downscaled != 0], 1)
    max_depth = np.percentile(depth_downscaled, 99)
    depthFrameColor = np.interp(depthFrame, (min_depth, max_depth), (0, 255)).astype(
        np.uint8
    )
    return cv2.applyColorMap(depthFrameColor, cv2.COLORMAP_HOT)


def getRectangleDistance(depthFrame, rectangle: dai.RotatedRect) -> float:
    center = (rectangle.center.x, rectangle.center.y)
    size = (rectangle.size.width, rectangle.size.height)
    x, y = int(center[0] - size[0] / 2), int(center[1] - size[1] / 2)
    values = depthFrame[y : y + int(size[1]), x : x + int(size[0])]
    # average them skipping zeroes (invalid)
    valid_values = values[values != 0]
    if valid_values.size == 0:
        return 0.0
    mm_distance = float(np.mean(valid_values))
    return mm_distance / 1000


with dai.Pipeline() as pipeline:
    color = pipeline.create(dai.node.Camera).build(dai.CameraBoardSocket.CAM_A)
    monoLeft = pipeline.create(dai.node.Camera).build(dai.CameraBoardSocket.CAM_B)
    monoRight = pipeline.create(dai.node.Camera).build(dai.CameraBoardSocket.CAM_C)
    stereo = pipeline.create(dai.node.StereoDepth)

    stereo.setDefaultProfilePreset(dai.node.StereoDepth.PresetMode.DEFAULT)

    colorCamOut = color.requestOutput((640, 480))

    monoLeftOut = monoLeft.requestOutput((640, 480))
    monoRightOut = monoRight.requestOutput((640, 480))

    monoLeftOut.link(stereo.left)
    monoRightOut.link(stereo.right)

    colorOut = colorCamOut.createOutputQueue()
    rightOut = monoRightOut.createOutputQueue()
    stereoOut = stereo.depth.createOutputQueue()

    counter = 0

    rectangle_center = (640 / 2, 480 / 2)
    rectangle_sizes = (50, 50)
    rectangle_angle = 0

    rect = dai.RotatedRect(
        dai.Point2f(rectangle_center[0], rectangle_center[1]),
        dai.Size2f(rectangle_sizes[0], rectangle_sizes[1]),
        rectangle_angle,
    )

    pipeline.start()
    while pipeline.isRunning():
        counter += 1
        colorFrame: dai.ImgFrame = colorOut.get()
        stereoFrame: dai.ImgFrame = stereoOut.get()

        assert colorFrame.validateTransformations()
        assert stereoFrame.validateTransformations()

        clr = colorFrame.getCvFrame()
        depth = processDepthFrame(stereoFrame.getCvFrame())

        remappedRect = colorFrame.getTransformation().remapRectTo(
            stereoFrame.getTransformation(), rect
        )

        depth_frame = stereoFrame.getFrame()
        rect_distance = getRectangleDistance(depth_frame, remappedRect)

        draw_rotated_rectangle(
            clr,
            (rect.center.x, rect.center.y),
            (rect.size.width, rect.size.height),
            rect.angle,
            (255, 0, 0),
        )
        draw_rotated_rectangle(
            depth,
            (remappedRect.center.x, remappedRect.center.y),
            (remappedRect.size.width, remappedRect.size.height),
            remappedRect.angle,
            (255, 0, 0),
        )

        cv2.putText(
            clr,
            f"{rect_distance:.3f} m",
            (10, 30),
            cv2.FONT_HERSHEY_SIMPLEX,
            1,
            (255, 255, 255),
            2,
        )
        cv2.imshow("color", clr)
        cv2.imshow("depth", depth)

        if cv2.waitKey(1) == ord("q"):
            break
    if pipeline.isRunning():
        pipeline.stop()

other info:

• I'm testing on a Linux laptop with arch on kernel 7.1.3
• depthai 3.8.0 (it crashed the same on 3.7.1)
• opencv-python 4.10.0.84
• depthai nodes 0.5.2 (not used in this script)
• python 3.13 in a virtual environment
• decent usb 3 cable

what doesn't work:

• changing USB port does not work
• changing USB cable does not work (tried a USB A 2.0)
• the original example behaviour is similar to this one
• the new example has the same behaviour, it fails at depthFrame = depthQueue.get()

I can also replicate this with the health check script

Device: DeviceInfo(name=5.1, deviceId=1944, X_LINK_UNBOOTED, X_LINK_USB_VSC, X_LINK_MYRIAD_X, X_LINK_SUCCESS)
Power supply check duration: 20000 ms
Running health check...

Health check completed in 30853 ms
HealthCheckMetrics(
  usbGeneration=USB 3.0,
  bandwidthMbps=2108.67,
  cameraFunctionality=pass,
  cameraCalibration=pass,
  imuFunctionality=pass,
  imuCalibration=pass,
  powerSupplyFunctionality=pass,
  deviceInUse=false,
  deviceInSetupMode=false,
  missingUdevRules=false,
  issues=[{type=warning, stage=powerSupply, message="No IR drivers detected; power supply check ran without IR load."}]
)

# becomes

Running health check...
[2026-07-15 14:08:34.030] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_2_0' (X_LINK_ERROR)'
[2026-07-15 14:08:34.030] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_3_out' (X_LINK_ERROR)'
[2026-07-15 14:08:34.030] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_7__output' (X_LINK_ERROR)'
[2026-07-15 14:08:34.030] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_0_0' (X_LINK_ERROR)'
[2026-07-15 14:08:34.030] [depthai] [error] Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: '__x_1_0' (X_LINK_ERROR)'
[194430107173DD5900] [5.1] [1784117316.147] [host] [warning] Closed connection

[194430107173DD5900] [5.1] [1784117316.147] [host] [warning] Attempting to reconnect. Timeout is 10000ms

what does work:

• rebooting does work (once)
• disconnecting the camera from the camera/cable and waiting a bit after reconnecting and retrying DOES work, but again, only for the first time
• if I run another script which has a "normal" object detection pipeline, with no stereo, it always works (same device, same pc, same venv)

dmesg of a broken loop

# camera connected
lug 15 13:21:55 kernel: usb 5-1: new high-speed USB device number 21 using xhci_hcd
lug 15 13:21:55 kernel: usb 5-1: New USB device found, idVendor=03e7, idProduct=2485, bcdDevice= 0.01
lug 15 13:21:55 kernel: usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
lug 15 13:21:55 kernel: usb 5-1: Product: Movidius MyriadX
lug 15 13:21:55 kernel: usb 5-1: Manufacturer: Movidius Ltd.
lug 15 13:21:55 kernel: usb 5-1: SerialNumber: 03e7
# script started
lug 15 13:22:08 kernel: usb 5-1: USB disconnect, device number 21
lug 15 13:22:10 kernel: usb 6-1: new SuperSpeed USB device number 19 using xhci_hcd
lug 15 13:22:10 kernel: usb 6-1: New USB device found, idVendor=03e7, idProduct=f63b, bcdDevice= 1.00
lug 15 13:22:10 kernel: usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
lug 15 13:22:10 kernel: usb 6-1: Product: Luxonis Device
lug 15 13:22:10 kernel: usb 6-1: Manufacturer: Intel Corporation
lug 15 13:22:10 kernel: usb 6-1: SerialNumber: 1944
lug 15 13:22:12 kernel: usb 6-1: USB disconnect, device number 19
lug 15 13:22:12 kernel: usb 5-1: new high-speed USB device number 22 using xhci_hcd
lug 15 13:22:13 kernel: usb 5-1: New USB device found, idVendor=03e7, idProduct=2485, bcdDevice= 0.01
lug 15 13:22:13 kernel: usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
lug 15 13:22:13 kernel: usb 5-1: Product: Movidius MyriadX
lug 15 13:22:13 kernel: usb 5-1: Manufacturer: Movidius Ltd.
lug 15 13:22:13 kernel: usb 5-1: SerialNumber: 03e7
lug 15 13:22:15 kernel: usb 5-1: USB disconnect, device number 22
# loops from "new SuperSpeed USB device..."

cat /etc/udev/rules.d/99-prolific.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="067b", ATTR{idProduct}=="2303", GROUP="libvirt", MODE="0660"

[brmarkus]

Do you hear "clicks" between the loops?
I had exactly the same on another Linux based laptop - but not on a Linux destop computer.
Therefore I'm using an actively powered USB3 hub and had no such problems since then.

When you connect the camera it first starts as a USB2 high speed device, not active, nothing streaming. Once the stack gets initialized, firmware loading and cameras activating the USB2-high-speed device disappears from the USB bus and a new USB3 super-speed device appears on the USB bus - trying to initialize and bring-up, but couldn't.

It looked to me that the camera did not get enough power via the laptop USB ports (maybe you have other USB-devices connected, already consuming some energy provided by your Laptop's USB power-manager, like bluetooth, wifi, touchpad; you might check your USB device topology from the root ports on to see what else is present and consuming energy).

Other cameas, like "OAK-D" do allow a power-supply, but not the "OAK-D Lite".

From "https://shop.luxonis.com/products/oak-d-lite-1" the total power consumption could be up to ~5W, maybe at startup resulting in a peak?

[LivingWithHippos]

Do you hear "clicks" between the loops?

Not sure what you mean, literally hearing sound? I can see the notifications about the device connecting and disconnecting when the script is launched

These ports have both PD 3 which has a 100 W cap, the cable is rated for 240 W, I also tried disconnecting everything and disabling bluetooth, these ports are root ones, but the error persists

I'll try with another pc asap

Is the load really lighter for a neural network than it is for depth calculation?

more tests

I've tried with another camera (same model)

• ran the health check 3 times -> all ok
• ran the official example 3 times -> broken on the third test

Interestingly here we were able to run 5 times before crashing

disconnected the camera and reconnected after 30 seconds

• ran the example -> again broken on the 3rd test

disconnected the camera and reconnected after 30 seconds

• health check
• waited 1 minute
• health check
• waited 1 minute
• health check -> broken
• disconnected and reconnected after 10 seconds
• health check -> broken
• disconnected and reconnected after 30 seconds
• health check
• disconnected and reconnected after 10 seconds
• health check -> broken
  -> so it also happens if I disconnect without crashing it before

If I disconnect and reconnect after 30 seconds before launching the health check it always works, but if I wait 30 seconds without disconnecting it breaks

I created another venv in another folder from scratch with only depthai, but the issue is the same

I monitored for any python process pending but I did not see any

also I noticed that if I let the health script retry it seems capable to successfully complete after some tries, while the depth one keeps on failing for 3 minutes but it does show an error

HealthCheckMetrics(
  usbGeneration=USB 3.0,
  bandwidthMbps=2145.15,
  cameraFunctionality=fail,
  cameraCalibration=pass,
  imuFunctionality=pass,
  imuCalibration=pass,
  powerSupplyFunctionality=fail,
  deviceInUse=false,
  deviceInSetupMode=false,
  missingUdevRules=false,
  issues=[{type=error, stage=cameraFunctionality, message="Camera socket 0 did not stream a frame."},
{type=error, stage=powerSupply, message="Camera socket 0 did not stream before power supply load."}]
)

I found this https://discuss.luxonis.com/d/6443-usb-30-connection-issue-with-oak-d-lite/18 but reversing the cable end changed nothing

[brmarkus]

Yes, literally clicking sound from an embedded relais inside the camera (maybe I mix this up with another OAK-D device).

Have you created/copied udev-rules during setup and installation? In the early Movidius days I experimented a lot with different udev-rules when I used RealSense- and Luxonis-cameras in e.g. Docker containers.
(also customized the USB device enumeration and camera device enumerations)

The driver seems to have a timeout implemented for the device's lifecycle, looks like, requiring the camera device to not be re-inserted too fast in a row...
(it was a bit more complicated as we used soldered-down Movidius devices and needed special timing for re-powering the whole chip to perform a reset in case the device was hanging/dead-locked sometimes)

[LivingWithHippos]

Have you created/copied udev-rules during setup and installation?

Yes I posted them above, but since the camera works I wouldn't expect those to be an issue

The driver seems to have a timeout implemented for the device's lifecycle, looks like, requiring the camera device to not be re-inserted too fast in a row...

That's kinda what I'm suspecting since the 30 second mark looks hardcoded, either that or something power related, but I can't understand why It fails when not disconnecting even if I wait a full minute between retries, it's like it gets "corrupted"

[brmarkus]

Hold on - have you copied the wrong udev-rule or just copy&pasted the wrong one?
From the current install-requirements-script (from "https://docs.luxonis.com/software/depthai/manual-install/#Manual%20DepthAI%20installation-Ubuntu%2FDebian" pointing to "https://raw.githubusercontent.com/luxonis/depthai-python/refs/heads/main/docs/install_dependencies.sh") it looks like this:

# Allow all users to read and write to Myriad X devices
echo "Installing udev rules..."
echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="03e7", MODE="0666"' | sudo tee /etc/udev/rules.d/80-movidius.rules > /dev/null
sudo udevadm control --reload-rules && sudo udevadm trigger

You wrote this in your initial post:

cat /etc/udev/rules.d/99-prolific.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="067b", ATTR{idProduct}=="2303", GROUP="libvirt", MODE="0660"

When you are within a virtual machine/KVM, it's complicated (as mentioned before due to dynamics), see "https://docs.luxonis.com/software/depthai/manual-install/#Manual%20DepthAI%20installation-Kernel%20Virtual%20Machine%20(KVM)"

[LivingWithHippos]

Uh sorry you're right (nice catch) I copy pasted the wrong rules, prolific is a serial adapter

cat /etc/udev/rules.d/80-movidius.rules 
SUBSYSTEM=="usb", ATTRS{idVendor}=="03e7", MODE="0666"

without this it won't even work so there's no risk of them being missing

[brmarkus]

Yeah, we had strange effects in production as well - that's why we experimented first with power-cycling specific ports (some USB-hubs allow to power-cycle single ports); later the Movidus chip got soldered down.
The chip came in multiple revisions; at the beginning resetting the chip didn't help, later we power-cycled the whole Movidius chip.
At some point we tested a kernel patch (not sure it was the UVC module?) as sometimes camera devices didn't get closed properly and the camera devices incremented "forever" (/dev/video0, /dev/video99 etc), haven't found if a user-space application is leaking a file descriptor.
The pipeline also didn't react "properly" to system-suspend/hibernate/resume, also therefore considering the power-cycle.

Let's see when someone from Luxonis dev team will respond.
@themarpe can you have a look, please?

[themarpe]

CC: @jakaskerl @oskarsonc

Which host is it? My first thought would be power, and that some kind of a half brownout occurs which puts the device into bad state for next runs. That is why a disconnect helps.

Perhaps try with https://shop.luxonis.com/products/oak-y-adapter or a powered USB hub in between your USB port.
Otherwise, we'd have to dive deeper

[TamseSaso]

Could you try disabling automatic reconnection by setting the following environment variable?

DEPTHAI_RECONNECT_TIMEOUT=0

By default, DepthAI uses a 10-second reconnect timeout and may retry several times, which can block subsequent device startup attempts.

[LivingWithHippos]

DEPTHAI_RECONNECT_TIMEOUT=0

It does seem to help a bit, I'm able to restart the script without having to disconnect, just need to wait a bit

We tested it on a CM3 raspberry with Debian 13, and after the first time it crashed the system stopped seeing the camera when connected. The camera still work, but I think it fried the custom USB 2 cable or something. EDIT: it's working again

I'll try to get an externally powered usb cable just to check if power is the issue, but I don't think we'll be able to add it to our system anyway, so back to object detection in the meanwhile

[durgeshloginai]

Adding sanitized evidence from a separate OAK-D Lite investigation because the repeat-start behavior appears closely related.

Environment and bounded profile

• OAK-D Lite (RVC2), DepthAI Python 3.8.0, Linux laptop
• Direct USB connection; every clean and failed invocation negotiated UsbSpeed.SUPER
• Automatic reconnect disabled with device.setMaxReconnectionAttempts(0)
• No frames were displayed or saved
• CAM_A: 1280×720 NV12 at 15 FPS
• CAM_B/C: 640×400 GRAY8 at 10 FPS
• StereoDepth DEFAULT, RAW16 depth, decimation 1, left-right check off, subpixel off, extended disparity off

A clean control delivered 153 consecutive RGB frames at 15.015 FPS and 101 consecutive depth frames at 10.051 FPS, with no sequence gaps, lates, disconnects, or reported errors.

Failure sequence

We observed three separate, explicitly initiated pipeline starts that crashed. Each failed invocation produced exactly one crash report; there were no SDK automatic retries or reconnect attempts.

1. After the clean 15 FPS control, only CAM_A FPS was changed to 30. The pipeline delivered zero RGB and zero depth frames, logged X_LINK_ERROR, closed the queues, explicitly reported a device crash, and the host process returned code 2.
2. A metadata-only device open then succeeded at SuperSpeed, but one subsequent start of the previously clean 1280×720/15 FPS profile crashed before its first frame with the same signature.
3. After a camera-only physical power cycle, that 15 FPS profile completed once (153 RGB frames at 15.011 FPS; 101 depth frames at 10.044 FPS). The next start of the exact same profile, with no reported physical change, again crashed before its first frame with the same signature. This was intended as a 10-minute stability run, but the timed collection never began because both streams never became ready.

All three crash reports showed approximately two seconds of device uptime and contained:

Start Source: Invalid config steps, 1
assertion "0" failed ... PlgSrcMipi::threadFunc
Fatal error RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE

Kernel logs showed USB disconnect/re-enumeration during crash handling. No kernel over-current, undervoltage, or insufficient-power diagnostic was recorded, although this does not eliminate a transient power issue.

After another physical reconnect, reducing only CAM_A resolution to 640×480 at 15 FPS while keeping the depth profile unchanged completed once (153 RGB frames at 14.983 FPS; 101 depth frames at 10.043 FPS; no gaps, lates, disconnects, or errors). This is only a lower-load workaround candidate: the reconnect and resolution change are confounded, so it does not establish resolution, USB bandwidth, or power as the cause.

The raw crash archives are not attached because they contain a unique device identifier. A sanitized subset can be provided if useful.

Does the matching PlgSrcMipi / RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE signature indicate the same underlying issue? If so, is there a fixed SDK/firmware build or an explicit OAK-D Lite sensor-output configuration you recommend testing?

[durgeshloginai]

Follow-up with sanitized standalone-depth evidence from the same investigation.

Standalone D2 control and failed restart

One standalone depth invocation completed for 10 minutes with 6,002
consecutive frames at 10.002 FPS and zero gaps, lates, disconnects, or errors.
The next standalone invocation used the identical device pipeline:

• CAM_B/C 640×400 GRAY8 at 10 FPS
• StereoDepth DEFAULT with 640×400 RAW16 depth
• Decimation factor 1
• Left-right check, subpixel, and extended disparity off
• Non-blocking output queue of four
• device.setMaxReconnectionAttempts(0); zero automatic reconnect attempts
• No CAM_A/RGB stream and no image or video display/saving

Only the host collection deadline changed from 600 to 1,800 seconds. A
metadata-only open immediately before the failed invocation found all three
cameras and negotiated UsbSpeed.SUPER.

The next standalone pipeline start delivered zero frames. DepthAI logged
read/write X_LINK_ERROR; the host received
QueueException: MessageQueue was closed; the wrapper classified
DEVICE_CRASH; the process returned 2; and kernel evidence recorded USB
disconnect/re-enumeration.

This one explicit invocation produced one crash report with the same
signature:

Start Source: Invalid config steps, 1
assertion "0" failed ... PlgSrcMipi::threadFunc
Fatal error RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE

The crash report recorded approximately 2.00 seconds of device uptime. This
was not an automatic retry, and the requested 30-minute collection never
began. It shows that the fatal startup signature is not limited to combined
RGB plus depth or extended disparity.

After a camera-only physical power cycle, one metadata-only inspection again
opened the expected three-camera device at SuperSpeed without a new crash
signature. No stream was started, so this confirms device-open recovery only,
not streaming recovery.

No kernel over-current, undervoltage, or insufficient-power diagnostic was
recorded, although that does not eliminate a transient power issue. The raw
crash archive remains local because it contains a unique device identifier
and is not attached here.

Does this standalone recurrence help narrow the failure to RVC2 camera-source
startup/restart state? Is there a maintainer-recommended instrumented build or
safe next diagnostic that does not rely on automatic retry?