エッジAI on Physical AI Hub

自律ドッキングの実装設計：位置合わせ・接近制御・充電接続を分解する

Sun, 01 Nov 2026 14:47:08 +0900

自律ドッキングは、接触できたかどうかだけでは成功を判断できない点が設計上の要所です。

先に結論

ロボットの自律ドッキングでは、不確実性を一度に解消しようとせず、段階的なゲートとして扱うのが基本です。まず地図と自己位置推定を使って充電ステーション周辺のステージング地点へ移動し、次にドックに対する相対位置と姿勢を精密化します。その後、低速で接近し、接触またはドッキング状態を確認してから、最後に電気的な充電成立を検証します。

「ドックへ到達した」と「充電できている」は同じ状態ではありません。したがって、成功条件は物理接触だけでなく、許容姿勢、停止状態、ドック状態、充電状態、タイムアウトを個別に評価する設計が適しています。条件を満たせない場合は前進を続けず、停止または後退、再位置推定、制限回数内の再試行、最終的な異常通知へ遷移させます。

なぜ段階分けが必要か

充電ステーションまでの移動は、通常のナビゲーションが得意とする問題です。一方、接触直前の位置合わせでは、地図上の自己位置だけでは扱いにくい局所的な誤差や、ドック設置位置のずれが問題になります。そのため、ステージング地点を境に、地図・大域自己位置推定からドック固有の相対センサーへ重心を移します。

さらに、接触したように見えても、端子の位置ずれや接続状態によって充電が成立しない可能性があります。ドッキング判定と充電判定を分離すれば、ロボットが物理的には停止しているものの、充電できていない状態を検出できます。

前提となる用語

大域自己位置推定：地図上でロボットがどこにいるかを推定する機能。ステーション周辺までの経路走行に使います。
ステージング地点：ドック固有の近距離処理へ切り替えるための待機位置です。
相対位置・姿勢推定：ロボットから見たドックの距離、横方向のずれ、向きなどを推定する処理です。
ドッキング判定：物理的にドックへ到達し、所定の姿勢や停止条件を満たしたかを確認する処理です。
充電判定：ドックとの電気的な接続が成立し、充電状態になったかを確認する処理です。

内部の仕組み：不確実性を順にゲート化する

代表的な構成は、通常のナビゲーションでステージング地点へ移動し、その後にドック固有の処理を実行する段階構成です。汎用フレームワークでは、ステージング位置の取得、相対位置の精密化、最終接近、ドッキング状態、充電状態を別々の処理として設計できます。一方、組み込み型ロボットでは、これらが一つのDockアクションに隠蔽されることもあります。抽象化の違いであり、段階的に確認する考え方と矛盾しません。

相対位置推定に使うセンサーは一つに決まりません。実装に応じて、赤外線、カメラ、レーザー・距離センサー、LiDAR、接触センサーなどが候補になります。重要なのは、センサー名を先に固定することではなく、各段階で何を観測し、どの状態を確定させるかを明確にすることです。

flowchart LR
  A["ステーション同定・大域自己位置推定"] --> B["ステージング地点へ移動"]
  B --> C["ドック相対座標系へ切り替え"]
  C --> D["相対位置・姿勢を精密化"]
  D --> E["低速接近"]
  E --> F["接触・ドッキング状態を検証"]
  F --> G["充電状態を検証"]
  G --> H["ドッキング成功"]

  B -->|"到達不可・タイムアウト"| R["停止または再位置推定"]
  D -->|"姿勢誤差・観測不安定"| S["停止または後退"]
  E -->|"障害物・異常接触・タイムアウト"| S
  F -->|"停止・姿勢・ドック状態が未成立"| T["後退して制限回数内で再試行"]
  G -->|"充電未成立・タイムアウト"| T
  S --> R
  T -->|"再位置推定後"| C
  T -->|"再試行上限超過"| U["異常通知または遠隔介入"]
  R -->|"復旧可能"| B

大域自己位置推定からドック相対位置合わせへ段階的に切り替え、ドッキングと充電を分離して検証する制御フロー。

図では、ステーションの同定と大域移動から始め、ステージング地点でドック基準の相対座標へ切り替えます。相対位置・姿勢を確認した後に低速接近し、接触・ドッキングを検証します。最後に充電状態を確認し、途中で条件を満たせなければ後退または再位置推定へ戻ります。

ロボットの電力制約をタスク計画へ反映する：3層設計の考え方

Wed, 14 Oct 2026 13:39:56 +0900

電池残量を計画に組み込むとき、どこまで細かくモデル化すべきかが設計上の焦点になります。

結論

ロボットの電力制約は、単一の計画器に集約せず、タスク割り当て、経路・作業単位のエネルギー計画、実行時の再計画という3層に分けて設計するのが妥当です。上位層では、タスクの消費量だけでなく、終了後に充電地点や待機地点へ戻るエネルギー、充電時間、安全余裕を含めて実行可能性を判断します。中位層では、距離だけでなく速度、加減速、勾配、床面、積載量、停止回数、センサーなどの補機負荷を区間ごとに見積もります。下位層では、SOC、電流、温度、実測消費を取り込み、予測との差に応じて計画を更新します。

SOCや残量パーセントだけでタスクを選ぶと、残量表示は十分でも帰還できない、負荷変動で作業途中に停止する、といった問題を扱いにくくなります。一方、すべてを高精度な電池モデルで計画する必要もありません。機体や運用環境に応じて、上位は粗く、中位は必要な作業単位で、下位は実測に反応できる粒度に分けることが判断の基本です。

なぜ残量表示だけでは不十分か

ROS 2のBatteryStateメッセージは、電圧、電流、充電量、容量、設計容量、残量パーセント、電源状態、健全性、セル電圧などを扱います。計画器が参照する電池状態も、SOC単独ではなく、利用可能容量や電源状態、健全性を含む状態ベクトルとして定義できます。

ただし、SOCは直接観測する値ではありません。クーロンカウント、電圧、電流、電池モデルなどを組み合わせて推定され、電池モデルと拡張カルマンフィルタを用いる方法もあります。負荷条件やモデル誤差によって推定値は変わるため、SOCをそのまま「今後使えるエネルギー」とみなすのは危険です。百分率、正規化容量、実容量、利用可能容量は実装によって意味が異なる場合もあります。

3つの計画粒度

1. タスク割り当て層

搬送や巡回などのタスクをどのロボットに割り当てるかを決める層です。判定には、タスクそのものの予測消費量、終了後の帰還エネルギー、充電に要する時間、予測誤差を吸収する安全余裕を含めます。

「SOCが閾値以上なら割り当てる」という方式では、帰還経路や充電待ち時間を評価できません。複数台を運用する場合は、充電器の競合や代替ロボットの有無も判断材料になります。Open-RMFでは、フリートの状態、走行、タスク、充電を運用モデルの一部として扱い、電池容量、消費、充電、状態変化を扱う関連パッケージも提供されています。

2. 経路・作業単位のエネルギー計画層

タスクを経路や作業区間に分け、各区間のエネルギーコストを予測します。距離または時間に比例させるモデルは実装しやすい一方、速度、加減速、勾配、床面、積載量、停止回数、センサーやマニピュレーターの負荷を表現しにくい制約があります。

移動ロボットの運動計画では、距離や時間だけでなくエネルギー消費を目的関数に含める考え方があります。最短経路と最小エネルギー経路は一致しない場合があるため、経路評価を距離だけに固定しないことが重要です。環境と負荷が安定しているなら距離・時間比例モデルから始め、影響が大きい条件を実測データや電池モデルで段階的に追加します。

3. 実行時制御・再計画層

タスク開始時に電力計画を固定すると、実際の電流、温度、積載状態、路面が予測と異なった際に破綻します。実行層では、現在のSOC、電流、温度、実測消費を取り込み、残タスク、経路、充電判断を再評価します。

再計画の契機は、実測消費が予測を上回った、帰還用リザーブを下回る見込みになった、充電器の利用状況が変わった、といった状態変化です。下位層は安全停止や低電力動作への移行を担い、上位層はタスク中断、再割り当て、充電後の再開を担うように責務を分けます。普遍的な再計画周期は確認できないため、機体の応答性と予測誤差に合わせて決めます。

flowchart LR
  S["電池・運用状態"] --> A
  A["タスク割り当て層\nタスク、充電、帰還余裕、予測誤差を評価"] --> B
  B["経路・作業単位のエネルギー計画層\n速度、加減速、勾配、床面、積載量、補機負荷を考慮"] --> C
  C["実行時制御・再計画層\nSOC、電流、温度、実測消費を短周期で監視"]
  C --> D["実行・走行・作業"]
  D --> E["実測値と予測誤差"]
  E --> C
  C -->|"帰還余裕低下・予測超過・充電状況の変化"| A
  A --> F["充電または待機の判断"]
  F --> G["充電後のタスク再開・再割り当て"]
  G --> A

タスク割り当て層は充電と帰還余裕を含めて仕事の実行可能性を判断し、経路・作業層は区間エネルギーを予測し、実行層は実測値と予測誤差を使って再計画します。

図では、タスク割り当て層が充電と帰還余裕を含めて仕事を選び、経路・作業層が区間エネルギーを予測し、実行層が実測値で予測を更新する循環を示します。

設計方式の比較

方式	主な入力	長所	制約
残量パーセント中心	SOC、電源状態	実装と監視が容易	負荷、温度、劣化、帰還エネルギーを表しにくい
状態ベクトル中心	電圧、電流、SOC、容量、健全性など	電池状態を多面的に扱える	推定誤差と各項目の定義管理が必要
距離・時間比例モデル	距離、走行時間	初期実装が簡単	速度、勾配、積載、補機負荷への対応が限定的
物理・電池モデル	電流、電圧、温度、負荷	条件変化を反映しやすい	モデル化と校正のコストが高い
実行時再計画	実測消費、SOC、残タスク	予測ずれに対応できる	再計画の契機と安全動作が必要

充電判断と実装の進め方

最初の実装では、タスクごとのエネルギー予算、帰還用リザーブ、充電開始条件、緊急停止または低電力モードへの移行条件を分離すると扱いやすくなります。これらを1つの閾値にまとめると、通常の充電判断と安全上の限界が混同されます。まず距離や作業時間から予算を置き、実測データでモデルを校正する構成が現実的です。

ロボットAIの電力・熱設計：長時間運用で推論性能を安定させる監視方法

Sun, 27 Sep 2026 14:06:14 +0900

短時間のベンチマークで良好に見えるロボットAIが、長時間運用でも同じ応答性を保てるとは限りません。

先に結論

Jetsonなどのエッジ計算機を搭載したロボットでは、平均FPSだけで長時間運用の安定性を判断してはいけません。温度、電力、CPU・GPU・メモリ帯域の利用率と周波数、アプリケーション遅延を同じ時系列で記録し、p95・p99遅延、最大遅延、期限超過率、キュー長を重視します。

温度上昇や電力制約と実効クロック低下が、p99遅延の増加と同時に起きていれば、熱または電力に起因する性能低下を疑います。温度やクロックが安定しているのにキューだけが伸びる場合は、CPU競合、メモリ帯域、I/O、前処理・後処理などを追加で調べます。状態が悪化したときは、推論レート、処理対象フレーム、入力解像度、モデル品質を段階的に下げる閉ループ制御が有効です。

なぜ長時間の監視が必要か

短時間のベンチマークは、起動直後の温度や一時的な冷却条件を反映します。一方、実際のロボットでは筐体や周囲の温度、電力モード、センサー入力、制御処理などが時間とともに変化します。Jetsonの熱管理機構は温度センサー、thermal zone、冷却デバイス、トリップポイントを使い、条件に応じて周波数制御やスロットリングを行うことがあります。

そのため、瞬間的な推論時間やFPSだけでは制御周期を守れるか分かりません。安全制約や周期処理を持つシステムでは、平均値よりも遅延分布の上側を見ます。p99遅延、最大遅延、期限超過率、連続した欠落フレーム数の許容値は、対象ロボットの制御仕様と安全要求から決めます。製品、冷却方式、筐体条件が異なるため、温度や電力の一律な閾値は設定できません。

監視するメトリクス

Jetsonのシステム状態は、tegrastatsで一定間隔に取得できます。RAM、SWAP、CPU・GPU・EMCなどの利用率と周波数、温度、電力情報が対象です。電力監視ではVDD_INなどの入力・レール単位の値を利用できますが、利用可能なセンサー名や値の意味は、モジュール、キャリアボード、ソフトウェア設定によって異なります。VDD_INがモジュール入力だけを示すのか、キャリアボードや周辺機器を含むのかは、対象機の回路構成とセンサー実装を確認してください。

温度の調査では、tegrastatsの温度値に加えてthermal sysfsを確認します。Linuxのthermal frameworkは、thermal zoneの温度、冷却デバイス、トリップポイントをsysfs経由で公開します。これにより、単に温度が高いかだけでなく、温度管理機構の状態を確認できます。

推論レイテンシはtegrastatsだけでは測れません。アプリケーション側で、入力受付、キュー待ち、前処理、推論、後処理、出力にタイムスタンプを付け、p50・p95・p99、スループット、期限超過率、キュー長を記録します。NVTXの範囲を付ければ、Nsight SystemsでCPU・CUDA・GPUのタイムラインと処理区間を対応付けられます。

flowchart TB
  S["同じ時刻軸で記録"]
  S --> T["温度センサー・thermal zone"]
  S --> P["利用可能な電力センサー\n例: VDD_IN"]
  S --> C["CPU・GPU・メモリ帯域の利用率と実効クロック"]
  S --> M["RAM・SWAP"]
  S --> A["入力受付から出力までのアプリケーション区間"]
  A --> Q["キュー待ち・前処理・推論・後処理・出力"]
  Q --> L["p95・p99・最大遅延\n期限超過率・キュー長・欠落フレーム"]
  T --> R["時間相関を確認"]
  P --> R
  C --> R
  L --> R
  R --> H{"温度上昇・クロック低下・遅延増加が重なるか"}
  H -->|"はい"| X["熱または電力制約の候補として調査"]
  H -->|"いいえ。キューだけ増加"| Y["CPU競合・メモリ帯域・I/O・前後処理を追加調査"]

温度、電力、実効クロック、キュー長、p99遅延などを同じ時系列に置くと、熱・電力制約とソフトウェア要因を切り分けやすくなります。VDD_INなどの電力値は、対象モジュールや回路構成に応じて測定範囲を確認します。

指標と取得手段の比較

指標・手段	主な対象	用途	注意点
tegrastats	温度、利用率、周波数、RAM・SWAP、電力	長時間の状態監視	製品やボードで項目が異なる
thermal sysfs	thermal zone、冷却デバイス、トリップポイント	熱制御とスロットリングの調査	対象機でセンサー構成を確認する
アプリ計測	キュー、前処理、推論、後処理、出力	エンドツーエンド性能の評価	推論単体の値とは一致しない
Nsight Systems	CPU・CUDA・GPUのタイムライン	競合や遅延区間の原因分析	常時監視より詳細調査向け
p95・p99遅延	遅延分布の上側	制御周期の評価	平均値だけでは見えない遅延を捉える

電力モードとクロック設定

nvpmodelはJetsonの電力モードを選択し、jetson_clocksはCPU、GPU、EMCなどのクロックを制御します。性能評価時と実運用時の設定を明示し、異なる条件の結果を混同しないことが必要です。

ロボット推論をエッジとクラウドに分担させる設計判断

Sun, 20 Sep 2026 23:22:26 +0900

ロボットのクラウド利用は、計算資源の問題だけでなく、通信が途切れた瞬間の振る舞いまで含めて考える必要があります。

先に結論

ロボットのクラウド推論は、通信遅延や切断が起きても安全性と制御性能を損なわない、非同期・非安全系の処理に限定するのが基本です。アクチュエータの最終制御、緊急停止、衝突回避の最終判断、ウォッチドッグ、最低限の状態推定はロボット上に残します。一方、学習、ログの再処理、フリート分析、モデルや地図の配布、遅延を許容できる高位計画はクラウドと相性がよい領域です。

クラウドを制御ループの一部に使う場合は、単に平均遅延を測るだけでは不十分です。許容遅延、ジッター、結果の有効期限、タイムアウト、通信断時の動作、古い結果の破棄条件、ローカルフォールバックをタスクごとに定義し、故障時の挙動まで検証する必要があります。

なぜ配置の境界が問題になるのか

クラウドロボティクスは、ロボット単体では不足する計算資源や知識をクラウド側で補完し、遠隔計算やデータ共有を利用する考え方です。大規模な計算や複数ロボットのデータを集約できる一方、通信接続、遅延、帯域幅、信頼性、セキュリティが制約になります。

エッジコンピューティングは、データ生成源の近くに計算資源を置く方式です。クラウドへの往復を減らし、遅延、通信量、クラウド接続への依存を抑えやすい点に意味があります。プライバシーの観点でも、すべてのセンサーデータを遠隔へ送らず、近傍で処理する構成を検討できます。

つまり設計上の対立は、クラウドかエッジかの二択ではありません。計算資源や知識共有を得る代わりに通信へ依存するか、応答性と接続独立性を優先してロボットや近接エッジへ処理を置くか、というトレードオフです。

前提となる用語

ここでいうオンデバイスは、センサーやアクチュエータを持つロボット本体で処理することです。構内エッジや地域エッジは、ロボットに近いネットワーク上の計算資源を指します。クラウドは、ロボットから離れた計算・ストレージ基盤です。

また、安全系とは、処理の遅延や失敗が安全な停止や危険回避に直接影響する機能を指します。非安全系とは、結果が遅れたり利用できなかったりしても、ロボットの安全な基本動作を直ちに損なわない処理です。

内部の仕組みと分担

安全系の基本経路は、センサー、ローカル状態推定、衝突監視、ローカル制御器、アクチュエータという閉ループにします。クラウドへの接続状態に左右されず、最低限の状態推定と停止判断を継続できることが前提です。リアルタイム処理では、予測不能なメモリ割り当て、ブロッキング、非決定的な処理を避け、期限内に完了できる実装が重視されます。

クラウド側には、センサーデータの要約やログ、学習用データ、フリート全体の分析を送ります。クラウド推論の結果は、高位計画やモデル更新などに利用できます。ただし、結果を受け取っただけで直ちにアクチュエータを動かすのではなく、期限内か、現在の状態と整合するかを確認し、無効なら破棄してローカル側へ戻します。

画像理解や意味認識のように計算負荷が高い処理はクラウドに置ける場合があります。しかし閉ループで利用するなら、ロボット側に低遅延の代替処理、安全な停止、または低機能モードを用意できることが条件です。

flowchart TD
  A["処理対象"] --> B{"安全性に直接影響するか"}
  B -->|"はい"| C["オンデバイスに配置"]
  B -->|"いいえ"| D{"許容遅延・ジッター・有効期限が厳しいか"}
  D -->|"はい"| E["オンデバイスまたは近接エッジに配置"]
  D -->|"いいえ"| F["クラウド配置を検討"]
  F --> G["タイムアウトを定義"]
  G --> H["期限切れの結果を破棄"]
  H --> I["ローカルフォールバックまたは安全停止"]

処理の安全性、許容遅延、ジッター、結果の有効期限を基準に、オンデバイス・近接エッジ・クラウドの配置を判断する。

処理カテゴリ別の配置

処理	基本配置	理由・条件
アクチュエータ制御	オンデバイス	通信遅延や切断を前提にできない
緊急停止・衝突回避の最終判断	オンデバイス	安全動作をローカルで完結させる
ウォッチドッグ	オンデバイス	接続状態に依存せず異常を検出する
最低限の状態推定	オンデバイス	制御継続に必要な状態を確保する
高負荷の画像理解・意味認識	エッジまたはクラウド	代替処理や安全停止を用意できる場合に限定
高位計画	エッジまたはクラウド	結果の遅延を許容できる場合
ログ再処理・フリート分析	クラウド	即時の安全動作を決めない
学習・モデルや地図の配布	クラウド	集約計算と配布に向く

通信品質に応じたフォールバック

クラウド推論を採用する処理には、まず結果の有効期限を設定します。期限を過ぎた結果は、通信が復旧して届いたとしても現在の状態に対して古い可能性があるため、破棄します。要求を送ってから一定時間以内に返らない場合も、待ち続けるのではなく、代替モデル、速度制限、低機能モード、安全停止、手動介入など、あらかじめ定めた動作へ遷移させます。

リアルタイムなロボットAI基盤：推論・制御・通信の実行予算を設計する

Sun, 14 Jun 2026 01:15:54 +0900

AI推論のベンチマーク値だけで、ロボット全体のリアルタイム性を判断できるのかが気になるテーマです。

先に結論

ロボットのAI処理に、制御30%、推論50%といった普遍的な固定比率はありません。先に制御ループの期限を予約し、センサー入力、アクチュエータ出力、ROS 2通信、スケジューリング干渉、安全余裕を見積もります。その残りをAIに割り当てるのではなく、AIにも独立した周期と期限を設定し、制御が推論の完了を同期的に待たない構成にするのが基本です。

判断には平均推論時間ではなく、前処理、メモリ転送、GPU実行、同期、後処理、ROS 2メッセージ処理まで含むエンドツーエンドのp99.9、最大値、ジッター、期限超過率を使います。AIが期限に間に合わない場合は、直近の有効な結果を使うか、安全なフォールバックへ切り替えます。

なぜ実行予算が必要か

ロボットでは、平均的に速い処理より、まれな期限超過をどう扱うかが重要です。AIが通常は短時間で完了しても、CPUやGPU、メモリ帯域、ドライバ、ログ処理などの競合で一部の周期が遅れれば、制御の決定性は崩れます。実行予算は、周期や締切の中で各処理が使える時間を明示するための枠組みです。

ハードリアルタイム経路では、処理時間の上限を見積もり、動的メモリ割り当て、ページフォールト、無制限に待つロック、非リアルタイムなシステムコールを避けます。これらは平均値には表れにくい遅延要因です。

前提となる仕組み

ROS 2のExecutorは、待機集合から実行可能なサブスクリプション、タイマー、サービス、アクションなどを取り出してコールバックを実行します。SingleThreadedExecutorは単一スレッド、MultiThreadedExecutorは複数スレッドを使います。ただし、一般的なExecutorはハードな優先度順やFIFO実行を保証しません。

Callback Groupには、同時実行を制限するMutually Exclusiveと、同時実行を許すReentrantがあります。これはコールバック間の関係を制御しますが、設定だけで締切やリアルタイム性が保証されるわけではありません。

QoSにはReliability、History、Deadline、Lifespan、Livelinessなどがあります。通信の信頼性、キュー保持、更新期限、データ鮮度を設計できますが、QoSのDeadlineはデータ更新を監視する機能であり、Executorのコールバック開始時刻や処理完了時刻を保証するものではありません。

予算の分け方

まず制御周期を定め、次の順で予算を予約します。

制御計算、センサー入力、アクチュエータ出力
リアルタイム通信処理
スケジューリングや共有資源による干渉
安全・ジッター余裕
AIの前処理、推論、後処理

AIを制御周期の「残り時間」に詰め込むと、推論遅延が制御期限を直接圧迫します。制御スレッドまたはリアルタイム向けExecutorはAIの結果を待たず、利用可能な結果の鮮度を確認して使う構成にします。AIの前処理やROS 2通信は別の実行資源に分け、GPU推論は可能な範囲で非同期に投入します。

設計上の仮置きとして、100 Hz、10 ms周期なら、制御とI/Oを2 ms、ROS 2通信処理を1 ms、AIのエンドツーエンド処理を6 ms、安全・ジッター余裕を1 msと置けます。ただし、これは標準値でも推奨値でもありません。対象のCPU、GPU、モデル、I/O、ROS 2構成を測定して再設定する必要があります。

flowchart LR
  subgraph CYCLE["100 Hz・10 ms周期の仮置き例"]
    CTRL["制御・I/O\n2 ms"] --> COMM["ROS 2通信処理\n1 ms"]
    COMM --> AI["AIエンドツーエンド処理\n6 ms"]
    AI --> MARGIN["安全・ジッター余裕\n1 ms"]
  end
  SENSOR["センサー入力"] --> CTRL
  AI -->|"期限内に取得"| FRESH["鮮度を確認して\n制御で利用"]
  AI -->|"期限超過"| FALLBACK["直近の有効値\nまたは安全なフォールバック"]
  FRESH --> ACT["アクチュエータ出力"]
  FALLBACK --> ACT
  CTRL -.->|"AIの完了を同期的に待たない"| FRESH

制御とI/O、通信、安全余裕を先に確保し、AIを独立した期限で実行する予算設計の仮置き例。2・1・6・1 msは推奨標準値ではなく、対象ハードウェアでの計測後に再設定する。

何を測るべきか

AIの計測点は、センサー取得、ROS 2受信、前処理開始、ホストからデバイスへの転送、GPUカーネルの開始・終了、同期、デバイスからホストへの転送、後処理、制御入力、アクチュエータ出力です。GPU処理は非同期に実行できるため、推論APIの呼び出し時間だけでは実際の完了時間を表しません。

ROS 2のノード合成を使い分ける：コンポーネント、ゼロコピー、障害分離の設計

Wed, 20 May 2026 08:53:24 +0900

ROS 2の「ゼロコピー」は、配置やミドルウェアの条件を分けて考える必要がある点が気になります。

結論：高速化と障害分離は、処理チェーンごとに境界を決める

ROS 2 Jazzyを前提にすると、カメラ画像やLiDAR点群のような大容量データを連続処理する場合、関連するComposable Nodeを同一プロセスのコンポーネントコンテナへ配置し、Intra-process Communicationを使う構成が有力です。通常のプロセス間DDS通信で必要になるシリアライズや外部トランスポート経由の処理を避けられるため、コピー回数、CPU負荷、通信経路上の待ち時間を減らす方向に働きます。

一方、同一プロセス化は障害分離を弱めます。さらに、ゼロコピーは一律に保証されず、メッセージ型、QoS、RMW実装、基盤ミドルウェア、APIの対応状況に左右されます。したがって、通信量の大きい安定した処理チェーンは合成し、実験的なアルゴリズム、頻繁な再起動が必要なノード、障害時にも残したい機能は別プロセスまたは別コンテナへ分ける、という判断が現実的です。

なぜノードの配置が重要なのか

画像や点群の処理では、センサー取得、前処理、認識、記録など複数のノードがデータを受け渡します。このとき、通信方式や実装に応じた経路・保持領域が関係し、処理段数や購読者数は遅延、CPU負荷、メモリ使用量に影響します。

別プロセスに配置したノード間では、通常、ROS 2のDDS/RMW通信経路を通ります。プロセス境界を越えるためのシリアライズやバッファリングが発生しますが、プロセス単位で影響範囲を分けやすい利点があります。逆に、低遅延だけを優先して多数のノードを一つのプロセスへ集約すると、あるノードのクラッシュで同じプロセス内の複数ノードが停止し得ます。

前提となる用語

Composable Node は、ノードを共有ライブラリとしてビルドし、コンポーネントコンテナへ動的にロードする仕組みです。複数のノードを同一プロセスで動かせます。

Intra-process Communication は、同一プロセス内のPublisherとSubscription間で使える通信経路です。通常のプロセス間通信とは異なり、同一プロセス内でメッセージを受け渡し、シリアライズを避けられる場合があります。ただし、別プロセスの購読者へ配信する場合は、DDS経路が必要です。

loaned message は、PublisherがRMWや基盤ミドルウェアからメモリを借りてメッセージを生成する方式です。同一プロセス内でメッセージの所有権を移動する方式とは異なります。

内部の仕組みとデータ経路

同一コンテナ内のPublisherとSubscriptionでIntra-process Communicationを有効にすると、メッセージは通常のプロセス間DDS経路を通らずに処理されます。その結果、プロセス間転送用のシリアライズ、デシリアライズ、外部トランスポート経由の処理を避けられます。これは遅延とCPU負荷を下げる方向に働きますが、ROS 2全体で共通する削減値が決まっているわけではありません。

また、同一プロセス内でもコピーや保持領域が完全になくなるとは限りません。Intra-process Managerの保持領域、QoSの履歴深度、キュー長、購読者数、メッセージの所有権方式によって、メッセージの保持やコピーの挙動が変わります。プロセス間転送用の中間コピーを削減できても、同一プロセス化が常にRSSを減らすとは限りません。

「ゼロコピー」を判断する際は、次の経路を区別します。第一は、同一プロセス内でメッセージの所有権を移動する経路です。第二は、RMWや基盤ミドルウェアからメモリを借りるloaned messageです。第三は、共有メモリトランスポートを利用するプロセス間通信です。これらは実装上の条件が異なり、一般に同じ意味でゼロコピーと呼べるわけではありません。第四の通常のシリアライズによるプロセス間通信は、ゼロコピー方式ではなく比較対象です。

loaned messageは、RMW実装、基盤ミドルウェア、メッセージ型、Publisher APIが対応している場合に利用できます。条件を満たさなければ、通常のメッセージ確保やコピーへフォールバックします。共有メモリ転送も、実装・設定依存であり、ROS 2アプリケーション全体で自動的に有効になるものではありません。

flowchart LR
  subgraph COMPOSED["同一プロセスのComposable Container"]
    C["カメラ"] -->|"Intra-process経路"| P["画像前処理"]
    P -->|"Intra-process経路"| R["認識"]
    P -.->|"外部購読者へはDDS経路"| E["記録・監視ノード"]
    C:::inside
    P:::inside
    R:::inside
  end

  subgraph SEPARATED["別プロセス構成"]
    C2["カメラプロセス"] -->|"DDS/RMW"| P2["前処理プロセス"]
    P2 -->|"DDS/RMW"| R2["認識プロセス"]
    R2 -->|"DDS/RMW"| E2["記録・監視プロセス"]
    C2:::process
    P2:::process
    R2:::process
    E2:::process
  end

  X["プロセス障害"] -.->|"同一アドレス空間のノードへ波及し得る"| COMPOSED
  Y["プロセス障害"] -.->|"プロセス単位で影響範囲を分けやすい"| SEPARATED

  classDef inside fill:#e8f3ff,stroke:#3777b8,stroke-width:1px
  classDef process fill:#f5f5f5,stroke:#666,stroke-width:1px
  style COMPOSED fill:#f2f8ff,stroke:#3777b8,stroke-width:2px
  style SEPARATED fill:#fafafa,stroke:#666,stroke-width:2px

同一プロセス化ではプロセス間転送を減らせる一方、クラッシュ時の影響範囲が広がり得ます。別プロセス化ではDDS/RMW経路が必要になりますが、障害境界を分けやすくなります。外部プロセスへの配信には、合成構成でもDDS経路が発生します。

graph LR
  subgraph COMPOSED[同一プロセス：Composable Container]
    C[カメラ] --> P[前処理]
    P --> R[認識]
  end
  E[記録・監視ノード\n外部プロセス]
  R -->|DDS/RMW\nプロセス間経路| E
  P -.->|Intra-process| R

図では、カメラ、前処理、認識を同一プロセスへ合成し、外部の記録・監視ノードEをプロセス境界の外に置いています。PからEへ出る経路は、同一プロセス内の受け渡しではなく、DDS/RMWなどを経由するプロセス間通信です。

Jetsonの推論性能を決める量子化・メモリ・電力の最適化手順

Tue, 05 May 2026 00:55:40 +0900

量子化や高クロック化は、設定を変えるだけで結果が決まるわけではありません。実機で何を測るかが、最初の分岐になります。

先に結論

Jetsonの推論最適化は、一般的な速度倍率を当てはめず、実機でモデル単体とエンドツーエンドの両方を計測して決めます。まず入力形状を固定し、FP16・バッチ1を基準にします。その後、INT8の精度とレイテンシ、バッチサイズ、メモリ転送と同期、CUDA Graph、電力モードを一項目ずつ比較します。

INT8はメモリ使用量や推論時間を削減できる可能性がありますが、常にFP16より高速になるわけではありません。ロボット制御のように応答時間を優先するなら小さいバッチ、高スループット処理なら大きいバッチを候補にします。最終判断では、レイテンシ、スループット、精度、ピークメモリ、消費電力、温度、連続稼働時の安定性を同時に確認します。

なぜ実機計測が必要か

TensorRTの性能は、精度モードだけでなく、レイヤー実装、workspace、選択されたtactic、入出力形状、データ変換の組み合わせで決まります。対象Jetsonの世代、JetPack、TensorRT、CUDAの組み合わせによって、INT8演算子の対応やTensor Coreの利用可否も異なります。したがって、モデルの種類だけから最適設定を決めることはできません。

JetsonではCPUとGPUが物理メモリを共有します。離散GPUのようなPCIe転送だけでなく、共有DRAMの帯域競合、キャッシュ、バッファの再配置、同期も性能に影響します。モデル単体のベンチマークが良くても、カメラ取得、前処理、後処理を含めると別の場所がボトルネックになる場合があります。

用語と仕組み

FP32、FP16、INT8は、計算やテンソルを表す精度の選択肢です。低精度化によって、条件によっては演算量やテンソルのメモリ使用量を減らせます。INT8では、キャリブレーションでスケールを推定する方式と、モデルにQ/DQノードを含めて量子化を明示する方式があります。いずれも量子化後のモデル精度を評価しなければなりません。

バッチサイズは一度に処理する入力数です。大きくするとGPU利用効率やスループットが向上する可能性がある一方、1リクエストあたりの待ち時間、キューイング遅延、メモリ使用量が増えます。リアルタイム制御ではバッチ1または小さいバッチ、まとめ処理では大きいバッチを比較します。

入力形状が一定なら固定形状のエンジンを優先します。可変形状が必要な場合は、TensorRTのoptimization profileに最小・最適・最大形状を設定し、実際に使う形状ごとに測定します。

メモリ転送と実行制御

基本的な流れは、入力取得、前処理、TensorRT推論、後処理、出力受け渡しです。前処理から後処理までのテンソルをGPU側に保持し、バッファを再利用できれば、毎フレームのCPU・GPU間コピーや不要な形式変換を減らせます。ただし、Jetsonではゼロコピーや共有バッファが常に最速とは限りません。アクセスパターンと同期コストを実測します。

ホストとデバイス間の移動が必要なら、ページロックされたホストメモリ、非同期コピー、CUDA streamを候補にします。コピーと前処理、またはコピーと推論を重ね合わせられるかを確認します。Nsight Systemsでは、CPU処理、CUDA API、メモリ転送、カーネル、同期を同じタイムラインで確認できます。

入力形状、バッファアドレス、実行経路が安定した反復推論では、TensorRTのCUDA Graphも候補です。実行シーケンスを再利用して、カーネル起動や実行制御のオーバーヘッドを削減できる可能性があります。動的形状や実行時に変化するアドレスがある場合は、適用条件を確認します。

flowchart LR
  A["条件を固定\nJetson型番・JetPack・TensorRT・CUDA\n入力形状・評価データ・電力設定"] --> B["FP16・バッチ1を基準測定"]
  B --> C["モデル単体を測定"]
  B --> D["エンドツーエンドを測定"]
  C --> E["INT8を構築・精度検証"]
  D --> E
  E --> F["バッチサイズを比較\nレイテンシ・スループット・キューイング遅延・ピークメモリ"]
  F --> G["転送と同期をプロファイリング\nCPU・CUDA API・コピー・カーネル・同期"]
  G --> H["バッファ再利用・非同期化・GPU側保持を評価"]
  H --> I["条件が合えばCUDA Graphを評価"]
  I --> J["電力モードとクロック設定を比較"]
  J --> K["総合判断\nレイテンシ・精度・メモリ・電力・温度・連続稼働時の安定性"]
  K --> L{"目標要件を満たすか"}
  L -- "いいえ" --> F
  L -- "はい" --> M["設定と測定結果を記録"]

実機で条件を固定し、モデル単体とエンドツーエンドを測定したうえで、量子化、バッチ、メモリ転送、CUDA Graph、電力設定を一項目ずつ評価する流れ。

再現性のある評価手順

条件を固定する：Jetson型番、JetPack、TensorRT、CUDA、入力形状、評価データ、電力設定を記録します。
基準を測る：FP16・バッチ1を、trtexecなどでモデル単体として測定し、続いて前処理・推論・後処理を含むエンドツーエンドで測ります。
INT8を検証する：キャリブレーションまたはQ/DQ方式で構築し、精度、レイテンシ、変換処理、対応演算子を確認します。
バッチを比較する：バッチ1、小さいバッチ、大きいバッチを、レイテンシ、スループット、キューイング遅延、ピークメモリで比較します。
転送と同期を調べる：GPU側テンソル保持、非同期化、stream、共有バッファ、必要に応じてCUDA Graphを一つずつ比較します。
電力と連続稼働を測る：nvpmodelの電力モードとjetson_clocksのクロック設定を比較し、温度やサーマルスロットリングも確認します。

選択肢の比較

選択肢	向いている要件	利点	注意点
FP16	基準測定、低レイテンシ	比較の出発点にしやすい	INT8よりメモリや計算量が大きい場合がある
INT8	メモリ制約、速度・省電力の改善	低精度化の効果を期待できる	精度、演算子対応、再量子化を検証する
バッチ1・小バッチ	制御、カメラ入力	待ち時間とキューイングを抑えやすい	スループットが伸びない可能性がある
大きいバッチ	まとめ処理、分析	GPU利用効率とスループットに有利な可能性	レイテンシとピークメモリが増える
固定形状	入力サイズが一定	条件を限定して測定しやすい	可変入力には向かない
動的形状	入力サイズが変化	複数形状を扱える	profileごとの性能測定が必要
GPU側保持・非同期化	前処理から後処理までGPUを使う構成	コピーや同期を減らせる可能性	共有バッファの同期を確認する
低電力モード	バッテリー、温度、連続稼働重視	電力と熱を抑える候補になる	目標レイテンシを満たすか測る

制約と判断基準

「INT8なら必ず高速」「バッチを増やせば必ず高性能」と決めつけてはいけません。対象演算子のINT8対応、Tensor Coreの利用可否、再量子化や入出力変換、TensorRT tacticによって結果は変わります。固定形状と動的形状の差、ゼロコピーの効果、CUDA Graphの改善幅も、モデルと実装によって異なります。

Jetson上でVLMと物体検出を組み合わせる推論パイプライン設計

Mon, 05 Jan 2026 23:57:34 +0900

JetsonでVLMを使うとき、毎フレーム処理させるべきか、それとも役割を分けるべきかが設計上の分岐点になります。

先に結論

Jetsonでカメラ認識システムを構築するなら、物体検出モデルを高頻度で動かす一次視覚ループ、VLMを必要時だけ呼び出す二次推論ループとして分離するのが基本です。検出器は物体の位置、既知クラス、信頼度、追跡情報を継続的に供給し、VLMは未知物体の説明、属性や関係性の解釈、自然言語による確認を担当します。

VLMを毎フレーム実行すると計算量やメモリ使用量、レイテンシが増えやすくなります。一方、検出器だけでは説明や文脈理解が難しい場合があります。両者を同期処理で直列化するのではなく、検出器とトラッカーを継続させたままVLMを非同期実行することが、リアルタイム性と柔軟な認識を両立する判断になります。

なぜ分担が必要なのか

物体検出器は、既知クラスについて画像中の位置、クラス、信頼度を取得する処理に向きます。ロボットが周囲の物体を追跡し、制御系へ一定間隔で位置情報を渡す用途では、検出器を一次ループに置くのが自然です。

VLMは画像と言語を組み合わせ、画像の説明、質問応答、属性理解、物体間の関係性の解釈などを扱います。したがって、両者は完全な代替ではなく補完関係です。ただし、テキストでカテゴリを指定するオープンセット検出器もあるため、境界は固定的ではありません。必要な出力が「どこに何があるか」なのか、「どのような状態で、何と関係しているか」なのかを先に分けます。

基本用語と内部の仕組み

一次ループは、カメラ入力から前処理、物体検出、トラッキングまでを高頻度で処理する経路です。ここで座標、クラス、信頼度、追跡ID、時刻情報を更新します。二次ループは、一次ループが発生させたイベントを契機に、VLMへ画像と質問や指示文を渡す経路です。

呼び出し条件には、検出信頼度の低下、未知クラス候補、属性や関係性の確認要求、シーン変化、一定間隔の再評価を使えます。毎フレームではなく、不確実性や変化が生じたときに実行することで、VLMの処理量を抑えられます。

VLMへは毎回フルフレームを渡す必要はありません。検出器が得たROI、クラス候補、信頼度、追跡ID、時刻情報を優先し、周囲との位置関係など空間的文脈が必要な場合だけフルフレームを追加します。ROIは対象を絞れますが、周辺情報を失う可能性があるため、質問の内容に応じて切り替えます。

flowchart LR
  A["カメラ入力"] --> B["前処理"] --> C["物体検出"] --> D["トラッカー"]
  D --> E["検出メタデータ更新\n座標・クラス・信頼度・追跡ID・時刻"]
  E --> F["結果統合"]
  E --> G["イベント判定"]
  G --> G1["信頼度低下・未知物体候補\n属性や関係性の確認・シーン変化"]
  G1 --> H["非同期キュー"]
  E --> I["ROI・クラス候補・信頼度\n追跡ID・時刻情報"]
  A -. "空間的文脈が必要な場合" .-> J["フルフレーム"]
  I --> H
  J --> H
  H --> K["VLM推論\n画像またはROI＋質問・指示文"]
  K --> L["VLM結果をメタデータとして追加"]
  L --> F
  F --> M["安全監視"] --> N["制御系・状況理解・オペレーター向け情報"]
  D -. "VLM処理中も継続動作" .-> E

物体検出器とトラッカーを高頻度で継続動作させ、イベント発生時だけVLMを非同期実行する構成。VLMの出力は検出結果を置き換えず、メタデータとして統合します。

VLMの結果は検出結果を置き換えるのではなく、メタデータとして統合する設計が扱いやすいでしょう。VLM処理中も検出器とトラッカーを動かします。DeepStreamのようなGStreamerベースの基盤では、映像入力、前処理、推論、トラッキング、メタデータ処理を接続できます。キューで検出経路とVLM経路を分離すれば、VLMの遅延が検出器や制御系を停止させにくくなります。ただし、特定のVLMプラグインが標準提供されることや、VLMを毎フレーム処理できることを意味しません。