Jetson 多相機掉幀怎麼查？GMSL、ROS 2 與 rosbag2 驗收流程

直接答案：先找出第一個開始掉資料的層

Jetson 多相機出現掉幀、延遲、畫面卡住或 rosbag2 漏資料時，先不要同時調時脈、QoS、cache 和 SSD。比較有效的順序是：

1. 每支相機單獨、用原生擷取路徑跑穩。
2. 固定解析度、FPS、pixel format、JetPack／L4T、驅動、載板與 SerDes 版本。
3. 一次增加一支相機，確認 CSI lane、GMSL virtual channel、frame counter 與錯誤日誌。
4. 原生擷取穩定後才加入 ROS 2 publisher、subscriber、RMW 與 QoS。
5. ROS 2 topic 穩定後才加入 rosbag2、cache、storage plugin、bag split 與目標 SSD。
6. 最後跑熱穩態、長時間、重啟、斷線和磁碟壓力測試。

核心判斷只有一個：上一層的輸入計數正常，哪一層的輸出第一次開始變少或延遲失控？ 找到這個邊界，才有資格調那一層的參數。

先下載驗收表，不要靠口頭記版本

本站整理兩個可重複使用的版本化資產：

• 下載 Jetson 多相機驗收 CSV：每次測試一列，適合試算表與交付紀錄。
• 下載 JSON 驗收結構：保存五層檢查、必要欄位與判讀限制，方便接到內部測試流程。

表中的範例列只是欄位示意，不是本站實測。請換成自己的模組、載板、相機、JetPack／L4T、ROS 2 distro、RMW、QoS、storage plugin、時長與計數。

第 1 層：感測器、SerDes、載板與供電

先證明單支相機能在目標硬體長時間輸出，再逐支增加。至少記錄：

• Jetson 模組、載板、相機型號與 sensor mode。
• CSI、GMSL 或 USB；serializer、deserializer、aggregator 與線材版本。
• 解析度、FPS、RAW10／RAW12／YUV／RGB／壓縮格式與實際封裝。
• CSI lane、virtual channel、I2C／proxy address 與 device tree 版本。
• 電源、相機啟動順序、溫度、錯誤計數與斷線回復。

NVIDIA 的 GMSL 文件以特定 AGX Orin 參考模組說明 virtual channel、SerDes 與 CSI 拓撲，也列出在 aggregator／ISP 組合下的最大連接數。這些數字只描述文件中的拓撲能力；不代表任意載板、任意相機與任意解析度／FPS 都能同時穩定串流。

同一件事也可能受版本影響。例如 Jetson Linux r36.4.4 release notes 對 Orin NX／Nano 的 CAM0 與特定 IMX219／IMX477 組合記錄了 sensor-id 條件。正式除錯前要先查你正在使用的 L4T release notes，不能只看最新論壇回覆。

這一層的通過條件

• 每支相機單獨通過固定時長與重啟次數。
• 逐支增加後，frame counter、CRC／CSI／SerDes 錯誤與時間戳沒有越過預先設定門檻。
• 拔線、重接或相機失效時，系統行為符合你的安全與回復設計。
• 完整保存 device tree、driver、韌體、載板與線材版本。

第 2 層：Argus、V4L2 與原生擷取

NVIDIA Jetson Linux r36.4.4 的相機架構文件把路徑分得很清楚：

先用和量產程式相同的 API 路徑做最小擷取測試，輸出到 fakesink 或記憶體，不要一開始就加入推論、ROS 2、編碼和寫檔。若最小路徑已失敗，往上加節點只會掩蓋根因。

NVIDIA 論壇有多相機 Argus timeout、daemon 卡住與無法回復的案例；案例能證明這類問題值得做長時間 create／destroy 與斷線測試，但不能證明所有版本或硬體都有同一缺陷。用你的 L4T、相機 partner driver 與可重現 log 向供應商確認。

這一層要留什麼證據

• 啟動命令、pipeline、API 與每支相機的 sensor mode。
• 每路預期 frame 數、實收 frame 數、時間戳間隔與最長停頓。
• dmesg、camera daemon／driver log、CPU／GPU／EMC、記憶體與溫度。
• 冷開機、服務重啟、session 重建與長時間循環結果。

第 3 層：ROS 2 publisher、DDS 與 QoS

原生擷取穩定後，才把影像送進 ROS 2。此時至少分開量：

1. 相機端產生多少 frame。
2. publisher 實際 publish 多少 message。
3. 測試 subscriber 收到多少、頻率與 message age 如何。
4. 是否有序列化、memory copy、executor、callback 或下游 subscriber 造成背壓。

ROS 2 官方文件指出，sensor data profile 傾向 best effort 與較小 queue，目的是優先拿到最新資料；publisher 與 subscriber 的 QoS 若不相容，甚至可能完全無法傳遞。把 QoS 改成 reliable 也不是萬靈丹：它可能增加重傳、排隊與等待。每次測試要記 reliability、durability、history、depth、RMW 與是否使用 intra-process／composition。

可以先用下列工具建立觀測，但命令輸出本身不是最終驗收：

ros2 topic info --verbose /camera/front/image_raw
ros2 topic hz /camera/front/image_raw
ros2 topic bw /camera/front/image_raw

ros2 topic hz 會增加一個 subscriber，也可能受主機與 QoS 影響。正式結果應由測試程式的 sequence／timestamp 計數與系統 trace 共同確認。

第 4 層：rosbag2、cache、切檔與儲存

只有 ROS 2 topic 已通過，才把 recorder 加進來。rosbag2 rolling 文件提供 events/rosbag2_messages_lost，能分開回報 transport 與 recorder 層的遺失；先用你的版本檢查是否支援：

ros2 bag record --help
ros2 bag record -a --stats_max_publishing_rate 1.0
ros2 topic echo /events/rosbag2_messages_lost

不同 ROS 2 distro／rosbag2 套件可能沒有相同選項，因此驗收表一定要保留版本。官方說明也指出，遺失事件是增量計數，而且沒有遺失的 topic 不會出現在事件裡；測試端要自行累加並和 publisher／bag 計數交叉比對。

GitHub issue #2108 描述一個 Jazzy 0.26.6、外接硬碟與較大 bag split 下漏資料的案例。它不是通用上限，但提醒我們：SSD 或介面的單次循序跑分，不能取代 rosbag2 在實際 cache、切檔、檔案系統與同時工作負載下的長時間測試。

這一層至少要測

• 目標 storage plugin、cache、compression 與 bag split 設定。
• 目標 SSD／外接儲存、檔案系統、剩餘容量與同時讀寫負載。
• 每個 topic 的發布數、錄入數、transport loss、recorder loss 與 bag metadata。
• 切檔瞬間、磁碟接近目標使用率、資料 offload 與服務重啟。
• 實際 replay 後的 topic 數、時間戳連續性與下游可用性。

第 5 層：整機熱穩態、故障與回復

前四層都過了，最後才測接近量產條件的整機：推論、編碼、網路、錄包、UI 與其他服務同時運作。驗收不能只跑一分鐘，至少覆蓋：

• 從冷機到熱穩態，包含可能的降頻。
• 最長預期連續班次或由風險分析設定的 soak test。
• 相機啟動順序改變、單路斷線、服務 crash、bag split 與磁碟壓力。
• 正常停止、強制重啟、電源中斷與版本回復。
• 發生異常時的降級、告警、人工接管與安全停止。

不要先訂一個跨專案通用的「0 掉幀」口號。先區分感知可容忍的 frame skip、訓練資料必須完整的 topic、控制 deadline 與安全訊號，再為每一類資料寫明允許值、量測方法與失敗後處置。安全相關訊號不應只依賴一般相機、ROS 2 topic 或 AI 模型承擔。

一張表看五層故障隔離

建議的最小驗收順序

1. 單支相機、原生 API、無編碼、無 ROS 2、無寫檔。
2. 相同設定逐支增加相機，保留每一步的已知正常版本。
3. 加入 ROS 2 publisher，再加一個最小 subscriber。
4. 固定 QoS 與 RMW，測 topic 計數、頻率、age 與系統負載。
5. 加入 rosbag2，先寫本機目標磁碟，再測 cache、split、compression。
6. 加入推論與完整整機服務，跑熱穩態與最長營運週期。
7. 測相機斷線、服務重啟、磁碟壓力與版本回復。

在開始前，可先用機器人感測器資料量計算器把 raw、實測 topic、持續寫入與保存容量換成同一組單位。那是容量預算，不是上述五層的穩定性證明。

最後的通過紀錄應能回答：哪個硬體與軟體版本、在什麼相機組合與負載下、跑了多久、預期多少資料、每一層實際收到多少、發生什麼錯誤、系統能否受控回復。 能回答這些，才算從「相機有畫面」走到可交付的多相機資料路徑。