JETSON / ROS 2 EVIDENCE
多相機有畫面，不代表資料真的同步
把時鐘來源、同步方法、五個資料層的計數、最大偏差與重播結果留在同一份紀錄。空白與未測不會被當成 0 或通過。
VERSION 1.1 · 2026-09-17
建立一筆可追查的同步測試紀錄
FIVE LAYERS
哪一層先少一筆，才是你要追的邊界
| 層 | 核心問題 | 不能替代它的證據 |
|---|---|---|
| 擷取 | 硬體 frame number、sensor timestamp 是否連續？ | ROS 2 topic 看起來有更新 |
| 發布 | publisher 發了幾筆，stamp 寫的是哪個時鐘？ | 平均 FPS 接近目標 |
| 配對 | 實際配成幾組，最大偏差是多少？ | 三個 topic 使用同一名稱格式 |
| 錄製 | rosbag2 留下幾筆，transport／recorder loss 如何？ | SSD 跑分或檔案有變大 |
| 重播 | 重播後的順序、stamp 與關聯仍可用嗎？ | 錄製時沒有報錯 |
TIMESTAMP LADDER
一個「總延遲」數字，找不到慢在哪一段
如果裝置能提供多個可比較的硬體／主機時間戳，請保存原始時標，再分段相減。NVIDIA Holoscan Sensor Bridge 的範例就是把 frame start、frame end、CPU received、pipeline operator 與 completed 分開；這個方法可借來設計紀錄，但官方範例的數值不能外推成你的 Jetson、相機或網路表現。
| 時標／區段 | 回答的問題 | 常見誤判 |
|---|---|---|
frame_start → frame_end | 感測器把一幀資料送入接收端花多久？ | 把 rolling shutter 讀出時間當成主機處理延遲 |
frame_end → received | 資料完成後，到 CPU／receiver 被喚醒花多久？ | 只量 ROS callback，漏掉傳輸與中斷等待 |
received → operator | 資料可用後，到 pipeline 真正排程執行花多久？ | 把 scheduler／queue 等待算成模型推論時間 |
operator → completed | 其餘處理、推論或顯示完成花多久？ | 用平均值掩蓋 p95／最大值與偶發停頓 |
SOURCES & DEMAND SIGNAL
來源怎麼用
NVIDIA Isaac ROS 的 Thor 多相機組裝指南提供一個三台 RealSense、以主相機 sync pulse 驅動其他相機的硬體同步範例；它不是所有相機或 Jetson 組合的相容保證。ROS 2 官方文件則說明 QoS profile 可能不相容而完全收不到訊息。Orbbec ROS 2 文件把 hardware frame number、sensor／device／system timestamp、arrival／publish delta 與 SDK／ROS 掉幀分開記錄，適合作為欄位設計參考。
NVIDIA 論壇反覆出現「三相機頻率不穩、不同步、掉 frame，且要和 joint states 對齊」的問題；論壇是需求與故障訊號，不是規格或通用解法。