`StereoDepth::setDepthAlign()` uses deprecated `CameraBoardSocket`, and no way to set using symbolic name "color"

[diablodale]

StereoDepth::setDepthAlign() continues to use deprecated enums to pre-declare during pipeline setup that it is desired to align depth data to the color camera. dai::CameraBoardSocket::RGB is deprecated. And StereoDepth::setDepthAlign() has no symbolic name param like ColorCamera::setCamera(std::string name). Therefore, it is impossible to align, during pipeline setup, unless the currently plugged in sensor is briefly started+probed, to then get the CameraBoardSocket and then create a 2nd pipeline with that socket.

See luxonis/depthai-shared#142

Current replacement mechanism is setCamera. left, right, color would be the names corresponding on the usual devices.

In addition ,throughout depthai-core tests and examples, they use deprecated CameraBoardSocket. Tests should use both old supported and whatever-is-the-current methodology.

[diablodale]

Same for dai::CalibrationHandler::getCameraIntrinsics(...), there is no association with the current symbolic names of cameras.
It is a now a multi-step process to derive the CameraBoardSocket from the symbolic name and then call getCameraInstrinsics with a socket enum (even though the API is named "Camera"). This is not unusual for an API set that is diverging from original design, so it only needs a migration path for devs

[moratom]

Thanks for the issue report @diablodale.

We'll try to improve on this front to unify the API when the next major version is released.

To mitigate this on v2 we will expose dai::Device::getCameraBoardSocket(name) function.

This would solve your issue, correct? It's still be a bit more involved than before, but dual pipeline creation won't be necessary anymore.

[diablodale]

No rush for me. I already probe and persist locally detailed sensor information. I updated my probe code and schema to get the miswsing socket->camera mapping. This issue is for my own tracking and for other/future developers and their needs.

If dai::Device::getCameraBoardSocket(name) is an RPC call, then I see no value. It is still a 2 connection process.

1. create Device(...)
2. auto socketColor = dai::Device::getCameraBoardSocket("color")
3. close Device()
4. create pipeline
5. stereoDepth->setDepthAlign(socketColor)
6. create Device(pipeline)

[moratom]

It's not necessary to start the pipeline on the device immediately, although this is almost always the case in our examples.

See https://github.com/luxonis/depthai-python/blob/main/examples/IMU/imu_rotation_vector.py.

1. create Device()
2. query the necessary info
3. build the pipeline
4. device.startPipeline(pipeline)

[diablodale]

That's an Interesting subtle alternate. 🤔
When I probe and persist locally, I create a pipeline with only a script node to verify general device sanity. I create a Device(pipeline) and then check the device is sending and host receives expected "pings". After that, I probe that device and persist results locally.

If I remove the ping/sanity check, it removes the pipeline, then I might be able to probe the sensor for data I need to persist by only Device(getOpenVINOVersion()). However, the openvino depends on the pipeline's needs so there might be a circular issue where I can't create a Device(not pipeline) that will work generally with any pipeline I later create given what I learn from the probe. I'll try using the newer Device(OpenVINO::VERSION_UNIVERSAL) and then I don't first need a pipeline.

If I can get around that, I might be able to simplify this into a single xlink connect. I'll need to check PoE because anything on PoE gen2 is painfully slow. I can't have the PoE startup get even longer than it already is. I suspect I'll keep persisting.