Bug: Frame timestamps use an arbitrary steady_clock epoch
Current behaviour
src/main.cc sets timestamp_ns from std::chrono::steady_clock::now().time_since_epoch() and attaches it to image_bgr and objects.
steady_clock's epoch is unspecified by the C++ standard and typically counts from an
arbitrary point such as process start or system boot. The published value therefore
cannot be compared against another node's timestamps, against wall clock, or against a
recording. It also does not represent when the frame was captured, only when the node
processed it.
Expected behaviour
Timestamps identify when the frame was captured by the device and can be correlated
across nodes and with recorded sessions.
Requirements
Publish the device capture time from sl::Camera::getTimestamp(sl::TIME_REFERENCE::IMAGE).
Publish a host wall-clock time from std::chrono::system_clock, in nanoseconds since the Unix epoch.
Use distinct, unambiguous metadata keys for the two values.
Attach both to every output: image_bgr, depth, camera_info and point_cloud.
Document both keys in README.md, stating unit and epoch.
Acceptance Criteria
Every output carries a device capture timestamp and a host wall-clock timestamp.
The wall-clock value matches date +%s%N on the host at capture time.
Two nodes receiving the same frame report the same device capture timestamp.
README.md documents unit and epoch for both keys.
Notes
Downstream session recording aligns camera frames against robot telemetry and audio, so
a timestamp that cannot be related to wall clock cannot be used for dataset export.
Both values are needed: the device timestamp is the correct capture instant, while the
host timestamp is what other nodes and the recorder share. On a Jetson the wall clock can
step when NTP synchronises after boot, which is why the device timestamp must be recorded
alongside it rather than replaced by it.
# Bug: Frame timestamps use an arbitrary steady_clock epoch
## Current behaviour
`src/main.cc` sets `timestamp_ns` from
`std::chrono::steady_clock::now().time_since_epoch()` and attaches it to `image_bgr` and
`objects`.
`steady_clock`'s epoch is unspecified by the C++ standard and typically counts from an
arbitrary point such as process start or system boot. The published value therefore
cannot be compared against another node's timestamps, against wall clock, or against a
recording. It also does not represent when the frame was captured, only when the node
processed it.
## Expected behaviour
Timestamps identify when the frame was captured by the device and can be correlated
across nodes and with recorded sessions.
## Requirements
- Publish the device capture time from `sl::Camera::getTimestamp(sl::TIME_REFERENCE::IMAGE)`.
- Publish a host wall-clock time from `std::chrono::system_clock`, in nanoseconds since the Unix epoch.
- Use distinct, unambiguous metadata keys for the two values.
- Attach both to every output: `image_bgr`, `depth`, `camera_info` and `point_cloud`.
- Document both keys in `README.md`, stating unit and epoch.
## Acceptance Criteria
- [ ] Every output carries a device capture timestamp and a host wall-clock timestamp.
- [ ] The wall-clock value matches `date +%s%N` on the host at capture time.
- [ ] Two nodes receiving the same frame report the same device capture timestamp.
- [ ] `README.md` documents unit and epoch for both keys.
## Notes
Downstream session recording aligns camera frames against robot telemetry and audio, so
a timestamp that cannot be related to wall clock cannot be used for dataset export.
Both values are needed: the device timestamp is the correct capture instant, while the
host timestamp is what other nodes and the recorder share. On a Jetson the wall clock can
step when NTP synchronises after boot, which is why the device timestamp must be recorded
alongside it rather than replaced by it.
cristhian
added this to the v0.2.0 Pure camera source on dora 1.0 milestone 2026-09-04 20:35:58 +00:00
cristhian
added the bug label 2026-09-04 20:35:58 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Bug: Frame timestamps use an arbitrary steady_clock epoch
Current behaviour
src/main.ccsetstimestamp_nsfromstd::chrono::steady_clock::now().time_since_epoch()and attaches it toimage_bgrandobjects.steady_clock's epoch is unspecified by the C++ standard and typically counts from anarbitrary point such as process start or system boot. The published value therefore
cannot be compared against another node's timestamps, against wall clock, or against a
recording. It also does not represent when the frame was captured, only when the node
processed it.
Expected behaviour
Timestamps identify when the frame was captured by the device and can be correlated
across nodes and with recorded sessions.
Requirements
sl::Camera::getTimestamp(sl::TIME_REFERENCE::IMAGE).std::chrono::system_clock, in nanoseconds since the Unix epoch.image_bgr,depth,camera_infoandpoint_cloud.README.md, stating unit and epoch.Acceptance Criteria
date +%s%Non the host at capture time.README.mddocuments unit and epoch for both keys.Notes
Downstream session recording aligns camera frames against robot telemetry and audio, so
a timestamp that cannot be related to wall clock cannot be used for dataset export.
Both values are needed: the device timestamp is the correct capture instant, while the
host timestamp is what other nodes and the recorder share. On a Jetson the wall clock can
step when NTP synchronises after boot, which is why the device timestamp must be recorded
alongside it rather than replaced by it.