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、時長與計數。

如果問題是「三路影像到底有沒有對齊」，請改用 Jetson 多相機時間同步驗收紀錄器。它會把時鐘來源、同步方法、時間戳代表時刻、擷取／發布／配對／錄製／重播計數，以及最大跨感測器偏差分開保存；也可直接下載 CSV 空白範本 與 JSON schema。這些仍是紀錄方法，不是本站對任一相機或 Jetson 組合的通過結論。

如果是「topic 列得出來，但 RViz、自己的 subscriber 或 recorder 收不到」，先看下方的 ROS 2 QoS 無影像排查，不要直接當成相機硬體掉幀。

如果收到第一張影像後就卡住，或推理結果越來越舊，接著看 callback／executor 卡住分流。QoS 相容和回呼能準時完成，是兩個不同檢查。

先分清楚四種常被混在一起的「同步」

NVIDIA Isaac ROS 4.1 提供一個 Jetson Thor 搭配三台 RealSense、以主相機 sync pulse 驅動其他相機的硬體組裝範例。這能證明「硬體同步需要額外接線、主從關係與明確架構」，但不能外推成所有 USB、GMSL 或 CSI 相機都支援相同方法。Orbbec ROS 2 文件則把 hardware frame number、sensor／device／system timestamp、arrival／publish delta 與 SDK／ROS 掉幀分開記錄；這正是驗收表不能只留一個平均 FPS 的原因。

如果還要判斷「同步但反應很慢」，應把 latency 拆成時標階梯。NVIDIA Holoscan Sensor Bridge 文件把 frame start、frame end、CPU received、pipeline operator 與 completed 分開，才能區分感測器讀出、傳輸／中斷、排程等待與後續處理。這是量測方法參考，不是 Jetson 通用效能數字；跨主機或跨裝置相減前，還要先證明時鐘域可比較。ROS 2 ApproximateTime 只依訊息 header timestamp 與 slop 配對，不能代替硬體曝光同步或 sensor-to-display 量測。

RealSense SDK 2.58.4 beta：先查時鐘域與資料路徑，再談同步或零拷貝

RealSense 在 2026-08-30 發布的 SDK 2.58.4 beta 增加裝置硬體時鐘與 Jetson GPU frame API，也列出 Ubuntu 26.04／ROS 2 Lyrical 支援。這些是 SDK 的功能與相容性聲明，不是本站在指定相機、載板、ROS wrapper 上的實測。若你正排查多相機時間對齊或主機到 GPU 的拷貝，先把下列條件與證據分開：

手機上可左右滑動表格，讀完第三欄的驗收限制。

這張表是 官方 API 變更與 release 條件的閱讀檢查表，不是效能比較或相容認證。先在原生 SDK 留下 frame counter、device time、host arrival 與 GPU 路徑紀錄，再把相同版本的 ROS 2 topic、bag 與回放結果接回本站的多相機時間同步驗收紀錄器；不要從新版 API 名稱反推現場的時間同步、低延遲或安全性。

第 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。

如果要把多相機、IMU 或 joint_states 配成同一個樣本，還要另外記錄：每個 publisher 的 stamp 來源、ExactTime／ApproximateTime 或自訂配對規則、允許偏差、配對成功數與未配對數。NVIDIA 論壇的三相機案例反覆出現頻率不穩、不同步、掉 frame 與 joint states 對齊問題；它是「這些欄位值得留下」的真人需求訊號，不是官方規格或通用參數答案。

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

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 共同確認。

ROS 2 topic 看得到卻收不到影像：先排除 QoS 不相容

topic 被發現，不代表 publisher 和每個 subscriber 已建立可傳訊的連線。 QoS 像寄件者能提供的配送方式與收件者的最低要求：寄件者只提供盡力配送，收件者卻要求可靠配送，這一對就不相容。先核對兩端的實際設定，再談影像 FPS、硬體頻寬或加大 queue。

下表依 ROS 2 Humble 的官方 QoS 文件整理，只判斷 reliability 這一項；不是端到端通過證明：

手機可左右滑動表格。兩端不必每個值完全相同，但所有影響相容性的政策都要通過。

例如 reliability 相容，但 publisher 是 volatile、subscriber 要求 transient local，仍然不相容。deadline、liveliness 等也要一起看；SYSTEM_DEFAULT 則取決於 RMW，不能只憑 profile 名稱猜現場數值。

先做三個排查，再決定要改哪一端

1. 確認端點與訊息型別。 用 ros2 topic info --verbose 留下每個 publisher／subscriber 的節點、型別、reliability、durability、history 與 depth。比較出問題的實際端點，不只看 topic 名稱或 camera launch 檔。
2. 用短暫、明確 QoS 的 subscriber 隔離。 下例只在獨立測試環境觀察一筆帶 header 的影像訊息。先查本機 --help，再替換成自己的 topic；若沒有收到，手動停止，不要把觀察程式一直留在正式管線。
3. 分開比對影像與配對所需 topic。 RealSense wrapper 的 color_qos／depth_qos、<stream_type>_info_qos（camera_info 與 metadata）、pointcloud.pointcloud_qos 是不同設定。影像有資料但 camera_info、IMU 或配對輸入沒有，不能靠只改 depth_qos 就宣稱整條路修好。

ros2 topic info --verbose /camera/front/image_raw
ros2 topic echo --help
ros2 topic echo /camera/front/image_raw \
  --qos-reliability best_effort \
  --qos-durability volatile \
  --field header --once

這組 echo 選項已核對 Humble 官方原始碼，沒有在本站的 Jetson／相機硬體執行。它不修改 publisher，也不證明持續吞吐或同步正確；不同 distro／套件版仍以本機 help 為準。CLI 自動選擇的 QoS 也不能代替 RViz、你的程式或 recorder 的實際設定。

Humble 的 topic hz 原始碼使用 sensor data QoS 建立 subscriber，輸出是該觀察端的接收頻率。不是每個 distro 都能用相同旗標覆寫它；也不要把 CLI 的結果外推成 camera、RViz 和 rosbag2 都收到同樣資料。重新驗收時，一次只改一個端點或政策，保存原設定與失敗 log，再把計數、時間戳及限制帶回時間同步驗收紀錄器。可靠傳輸、時間同步、低延遲與安全停止仍是不同驗收項目。

本節於 2026-10-01 核對 ROS 2 Humble 文件／CLI 原始碼及 RealSense wrapper 文件。其他相機規格與 SDK 段落保留原查證日期；本節不是硬體實測或通用參數處方。

ROS 2 收到影像後卡住：多執行緒不會自動解除 callback 互斥

先分清「互相等待」「同組排隊」與「處理速度不足」，不要只增加 executor 執行緒或 queue 深度。 Callback group 像工作室的門禁：即使有多名工人，同一個互斥房間仍一次只准一人進去。ROS 2 Humble 預設的 group 是 MutuallyExclusive；同一節點全部沿用它，換成 MultiThreadedExecutor 仍不能讓這些回呼彼此並行。

手機可左右滑動這張分流表；三欄要一起判讀，不能只套用中間欄的調整。

留下三組證據，再重測一個變因

1. 設定與等待關係： 保存 ROS 2 distro／套件版、rclpy 或 rclcpp、executor 執行緒、各端點 group，以及在哪個回呼等哪個結果。沒有例外訊息，不能排除 deadlock。
2. 開始、結束與資料新鮮度： 分開記回呼開始／結束、輸入與完成計數、可比較時鐘下的 message age。耗時可用單調時鐘；不能直接拿它減不同時間域的 header.stamp。
3. 修改前後的同條件紀錄： 一次只改等待方式或 group 配置，核對結果完整性、逾時回復與共享資源。CPU／GPU 使用率或 topic hz 單一數字，不能代替這組證據。

本節於 2026-10-06 核對 ROS 2 Humble 官方文件定點原始碼。分流表與有界佇列建議是本站工程判讀，未執行 ROS 範例或 Jetson／相機硬體實測；其他段落保留原查證日期。模型回呼恢復不代表機器人安全控制已通過。

第 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 層：整機熱穩態、故障與回復

冷機正常、持續負載才掉幀時，先看Jetson 功耗模式、tegrastats 與降頻判讀。這是觀察與隔離方法，不是要求切換 MAXN 或停用熱保護，也不是本站已量到你的硬體瓶頸。

前四層都過了，最後才測接近量產條件的整機：推論、編碼、網路、錄包、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、持續寫入與保存容量換成同一組單位。那是容量預算，不是上述五層的穩定性證明。

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