Communication exception

pikelcw

Hi,

I recently received my Depthai with Rpi CM4.
While I was running examples from the depthai-python repository, I would get Communication exception from time to time.
For example, I get

inDepth = q.get() # blocking call, will wait until a new data has arrived
RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: 'disparity' (X_LINK_ERROR)

while running 03_depth_preview.py, and get

track = tracklets.get()
RuntimeError: Communication exception - possible device error/misconfiguration. Original message '[json.exception.parse_error.110] parse error at byte 1: syntax error while parsing MessagePack value: unexpected end of input'

while running 29_2_spatial_object_tracker.py.

Is there anything I can do to check what is wrong?

Thanks

Brandon

Hi @pikelcw ,

Sorry about the trouble here. We recently discovered a stability issue on the Pi series with our Gen2 API (which is our mainline API) that we've been feverishly trying to solve.

https://github.com/luxonis/depthai/issues/354

So I think this is what you are running into. @GergelySzabolcs I think got to the bottom of it yesterday, and is working to implement a fix.

In the time being, depending on what you are planning to accomplish, you could use our Gen1 API. We have tested that (to make sure it doesn't suffer from the same issue) and it will run for 2 days straight without an issue.

If that's of interest, see below for instructions:

To run gen1, clone this repo:
https://github.com/luxonis/depthai

And then checkout gen1_main.

And then you can run
python3 install_requirements.py

And then to run the equivalent of 29_2_spatial_object_tracker.py, you can run:

python3 depthai_demo.py -s metaout previewout depth object_tracker -bb -ff

Now that we think we know what the root cause is, we are working to fix it in Gen2, but we don't yet have a timeline on that. This bug went back to the very beginnings of Gen2, but didn't actually become evident until recently.

Thoughts?

Thanks and sorry again about the trouble here.
-Brandon

pikelcw

Hi Brandon ,

Thank you for the response. For now, Gen 1 should be enough for my purpose!
I have another unrelated question. My depthai's rpi won't boot if I just plug in the 5V.
I need to either plug in an HDMI, or plug in the micro USB on the side then unplug it to boot.
Is that how it is designed to work? Or is that some software setup?

Thanks

Brandon

Hi pikelcw ,

Thanks.

Yes, so that's actually a setting in the Raspberry Pi itself. I thought we had changed it by default, but apparently did not.

So the Pi 4 series will actually boot, but not launch pretty much everything if there is no HDMI plugged in. The why is that with no monitor connected the Pi will not launch the graphical environment. With Pi 3 had composite enabled by default, which was equivalent of having a monitor plugged in, even if no monitor was plugged in.

See here for the fix:

https://github.com/luxonis/depthai-hardware/issues/45#issuecomment-788632720

Thoughts?

Thanks,
Brandon

pikelcw

Hello @Brandon ,

I had changed these settings but it still does not boot.
After changing the settings and plugging in 5V, only the PWR LEDs came up, other LEDs did not.
And also the USB wifi dongle's LED did not turn on.

Anything else I can try?

Thanks

Brandon

Hi pikelcw ,

That's odd. I think my unit (without the settings changed) does the same thing - at least no activity light - when there is no HDMI plugged in.

We'll try to reproduce.

Sorry about the trouble here.

-Brandon

Brandon

Confirmed that my Pi CM4 DepthAI boots with monitor connected by does not boot w/ no monitor. Trying some things...

Brandon

Hrm... none of the tricks that worked before are working. I wonder if the new version or Raspbian changed this boot behavior for Pi 4.

Brandon

Searching... https://raspberrypi.stackexchange.com/questions/109279/pi-4b-wont-boot-without-hdmi-cable-plugged-to-monitor

Brandon

Yes, I can't figure out why this doesn't work anymore w/out a monitor plugged in. We definitely had this working before.

Brandon

Alright, I finally got it.

To get the Pi 4 to boot up completely without HDMI attached, adding this to /boot/config.txt did the trick:

enable_tvout=1

Please note though that for me this actually completely prevented HDMI from working at all. But I think for the use-case here, that's fine.

Thoughts?

Thanks,
Brandon

pikelcw

Hello Brandon,

Sorry for the late reply. I've tried adding enable_tvout=1, it is still not working.
Would you mind sharing your whole /boot/config.txt?

Thanks

zenstyle

I'm also getting the following error, on the xavier platform.. so far I can't find anyway to make it stable, and I'd like to use gen2 code for handtracking..

RuntimeError: Communication exception - possible device error/misconfiguration. Original message 'Couldn't read data from stream: 'disparity' (X_LINK_ERROR)

Brandon

Hi zenstyle ,

Which DetphAI version are you using? We recently released an update that fixed the Pi/Jetson instability.

Brandon

The release that has this fix is 2.4, released 2 days ago:

The fix is also now in the main branch of both of those repos.

So I'm thinking that since this was so recently released it's likely that an older version is being used. (I'm hoping so.)

Thoughts?

Thanks,
Brandon

zenstyle

Brandon unfortunately it is v2.4.0 / v2.4.0.0, also I see these resets in my dmesg

usb 1-2.4.1.3.3: USB disconnect, device number 112
usb 2-1.4.1.3: new SuperSpeed USB device number 75 using tegra-xusb
usb 2-1.4.1.3: New USB device found, idVendor=03e7, idProduct=f63b
usb 2-1.4.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.4.1.3: Product: Luxonis Device
usb 2-1.4.1.3: Manufacturer: Intel Corporation
usb 2-1.4.1.3: SerialNumber: 14442C105141CCD200
usb 2-1.4.1.3: USB disconnect, device number 75
usb 1-2.4.1.3.3: new high-speed USB device number 113 using tegra-xusb
usb 1-2.4.1.3.3: New USB device found, idVendor=03e7, idProduct=2485
usb 1-2.4.1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2.4.1.3.3: Product: Movidius MyriadX
usb 1-2.4.1.3.3: Manufacturer: Movidius Ltd.
usb 1-2.4.1.3.3: SerialNumber: 03e72485

Brandon

zenstyle Thanks.

So how is DepthAI being powered and which USB cable is being used? I'm wondering if there is a power issue here or perhaps a USB3 issue.

I'm going to look up the command for initializing the pipeline over USB2 only to check the USB3/cabling-problem potential here.

zenstyle

I'll test a few configs, but I've made sure the OAK-D is separately powered and the hub.

Brandon

Got it. Thanks. And if you could share a photo of the setup sometimes that helps. Finding the USB2 force parameter now as well, so that you can start the pipeline in USB2 to see if that's the issue.

Brandon

OK, found it. Try changing the line in the example your are running that has the Device(pipeline) to

Device(pipeline, usb2Mode=True) and see if the stability improves and/or the issue goes away. If that's the case, then we know this is some sort of issue with the signal integrity (or host driver, but that's rare) of USB3,

And for USB3, the cable quality and length seems to matter quite a bit.

zenstyle

Yes that works, you're amazing... It's weird I'm using a new cable from the box and it works fine until I put my hand in the image then it crashes in USB3 mode... seems it's a little slower but works fine in usb2 without crashing..

Again amazed by the immediate responsiveness and specificity in solving that, just want to separately thank you.

Brandon

zenstyle Thanks. That is weird. Not exactly sure what is going on, but we have seen some issues with USB3 on some hosts. Trying a different port and/or different cable could maybe improve this. Funnily enough, we've seen more field failures of the USB3 cables we down-selected on then on OAK-D itself. So it could be that this cable is just not good. We're more than happy to send you a new one as well if that would help. (And in USB cables, USB3 and USB2 are actually different wires - so USB2 can work fine even if the USB3 wires are damaged or mis-assembled.)

Thanks,
Brandon