OAK-D Pro W PoE: WARP_SWCH_ERR_CACHE_TO_SMALL

Tom

Hello,

I'm having some trouble with my OAK-D Pro W PoE w/ OV9782 and would appreciate some help.

I have created an image/video server that runs locally on the camera in a script node, similar to the examples below:

I have three of these cameras, each with the OV9782 main sensor. For two of them, I have been able to flash the pipeline and use the servers successfully. However, on this last camera, I am having some problems.

I have reduced this down to a small sample that reproduces the error. Here, the script node containing the server is omitted.

import depthai as dai
import time


def main() -> None:
    # Device info.
    ADR = "10.0.0.4"
    device_info = dai.DeviceInfo(ADR)
    pipeline = dai.Pipeline()

    # Camera node.
    cam = pipeline.create(dai.node.Camera)
    cam.setSize(1280, 800)

    # Video encoder node.
    jpeg = pipeline.create(dai.node.VideoEncoder)
    jpeg.setDefaultProfilePreset(cam.getFps(), dai.VideoEncoderProperties.Profile.MJPEG)

    # Connections.
    cam.video.link(jpeg.input)

    # Load pipeline.
    with dai.Device(pipeline, device_info) as device:
        device.setLogLevel(dai.LogLevel.DEBUG)
        device.setLogOutputLevel(dai.LogLevel.DEBUG)
        while not device.isClosed():
            time.sleep(1)


if __name__ == "__main__":
    main()

When the connection between the camera's video output and the video encoder is made, I get the following error:

[184430107175960F00] [10.0.0.4] [4.860] [Camera(0)] [error] Not possible to create warp params. Error: WARP_SWCH_ERR_CACHE_TO_SMALL 

[2023-10-17 12:33:46.165] [warning] Monitor thread (device: 184430107175960F00 [10.0.0.4]) - ping was missed, closing the device connection

From my research, it seems this is related to the unwarping/undistorting of the lens, which is the reason I am using the Camera node and not the ColorCamera node. My full servers work totally fine with ColorCamera but I do need that lens correction.

I'd appreciate some help with this issue, or a workaround for the lens correction. Thanks!

jakaskerl

Hi Tom
Works for me on depthai==2.23.0. I changed the setSize to (1920, 1080) since I had problems with width not being a multiple of 32 (using imx378).

Thanks,
Jaka

Tom

jakaskerl

Thanks for giving this a try! I am wondering if this could be a hardware issue, since it also works on my other two cameras, but this one consistently fails.

jakaskerl

Hi Tom
I think this is related to the CMX allocation to manip node. This should have been fixed to be dynamically allocated, but apparently it doesn't work with Camera node warp.

Could you try modifying the setSippBufferSize() and setSippDmaBufferSize().
https://docs.luxonis.com/projects/api/en/latest/references/python/#depthai.Pipeline.setSippBufferSize

Thanks,
Jaka

Tom

jakaskerl

I've allocated 192 KB on each, but this still produces the same error as before.

When I try to allocate more (256 KB each), it seems that I am out of memory:

RuntimeError: SIPP (Signal Image Processing Pipeline) out of memory; 
tried to allocate '256000'B out of '218112'B available. You can increase 
the size by setting 'sippDmaBufferSize' in 'BoardConfig'.

I was not able to find this property in the BoardConfig class of the Python API.

This seems like quite a small amount of memory relative to the image size, but I am not sure exactly the use case of this buffer.

jakaskerl

Tom
Checking with the dev team...
Will report back when I get some info.

Tom

jakaskerl Great, thanks!

jakaskerl

Hi Tom
This highly depends on the depthai version you are using (we've had problems with 2.21.2) so updating to the latest 2.23.0 is the first step.

Looks like there also might be a problem with the calibration. Could you fetch the calibration data from the device that fails, perhaps so we can reproduce it locally. And also, adding the calibrations for the working two devices as well if you can will be very helpful.

Thanks,
Jaka

Tom

jakaskerl I've just updated to 2.23.0, and no longer getting this error!

I don't recall my old version, but I am reasonably sure it was 2.21.3.

I'm not sure if the calibration data would still be helpful for the dev team since things are working now, but I'm happy to send that over if desired!

Thanks for following up on this!