Per this discussion Zed X set AEC_AGC_ROI always return failure, the ROI width and height for auto exposure/gain must be >=256.
When setting with an ROI where the width/height are both < 256. The setCameraSettings(sl::VIDEO_SETTINGS::AEC_AGC_ROI, ...) function does return an error code (“The function does not perform as expected”). However, after several more loops (set ROI to different value then grab), a grab() eventually blocks and one of two happens:
- “(Argus) Error FileOperationFailed: Failed socket read …” error occurs, pause for 10-20 seconds, then API is able to reopen the Camera and continue
- “(Argus) Error Timeout: (propogating from …” occurs, pause for 20-30 seconds, and program SegFaults.
sudo systemctl restart zed_x_daemon must then be run in order to read from the Camera (regardless if in script or ZED Explorer)
Hardware:
- Nvidia Xavier NX
- ZED X
- Mono Capture Card
Software:
- SDK 4.1.3 (tried on 4.1.2 as well)
- Mono Driver 1.0.5 L4T35.4.1
- Jetpack 5.1.2
I’ve attached a C++ script that does a basic grab() in a loop while adding jitter to the AEC_AGC_ROI around the 256 threshold for width and height. On our system, it crashes 100% of the time and usually within 5 seconds.
zedx_autoexposure_roi_crash.cpp (2.4 KB)
Update 1:
I rewrote the above script to instead slowly step down from 500 width and 500 height after each grab. It consistently fails at width and height 280-281 at which it fully SegFaults and the ZED X daemon must be rebooted. This is strange because it is not the 256 threshold mentioned previously.
zedx_autoexposure_roi_crash_gradualStepdown.cpp (2.3 KB)
Hi @penguin,
Thank you for reporting this issue.
In both cases, the “(Argus) …” errors mean that nvargus camera (which is the camera capture stack used by the ZED SDK for the ZED X) has crashed.
The first behavior you’ve noticed is expected when argus camera crashes, the ZED SDK reboots it and this can take ~10-20 seconds depending on the platform/number of cameras to restart. This allows us to recover from these types of errors and restore the camera feed.
In general, it is not recommended to change Auto exposure parameters at each grab, as the auto-exposure takes a few frames to be applied. As we cannot control the behavior of argus when receiving many commands like this, I would suggest limiting the amount of ROI changes.
Does the system crash when setting the ROI size once to the 280-281 size limit you’ve mentioned?
Hi @mattrouss,
Thanks for the response. We can look to limiting the number of Auto-exposure updates on our deployed application. “… auto-exposure takes a few frames to be applied”: Is it number of frames or time-based? I ask because our application sets the FPS to 60 but only grabs at ~10 FPS.
When stepping down the ROI width/height by 1 every grab, it would either:
- Stop grabbing and crash at 281 OR
- Slow down (longer grab time) at 281 and then stop grabbing and crash at 280
I re-ran the gradualStepDown script I attached again with it only updating the ROI every 30 frames and it stopped at 287, reopened after ~10-20 seconds, then stopped again at 281, reopened after ~10-20 seconds but then every grab failed. No SegFault though
The auto-exposure duration to be applied varies depending on the starting and ending exposure, so I would say it is time based.
The frame rate of your application highly depends on the algorithms that you use. For example, if you activate a DEPTH_MODE, the depth computation is included in the grab() call. This is true for our other modules in the ZED SDK.
You can disable all ZED SDK modules and set the depth mode to DEPTH_MODE::NONE for a higher frame rate.
It seems that argus camera crashes until it is no longer able to recover.
We are currently working on the reliability of the GMSL connection with argus, in order to improve the recoverability of our cameras.
Our grab() rate is low due to issues external to the ZED SDK.
We just finished testing and a 2 Hz auto-exposure update worked well. Also, limited our ROI to 300 pixels for width and height and did not run into any issues.
We will stay on the lookout for ZED X Driver updates in the future to fix this issue.