[RSDK-8402] Migrate from OakCamera to DepthAI

[hexbabe]

RSDK-8402

PR comment in luxonis/depthai
We were notified by Luxonis folk that they are sunsetting the OakCamera SDK. We should refactor our integration to use DepthAI

This PR switches out OakCamera functionality with the equivalent new idioms presented in their new shiny documentation https://docs.luxonis.com/

I did more thorough manual testing since this is kind of a huge change.

Testing

OAK-D tests on Mac

Integration tests

Passing ✅

OAK-D config with "color" sensor (get_image stream on app)

{
  "sensors": [
    "color"
  ]
}

✅

Reconfigure from above -> OAK-D config with "color" sensor and dimensions (get_image stream on app)

{
  "sensors": [
    "color"
  ],
  "width_px": 640,
  "height_px": 480
}

✅

Reconfigure from above -> OAK-D config add FPS (get_image stream on app)

{
  "sensors": [
    "color"
  ],
  "width_px": 640,
  "height_px": 480,
  "frame_rate": 10
}

Same as above but with choppy stream ✅

Reconfigure from above -> OAK-D config with color main sensor and depth secondary sensor (get_image stream on app)

{
  "sensors": [
    "color",
    "depth"
  ],
  "width_px": 640,
  "height_px": 480,
  "frame_rate": 10
}

Same as above ✅
I also switched the order and tested color as the main sensor with get_image and it looks good too ✅

Reconfigure from above -> OAK-D config with depth main sensor and color secondary sensor (get_image stream on app)

{
  "sensors": [
    "depth",
    "color"
  ],
  "width_px": 640,
  "height_px": 480,
  "frame_rate": 10
}

✅

OAK-D config with depth main sensor and color secondary sensor (get_images from my Python client)

{
  "sensors": [
    "depth",
    "color"
  ],
  "width_px": 640,
  "height_px": 480,
  "frame_rate": 10
}

Honestly in a future PR I should source control the Python test client. But the results look good!
✅

OAK-D config with depth main sensor and color secondary sensor (get_point_cloud from app)

{
  "sensors": [
    "depth",
    "color"
  ],
  "width_px": 640,
  "height_px": 480,
  "frame_rate": 10
}

✅

OAK-FFC-3P on my RPI4

Single sensor on cam_c (get_image on app)

{
  "camera_sensors": [
    {
      "height_px": 720,
      "socket": "cam_c",
      "type": "color",
      "width_px": 1280
    }
  ]
}

Hey Johnn ✅

Reconfigure from above -> two sensors with main on cam_b (get_image on app)

{
  "camera_sensors": [
        {
      "height_px": 720,
      "socket": "cam_b",
      "type": "color",
      "width_px": 1280
    },
    {
      "height_px": 720,
      "socket": "cam_c",
      "type": "color",
      "width_px": 1280
    }
  ]
}

✅

Two sensors with main on cam_b (get_images with python test client)

{
  "camera_sensors": [
        {
      "height_px": 720,
      "socket": "cam_b",
      "type": "color",
      "width_px": 1280
    },
    {
      "height_px": 720,
      "socket": "cam_c",
      "type": "color",
      "width_px": 1280
    }
  ]
}

Two similar images were .show()-ed successfully by pillow ✅

Two sensors with main on cam_b with all attributes configured (get_image on app)

{
  "camera_sensors": [
    {
      "height_px": 720,
      "socket": "cam_b",
      "type": "color",
      "frame_rate": 5,
      "color_order": "bgr",
      "interleaved": true,
      "width_px": 1280
    },
    {
      "type": "color",
      "width_px": 1280,
      "height_px": 720,
      "socket": "cam_c"
    }
  ]
}

Color wonkiness of BGR is good. Frame rate looks around 5. Interleaved is not visually discernable, but no errors and we do set it! ✅

[seanavery]

LGTM. Nice work!

Just left a couple of questions to better understand things.

BGR color wonkiness ok? Or should we handle that better?

[seanavery]

[q] will this infinite loop if device fails to initialize?

[hexbabe]

Yes it will, but since it's an async function that async sleeps, it should yield to other tasks on the event loop

[seanavery]

[q] Will there be any issues wrt early exit of the try block here if one of the nodes fails to initialize?

[hexbabe]

Good point. I think we actually set configured to True after, which is wrong. I'm gonna change it to re-raise a helpful exception instead in the except block

[hexbabe]

Done

[seanavery]

[q] Is it ok to have hardcoded queue size here?

[hexbabe]

Done (unhardcoded it and cleaned up some defaults at the top of the file)

[hexbabe]

BGR color wonkiness ok? Or should we handle that better?

BGR looking weird through App is expected. On the scope, Pete raised the point that on Tennibot's demo repo, they request BGR color order explicitly. The attribute is default rgb unless bgr is explicitly supplied though