Hi, OAK/depthai newbie here, We're evaluating the use if the OAK-D-POE within ROS, mainly just using sample code from the `depthai-ros-examples` repo at the moment. However the device loses connection once or twice per day, requiring a power cycle to get it talking again. Sometimes this occurs when trying to restart the relevant ROS nodes. When it goes dark it's no longer pingable and the depthai config utility doesn't pick it up either. The device is: - Plugged directly into a PoE-capable PC (Intel I350-AM4 controller, 802.3at, 25W per port) - Configured for a static IP (same subnet as the ethernet interface, only device on that interface) - Using the latest depthai version (2.17.10) and bootloader (0.0.18) I'll swap the ethernet cable next chance I get but don't currently have physical access to the system. At the moment I'm just looking for general troubleshooting tips beyond what I can find in the docs. Anywhere in particular I should be looking for errors? Does the device do any internal logging that I could retrieve after the fact? `dmesg` isn't showing anything out of the ordinary on the computer's side. Thanks, Greg

Sorry, yeah, two corrections: - depthai version is 2.17.1. - exact device is the "OAK-D Pro PoE" I didn't realize there was a new release since I had updated, so I'll get us on 2.17.2 today. [Here's the example we're using](https://github.com/luxonis/depthai-ros-examples/blob/b2675aa1fa8b6cb320de9528b28a0e0e7949f46c/depthai_examples/launch/stereo_inertial_node.launch), which [runs this pipeline](https://github.com/luxonis/depthai-ros-examples/blob/b2675aa1fa8b6cb320de9528b28a0e0e7949f46c/depthai_examples/ros1_src/stereo_inertial_publisher.cpp). If there's any other info I can help provide just let me know. Thanks, Greg

Diagnosing PoE instability

Greg

Hi, OAK/depthai newbie here,

We're evaluating the use if the OAK-D-POE within ROS, mainly just using sample code from the depthai-ros-examples repo at the moment.

However the device loses connection once or twice per day, requiring a power cycle to get it talking again. Sometimes this occurs when trying to restart the relevant ROS nodes. When it goes dark it's no longer pingable and the depthai config utility doesn't pick it up either.

The device is:

Plugged directly into a PoE-capable PC (Intel I350-AM4 controller, 802.3at, 25W per port)
Configured for a static IP (same subnet as the ethernet interface, only device on that interface)
Using the latest depthai version (2.17.10) and bootloader (0.0.18)

I'll swap the ethernet cable next chance I get but don't currently have physical access to the system.

At the moment I'm just looking for general troubleshooting tips beyond what I can find in the docs. Anywhere in particular I should be looking for errors? Does the device do any internal logging that I could retrieve after the fact?
dmesg isn't showing anything out of the ordinary on the computer's side.

Thanks,
Greg

erik

Hi Greg ,
We apologize for this issue. Just curious - which depthai version are you using (as 2.17.10 is typo)? In 2.17.1 we had added stability fixes, specifically for POE cams which fixes sporadic issues once every few hours (so similar to what you are expecting here). Due to other issues (initialization failing in about 20%) we had to revert that back in 2.17.2. Could you share the pipeline/example you are using?
Thanks, Erik

Greg

Sorry, yeah, two corrections:

depthai version is 2.17.1.
exact device is the "OAK-D Pro PoE"

I didn't realize there was a new release since I had updated, so I'll get us on 2.17.2 today.

Here's the example we're using, which runs this pipeline.

If there's any other info I can help provide just let me know.

Thanks,
Greg

erik

Hi Greg ,
Please do provide updates on these tests. If it doesn't work as expected, could you provide a detailed overview of this problem (how to reproduce, all relevant program versions, MRE, etc.) on depthai-core Issue, so it's easier to track?
Thanks, Erik

Greg

It's a little tricky to create an MRE since this happens after some random number of connections, but I have found that hard-killing the process will take the device offline somewhat more consistently. I opened an issue with more info here: https://github.com/luxonis/depthai-core/issues/547

erik

Greg Thank you for the testing and details provided in the Issue! As Brandon mentioned, we are currently looking into this.
Thanks again, Erik