長時間運用 on Physical AI Hub

ロボットの電力制約をタスク計画へ反映する：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などのクロックを制御します。性能評価時と実運用時の設定を明示し、異なる条件の結果を混同しないことが必要です。