fix(libcamera): publish mid-exposure timestamp - #2489
Open
JosephTLockwood wants to merge 1 commit into
Open
Conversation
SensorTimestamp marks start-of-exposure. The scene a detector integrates over spans [SOE, SOE+exposure], so mid-exposure is the closest single-instant approximation. Add exposure/2 to the published timestamp using the new getFrameExposureTimeUs JNI call; falls back to SOE when the driver returns 0. Depends on PhotonVision/photon-libcamera-gl-driver#33.
github-actions
Bot
added
documentation
4 tasks
gerth2
reviewed
Aug 20, 2026
| // is the closest single-instant approximation. When the driver | ||
| // returns 0, ExposureTime metadata was unavailable for this frame | ||
| // and we leave the timestamp uncorrected. | ||
| long midExposureCorrectionNs = exposureUs > 0 ? (exposureUs * 1000L) / 2L : 0L; |
Contributor
There was a problem hiding this comment.
What conditions lead to exposureUs being less than zero? Or zero?
Contributor
There was a problem hiding this comment.
https://docs.libcamera.org/master/public-api/namespacelibcamera_1_1controls.html#a4e1ca45653b62cd969d4d67a741076eb makes no mention of what happens when "metadata is unavailable or this frame" - the comment states what the expected behavior of libcamera is but I'm not sure I concur.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
PhotonVision's libcamera path currently publishes the start-of-exposure timestamp from
libcamera::controls::SensorTimestampdirectly. The scene a detector integrates over spans[SOE, SOE+exposure], so the closest single-instant approximation is the midpoint of that window. The existing e2e-latency design doc already acknowledges this residual ("sensor will remain collecting light for up to the total integration time").Magnitude at typical FRC exposures (~5–15 ms): a 2.5–7.5 ms earlier-bias is removed, which is ~12–37 mm of pose error at 5 m/s drive speed.
What
LibcameraGpuFrameProvider: readgetFrameExposureTimeUsand addexposure/2(ns) to the published timestamp.0(libcamera did not populateExposureTimefor the frame), the correction is skipped and behaviour matches today.e2e-latency.md: documents the new behaviour and the rolling-shutter caveat.Dependency
Requires PhotonVision/photon-libcamera-gl-driver#33 (the paired JNI surface). That PR must merge and a driver release that bumps
libcameraDriverVersioninbuild.gradlemust land before this PR compiles against the upstream Maven artifact. Local smoke build was verified with./gradlew publishToMavenLocalon the driver branch.Scope notes
driver-returns-0fallback already covers the unsupported-sensor case, so a config toggle would be redundant.