Camera OAK-1 AF freezes after sending cameraControl requests

alexv

I have implemented a pipeline where the camera manual focus, auto-exposure by ROI, autoexposure Enable and autoexposure Compensation change depending on the activity being performed. When changing between activities there is a low frame rate that I asume is due to the change of the camera configuration. The issue I am having lately is that the camera stops sending frames after 20-30 minutes of this constant change, which was not the case before when the auto-exposure by ROI requests were sent. Is there any method to identify if the freeze in the camera is due to the cameraControl requests or if there are other things I should look for ?
I am using depthai v2.17.4 due to an issue explained here: image artifact depthai v2.17.4

Thank you for your help,

Alex

jakaskerl

alexv
Update depthai to latest version please.

Thanks,
Jaka

alexv

Hello @jakaskerl, I have updated my depthai version to 2.30 and still have the same problem.
To provide more details:

The freeze only happens when the camera is connected to an Android device via a HUB, which is connected to a portable battery as energy source for all the devices. When the camera is used on PC there is no freeze even overcharging the camera control requests to exagerated levels.
The freeze happens with the given context with both depthai versions: 2.17.4 and 2.30.0
The freeze happens after some time of use of the platform (Android device + OAK-1 AF + HUB + battery), which makes me question if there is a energy problem.
Once the freeze arrives, the camera gets back to send frames after 3 to 4 minutes of waiting. Which might be a little contradictory if the hypothesis of the energy is near to be correct.
All the freeze issues have started after the implementation of the autoexposure by region of interest. Before the main camera control requests were for manual focus, and autoexposure compensation (to increase or decrease the exposure gain).

I would like to have your insight with respect to this issue, and if you have some information more detailed about the minimum voltage/current that it is needed to operate at 100% the camera options, or if there are some previous cases where the camera freezes the frame flow.

Hope that you can provide some clues.

Thank you for your attention.

jakaskerl

alexv
Can you narrow down the variables?

What is this android device you mention? How is depthai running there? Can you connect to the device with PC but still use HUB + battery? Also the other way around, where you don't use the HUB + battery, but use the android device.
How are you triggering the AE/AF/... is it self enclosed on the device or are you sending the triggers/controls from the host (android device/PC)?

alexv Is it the same to setAutoExposureEnable() and setAutoExposureRegion() where the region is the whole image frame ?

Should be, yes.

Thanks,
Jaka

alexv

Hello @jakaskerl, could you please confirm if the method used to establish the best exposure values is the same for "setAutoExposureEnable" and for "setAutoExposureRegion". Is it the same to setAutoExposureEnable() and setAutoExposureRegion() where the region is the whole image frame ?

alexv

jakaskerl About narrowing the variables:

The Android device is a Vuzix M400 smart glasses (OS version 3.1.3, Android version 11 API 30). The OAK-1 AF camera is controlled by a module developed in C++ and accesed by the Android device through JNI.
I can connect the OAK-1 AF with PC using HUB + battery
I cannot connect the OAK-1 AF camera directly to the smart glasses. The internal battery of Vuzix M400 does not provide enough autonomy, thus the use of an external battery.
The OAK-1 AF receives triggers from the android device through the JNI. using the C++ module that contains the depthai library. When connected to a PC the camera is directly controlled by the C++ module. The focus is controlled manually based on the distance an identified object in the image (certain distance corresponds to certain focus value). The exposure is set to automatic by region in certain cases where the interest objects are closer to each other, and when they are too separated the auto-exposure in the whole image is applied. In this switch between AE by region and AE global is where I added an intermediate manual exposure setting since there were some cases where the exposure didn't change at all, independently of the illumination on the image.
The final product is the android application containing the c++ module to control the OAK-1 AF using the smart glasses Vuzix M400, the HUB and the external battery.

Hope that the context would help to find a reason for such blocking.