Summary:
We need to capture images with Argus using an external hardware trigger (e.g. by a light barrier). Therefore we tried to enable an infinite timeout by setting enableCamInfiniteTimeout=1. Unfortunately, this is not working. We get the following output:
SCF: Error InvalidState: Timeout!! Skipping requests on sensor GUID 1, capture sequence ID = 3 draining session frameStart events 2
(in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameStart(), line 529)
SCF: Error Timeout: Sending critical error event for Session 1
(in src/api/Session.cpp, function sendErrorEvent(), line 1039)
SCF: Error InvalidState: Sensor 1 already in same state
(in src/services/capture/CaptureServiceDeviceSensor.cpp, function setErrorState(), line 100)
SCF: Error InvalidState: Timeout!! Skipping requests on sensor GUID 1, capture sequence ID = 3 draining session frameEnd events 2
(in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 646)
SCF: Error InvalidState: Sensor 1 already in same state
(in src/services/capture/CaptureServiceDeviceSensor.cpp, function setErrorState(), line 100)
SCF: Error InvalidState: Timeout!! Skipping requests on sensor GUID 1, capture sequence ID = 4 draining session frameEnd events 1
(in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 646)
SCF: Error InvalidState: Sensor GUID 1 is in error state. Skipping requests, capture sequence ID = 4 continue draining session frameStart events 1
(in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameStart(), line 543)
For r35.4.1, @JerryChang provided a patch which made the infinite camera timeout work but it had the issue that waitForEvents did not return even if the timeout parameter was set. He suggested to move on with r35.5.0 but there, enableCamInfiniteTimeout=1 still gives the timeout errors.
Is there a way to make enableCamInfiniteTimeout work on Jetson Orin Nano?
unfortunately, one of change did not catch r35.5.0 public release.
please apply this pre-built library to fix enableCamInfiniteTimeout support.
i.e. Topic284939_Mar06.7z (1.6 MB)
please try again with below steps for confirmation.
for instance, $ sudo service nvargus-daemon stop $ sudo enableCamInfiniteTimeout=1 nvargus-daemon
thanks for the file. It works as it did on r35.4.1 with your patches. But there is still the issue with the waitForEvents function. It does not respect the timeout parameter, instead it keeps waiting forever if no event occurs. This blocks the reading thread if the camera is not triggered which is a problem e.g. when closing the application. Could that be fixed? All I need is that the waitForEvents function returns after the given timeout.
I’m afraid it cannot be fix.
FYI,
it’s enableCamInfiniteTimeout to configure timeout of waiting SOF signal from CSI channel.
it’s low-level camera driver, (i.e. RCE firmware), it’ll be waiting continuously only when it received SOF signal, then, it’ll send frame-start event to queue the buffer.
that means… only when SOF signal received, it’ll send capture request to Argus stack for buffer processing.
besides infinite timeout,
you may have another approach to configure set_mode_delay_ms in the device tree,
this is property setting for the first frame after capture starts, the unit is in milliseconds.
please see-also Device Properties for details.
that are bad news. I am still not sure if I understood it correctly. Does that mean, that waitForEvents makes a call to the low level camera driver which cannot be aborted and this call blocks until an event occurs? But then the timeout parameter would not make sense at all, even with enableCamInfiniteTimeout disabled. If the timeout is shorter than the period if incoming HW events, it would always wait longer than the provided timeout. Is that correct? So what is the purpose of this timeout?
I assumed the queue was polled periodically or by using a condition variable in which case one could define a timeout or notify the waiting thread using a timer. Maybe, would you be so kind to describe it a little more in detail, so that I could understand why this is not possible?
Regarding the set_mode_delay_ms: As I understand this is only for the first frame right? So timeout would still occur after the first image. Also it would be not good solution for us, because it is hardcoded in the device tree. If we use streaming mode, timeouts events should still be fired. With enableCamInfiniteTimeout we could configure it on demand without re-flashing the device tree.
with set_mode_delay_ms set to a high value (5min), I still get timeouts after some seconds:
SCF: Error InvalidState: Timeout!! Skipping requests on sensor GUID 1, capture sequence ID = 3 draining session frameEnd events 2
(in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 646)
SCF: Error Timeout: Sending critical error event for Session 1
(in src/api/Session.cpp, function sendErrorEvent(), line 1039)
SCF: Error InvalidState: Sensor 1 already in same state
(in src/services/capture/CaptureServiceDeviceSensor.cpp, function setErrorState(), line 100)
SCF: Error InvalidState: Timeout!! Skipping requests on sensor GUID 1, capture sequence ID = 4 draining session frameEnd events 1
(in src/services/capture/FusaCaptureViCsiHw.cpp, function waitCsiFrameEnd(), line 646)
FYI, we’ve never test such camera use-case with external hardware trigger.
however, we’ll have improvements of camera error resiliency for the next JP-6 public release.