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

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のコールバック開始時刻や処理完了時刻を保証するものではありません。

予算の分け方

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

1. 制御計算、センサー入力、アクチュエータ出力
2. リアルタイム通信処理
3. スケジューリングや共有資源による干渉
4. 安全・ジッター余裕
5. 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

何を測るべきか

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

CUDA Graphなどは起動オーバーヘッドを削減し得ますが、動的形状、メモリ再利用、入力依存の分岐などに適用条件があります。高速化手法を採用しても、締切そのものが保証されるわけではありません。

評価では平均値だけでなく、p99、p99.9、最大値、ジッター、期限超過率、キュー滞留時間、CPU・GPU使用率、ページフォールト、コンテキストスイッチを確認します。最大負荷、温度上昇、ログ出力、バックグラウンド処理、メモリ帯域競合を含めて測ることが必要です。

sequenceDiagram
  participant S as "センサー"
  participant R as "ROS 2受信"
  participant P as "前処理"
  participant CPU as "ホストCPU"
  participant GPU as "GPU推論"
  participant C as "制御ループ"
  participant A as "アクチュエータ"
  S->>R: "t0 センサー取得"
  R->>P: "t1 ROS 2受信"
  R->>P: "t2 前処理開始"
  P->>CPU: "t3 H2D転送・推論投入"
  Note over CPU,GPU: "GPU処理は非同期に投入されるため、API呼び出し時間だけでは完了時間を表さない"
  GPU-->>GPU: "t4 GPUカーネル実行"
  GPU-->>CPU: "t5 推論完了・D2H転送"
  CPU->>C: "t6 後処理結果・制御入力"
  C->>A: "t7 アクチュエータ出力"
  Note over S,A: "t0〜t7のエンドツーエンド時間と各区間を記録し、p99・p99.9・最大値・ジッター・期限超過率を集計する"

構成の比較

実装時の判断基準

制御、I/O、安全監視はAIや一般のROS 2コールバックから実行上分離します。別CPUコア、別プロセス、別アクセラレータへの分離は干渉を減らす手段ですが、共有メモリ、帯域、ドライバ、OS処理の影響は残ります。分離後もp99.9と最大値を再計測してください。

QoSはデータの性質で選びます。古いセンサー値を捨てて鮮度を優先するなら履歴を制限し、欠落より配信の信頼性を優先するならReliabilityを検討します。DeadlineやLifespanは期限・鮮度の監視に使いますが、コールバック実行時間の上限とは分けて管理します。

AIモデルも、高精度・高遅延構成と低精度・低遅延構成を、平均値だけでなくジッターと期限超過率で比較します。対象ロボットの周期、I/O時間、ハードウェア、OS、RMW実装、DDS、モデル形状が不明な段階では、実際の比率や最悪実行時間は確定できません。

まとめ

採用判断の軸は、AIが何ミリ秒で終わるかではなく、制御期限を守り、期限超過時にも安全に縮退できるかです。制御と安全余裕を先に確保し、通信を独立した予算として管理し、AIはエンドツーエンドのp99.9、最大値、ジッター、期限超過率で評価します。

参考情報

• ROS 2 Executor: How to make it efficient, deterministic, and responsive for real-time?
• ROS 2 Jazzy Documentation — Real-Time Programming
• Background on Real-time Programming in ROS 2
• ROS 2 Jazzy Documentation — About Executors
• ROS 2 Jazzy Documentation — Using Callback Groups
• ROS 2 Jazzy Documentation — About Quality of Service Settings
• TensorRT 10.0.1 Best Practices
• CUDA C++ Programming Guide 12.5 — Asynchronous Concurrent Execution

推論速度の競争だけでなく、遅れたときの縮退設計まで含めて評価する視点が欠かせません。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。