I’ve read https://support.stereolabs.com/hc/en-us/articles/206918319-What-is-the-latency-of-the-ZED-camera- ; however, I do not understand how this interacts with grabbing frames through the SDK.
Our camera (Zed2i) is on a mobile robot. We only call
.grab when the robot is stationary - yet we get blurry frames that have blur matching the recent movement of the robot during the previous half second.
Is this a result of the latency from the USB controller? Is the SDK continuously polling data from the camera even when I don’t grab frames and then returning data that is a few frames old when I do call
.grab? I’d expect that calling
.grab triggers the actual frame capture which would then always return a non-blurry frame as the robot is stationary.
If latency is the issue, do you have any tips for reducing latency or diagnosing why it can be so variable ? Could a damaged USB cable cause increases in latency or would it simply not connect to the camera at all?
the latency of the USB3 cameras is strictly related to the grabbing frequency.
As explained in the support page that you linked, the latency is caused by the USB3 controller, specifically by the buffering that it introduces. According to OS versions, the buffering can rise to 4 frames.
What is the frame rate that you are using?
That’s indeed the behavior of the SDK. When you call
grab the SDK retrieves the latest available frame in the buffer.
No, the ZED Cameras have no SW triggering capability.
Raising the frame rate will reduce the overall latency.
No, it would cause data loss, but latency would not be influenced.
Thank you for the info.
Is there a way to get the timestamp of when the sensor captured a frame (as opposed to it being available in the buffer).
sl.TIME_REFERENCE.IMAGE “Defines the timestamp at the time the frame has been extracted from USB stream.” However, as I understand from your post this timestamp has some variable latency of up to ~4 frames compared to the actual time the light hit the camera sensor.
Also does the SDK make the exposure time available? I imagine it’s useful to account for that time in checking for stale frames since the zed2i has rolloing shutter. The actual delay between the sensor starting an image capture and it being available from .grab is (latency + exposure time)?
We would have used it if it was possible
This information is not available. However exposure time is negligible with respect to buffering latency