fixed focus oak-d-lite doesn't throw errors on autofocus APIs or declare it is fixed focus

[diablodale]

I got my oak-d-lite fixed focus cameras and discovered that they do not id themselves as fixed nor do the autofocus apis throw errors.
At a minimum, I believe autofocus apis/commands to fail or throw errors.

Setup

• Microsoft Windows [Version 10.0.19044.1466]
• VS2019 v16.11.8
• depthai-core v2.13.3 + xlink move/thread fixes
• oak-d-lite fixed focus

Repro

1. cmake config and build depthai-core for x64, debug, shared lib
2. cmake install
3. create main app to include code similar to below
4. point main app config to install location
5. config and build main app
6. Run main app and also watch console/debug output

rgbCamera->initialControl.setAutoFocusMode(dai::CameraControl::AutoFocusMode::CONTINUOUS_VIDEO);
device = std::make_unique<dai::Device>(config, DeviceInfo);

Result

App runs.
No exceptions, errors, nor console/debug log output indicating that the autofocus apis will not and did not work on the fixed focus camera.

Expected

API to throw exceptions or return errors that indicate the specific problem of "no autofocus on this camera". I consider this to be the same level of error as calling an API for a sensor that doesn't exist on the device.

Notes

The way in which the API failure will likely be different for each api or scenario. For example

• rgbCamera->initialControl.setAutoFocusMode() is called before the camera pipeline starts. So without prior knowledge of the specific cameras abilities, no error is possible here. Caveat, future knowledge of the sensor might be possible with Device Discovery and Board Configuration #285
• std::make_unique<dai::Device>() is a good place to throw exception or return an error. However, there are many errors that can occur here (no autofocus, no IMU, etc.). How does an app discern which error has occurred? I would prefer specific exceptions for each error case. If not that, then at a minimum, the exception::what() text should be specific, customer ready language, and unchanging.
• later runtime calls to APIs like dai::CameraControl::setAutoExposureRegion() should throw exceptions since the knowledge is readily available that the camera has no autofocus. One doesn't even need to spin up an XLink packet since the host-side depthai-core code can cache the knowledge that there is no autofocus.

Workarounds?

I do not know of any workarounds.
Is there any command or api that can detect a fixed focus color camera? Something that declares it or will fail/throw?
If such exist, then I can probe and persist the knowledge.

[Luxonis-Brandon]

Thanks! CC: @alex-luxonis and @saching13 - I'm not sure if we declared this in the EEPROM that they're fixed focus. I didn't think of it at least.

[diablodale]

Comparing my oak-d (self calibrated with cali script) and oak-d-lite (factory calibrated)...

• OAK-D eeprom::cameradata::rgb::lensPosition=135. That was the default autofocus value in the cali script
• OAK-D-Lite ...::lensPosition=0

Maybe I can risk assuming that any oak-d-lite that has a lensPosition=0 is a fixed focus?
Sure it is possible someone custom calibrates using the cali scripts and uses a custom focus value...but that is probably a very small set of people. 🤷‍♀️

[saching13]

Maybe I can risk assuming that any oak-d-lite that has a lensPosition=0 is a fixed focus?

Yes.
So there was no programmatic way to detect that. But during calibration, it is set to zero. Since all the autofocus will have a number for lensPosition we can just go with lensPosition = 0 being the Fixed focus. Will add a new field for this when we do another major upgrade for EEPROM data.

[saching13]

Sure it is possible someone custom calibrates using the cali scripts and uses a custom focus value...but that is probably a very small set of people. woman_shrugging

Yes. But as of now the script in the main cannot be used for OAK-D-Lite Calibration.

[diablodale]

Got it. I've implemented the probing workaround.

[diablodale]

closing as my local probing continues to work, and don't call the errant APIs when I can predict they could fail.
Also, newest depthai-core using a series of camera name (e.g. "color") to camera board enum can be use to query dai::CameraFeatures::hasAutofocus