Hi @sammeboy635
Welcome to the StereoLabs community.
Before the point by point answers, one honest premise: we do not publish a characterized timestamp jitter figure in the datasheets, so I will not invent numbers; what I can give you is exactly how the timestamps are generated, and the deterministic path to get an exposure referenced TOV in your GPS disciplined time base.
- What point in the frame pipeline does the SDK timestamp represent? Is it tied to exposure start, mid-exposure, or host-side frame delivery?
The value returned by getTimestamp(TIME_REFERENCE::IMAGE) is assigned by the host, not by the camera, in Epoch time with nanosecond resolution (Sensors Time Synchronization). It refers to the instant the complete frame is available in host memory, which on the GMSL2 path is within a few microseconds of the end of the exposure phase; it is neither exposure start nor mid-exposure. Note the distinction between the timestamp value and the delivery: the frame reaches your grab() about one frame period later because of buffering, but the timestamp still refers to the capture instant. This was discussed in depth here: ZedX Timestamps.
- For the ZED 2i over USB, what is the expected jitter between the true exposure moment and the SDK timestamp on Jetson Orin hardware? Is the camera clock correlated to the host clock, and if so, how?
There is no clock correlation mechanism to configure: the camera does not export a disciplined clock and has no PPS input, and all data, images and IMU, is timestamped on the host, so everything is already in the host time base. The bias and jitter come from buffering internal to the USB3 controller driver plus host scheduling, and we do not publish a characterized figure for this on Orin. Since timestamping accuracy is your primary decision factor, I would not recommend the ZED 2i for this specific requirement.
- For the ZED X over GMSL2, does the CSI path on Jetson result in a more deterministic timestamp than USB? Is the timestamp accuracy characterized anywhere for this configuration?
Yes, it is more deterministic: there is no USB controller in the path, and the residual delay is dominated by one frame of buffering in the Jetson ISP stack; we are addressing a known case where it randomly becomes two frames at SVGA and HD1080. It is not characterized in a public datasheet, but for your use case you do not need to rely on the software timestamp at all: the ZED Link capture cards expose a TRIG_OUT square wave on the GPIO connector whose rising edge is synchronized with the end of the exposure phase of the CMOS sensors (ZED Link Mono GPIO Triggering). Routing that pulse to a Jetson input and pairing pulse N with frame N, using getFrameDroppedCount() to detect drops, gives you an exposure referenced TOV directly in your KernelPPS disciplined time base.
One related point that matters with chrony in the loop: the default SDK timestamp clock is the wall clock, so you may prefer Camera::setTimestampClock(TIMESTAMP_CLOCK::MONOTONIC_RAW_CLOCK) (ZED SDK 5.4) to get image and IMU timestamps immune to both NTP/PTP step and frequency adjustments. If you want to stay in Epoch time, Camera::setMaxSystemClockStepMs() controls how fast the SDK follows backward host clock adjustments, and a negative value applies the correction immediately.
- Given the ZED 2i uses a rolling shutter, does the SDK timestamp refer to a specific row, the start of the scan, or some other reference point?
The SDK exposes a single timestamp per frame and does not expose a per row reference, and the row dependent skew of the rolling shutter is not characterized. On a moving vehicle this residual is a real, unrecoverable error source through the API, which is why for precision navigation I recommend the ZED X: both sensors use an electronically synchronized global shutter, so the whole frame shares one exposure interval and a single timestamp is physically meaningful.
- What is the typical latency and variance between IMU sample timestamps and the corresponding image frame timestamp for each camera?
The camera and the IMU share a common low drift reference clock and the same host time base, so image and IMU timestamps are directly comparable with no offset estimation needed. Using getSensorsData(sensors_data, TIME_REFERENCE::IMAGE) you get the sample closest to the frame, so the residual is bounded by half the IMU period: about 1.25 ms with the 400 Hz IMU of the ZED 2i, and about 2.5 ms with the ZED X IMU, whose rate is standardized at 200 Hz with ZED X Driver 1.4.0 and newer. If you need finer alignment, getSensorsDataBatch() returns all the high frequency samples associated with the last grabbed frame, so you can interpolate exactly at the image timestamp.
Summary for your application: for a precision agricultural platform fusing RTK and vision, the ZED X on a ZED Link Mono capture card is the configuration I would pick, for the global shutter, the deterministic GMSL2 capture path, the TRIG_OUT exposure signal, and the IP67 enclosure. Please also have a look at the GNSS/RTK setup and Data Synchronization pages of the Global Localization module, since the ZED SDK already handles the GNSS to camera time alignment for you.
Capture card documentation is here: ZED Link Capture Card, and the cameras are available in the official store.