I've been using an OAK-D for object detections. Anything using the RGB camera stream works fine but I'm running into a pipeline issue with stereo depth nodes. My implementation uses the following: depthai 2.22.0.0 OAK-D camera Ubuntu 20.04 in a VMWare virtual machine Luxonis RGB Depth Alignment Python script found here I copied the alignment script onto my machine and ran it, but I'm confronted with the error: [14442C10619FF0D000] [3.2.1] [2.723] [system] [critical] Fatal error. Please report to developers. Log: 'Fatal error on MSS CPU: trap: 09, address: 802CE934' '0' I wasn't able to find a solution in the existing posts on this issue. Here is the full console output:

Fatal error on MSS CPU: trap: 09, address: 802CE934' '0'

aiManny

I've been using an OAK-D for object detections. Anything using the RGB camera stream works fine but I'm running into a pipeline issue with stereo depth nodes.

My implementation uses the following:

depthai 2.22.0.0
OAK-D camera
Ubuntu 20.04 in a VMWare virtual machine
Luxonis RGB Depth Alignment Python script found here

I copied the alignment script onto my machine and ran it, but I'm confronted with the error:

[14442C10619FF0D000] [3.2.1] [2.723] [system] [critical] Fatal error. Please report to developers. Log: 'Fatal error on MSS CPU: trap: 09, address: 802CE934' '0'

I wasn't able to find a solution in the existing posts on this issue. Here is the full console output:

erik

Hi aiManny ,
Does it crash every time at startup? Does it crash outside the VM as well (directly on Ubuntu)?

aiManny

Thank you for the rapid response erik!

It crashes every time at startup. But if I comment out all the stereo node instantiations and references then it runs fine and displays the RGB camera stream as it should.

I will try the original script directly on Ubuntu and let you know

aiManny

erik do you suspect this is a hardware/firmware issue? I purchased my OAK-D back during the original kickstart in 2020 and am just now testing the stereo features.

aiManny

I just tested the script on an Ubuntu OS and got the same issue crash and error message

erik

Hi aiManny ,
My guess would be a software issue. Could you try some other example code that uses depth, besides the rgb_depth_alignment.py?

aiManny

I just attempted the Depth Preview example found here. Unfortunately I got the same error message and CPU trap address:

[14442C10619FF0D000] [3.2.1] [2.697] [system] [critical] Fatal error. Please report to developers. Log: Fatal error on MSS CPU: trap: 09, address: 802CE934 0

Traceback (most recent call last):

File "depth_test.py", line 51, in <module>inDisparity = 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)

Ben

By pure chance, I am running into the same error today after not using my Oak-D for a while (mine is also a kickstarter era model). I think it may be related to a lack of calibration information on my device. I do not seem to have valid calibration information in the EEPROM (cannot read it or reflash a factory config using the tools in the depthai-python/examples/calibration repo). As a result (I assume) I get this error anytime I attempt to do anything with the depth cameras.

The reason I logged on to the forum was to get some help with the calibration process - for some reason it seems to be running agonizingly slow, less than 1 fps with huge latency. I have tried it on Linux and Windows, with a variety of USB3 and USB-C cables. Maybe I am just spatially challenged, but I cannot get through the 39 image calibration routine with the frame rate running so slow - it's endlessly frustrating trying to find the right orientation of the board acceptable to the calibration script. Therefore I am unable to verify whether successfully flashing a new camera calibration will resolve the issue.

Is it normal for the calibration routine to run so poorly? The example in the video on the calibration trouble shooting page seems much smoother.

aiManny

That's definitely an intriguing development. In my case, I was able to successfully calibrate my OAK-D back during the summer of 2022 (originally the RGB wasn't working with Aruco markers the way I'd expected).

aiManny

@erik, could this CPU Trap issue be related to a faulty calibration?

erik

Hi aiManny ,
That might be the case as well, if it only crashes on stereo depth examples. Perhaps you could try to calibrate it?

aiManny

My calibration script was a year outdated, so I went ahead and cloned the latest depthai repo with git clone https://github.com/luxonis/depthai.git and ran the python3 install_requirements.py inside a new virtual environment (just to be safe). When I tried to run the the calibration script it threw this:

I don't understand why this worsened things! Now my OAK-D no longer shows up when I run lsusb, and all my other OAK-D scripts that were running fine yesterday are failing with the same error above. I'm still using the USB 3.0 cable, and the light on my OAK-D is coming on. So far I've tried resetting the udev rules with:

echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="03e7", MODE="0666"' | sudo tee /etc/udev/rules.d/80-movidius.rules

sudo udevadm control --reload-rules && sudo udevadm trigger

However, that didn't fix anything

jakaskerl

Hi aiManny
Updating depthai repo couldn't have worsened things but combining it with a new venv might have. Try to install the latest version of depthai library and check whether your virtual environment is causing the problem.

Thanks,
Jaka

aiManny

After restarting my VM several times, the camera is now detectable. I ran through a calibration and was able to capture images and view reprojection error, but before it finished I received this error:

Should I retry calibration, resort to a factory reset, or perhaps something else?

jakaskerl

Hi aiManny
I think there is a problem with the calibration script for your specific board. Could you create an issue at depthai repo and tag https://github.com/MaticTonin.

Thanks and sorry for the inconvenience,
Jaka

aiManny

Recalibrating solved it! It took a little work, as documented in this depthai issue, but all stereo functions are running as they should. Thank you all for the in-depth support.