再計画 on Physical AI Hub

ロボット行動方策の実行粒度：アクションチャンクと再計画周期の設計

Thu, 24 Sep 2026 13:31:55 +0900

アクションチャンクの「長さ」と再計画の「間隔」は、同じ数字で語られがちな点が気になります。

先に結論

ロボットの行動方策では、1回の推論で予測する長さ H と、次の推論まで実際に実行する長さ K を分けて設計するべきです。Hはタスクの時間的なまとまりや先読みを表し、Kは環境変化に対する反応性と推論負荷を左右します。

基本方針は、通常 H >= K とし、予測した全アクションを固定的に実行しないことです。接触、物体移動、外乱、視覚変化が多い局面ではKを小さくし、安定した自由空間動作や推論コストが高い構成ではKを大きくする候補があります。ただし、最適な数値はロボット、制御周期、アクション表現、推論遅延、タスクによって変わるため、実機でHとKを組み合わせたアブレーションを行って決めます。

なぜHとKを分けるのか

アクションチャンクとは、方策が1回の推論で単一のアクションではなく、複数ステップの連続アクション列を予測する設計です。ACT（Action Chunking with Transformers）は固定長のアクション列を予測し、時間的に重なる予測をtemporal ensembleで融合する構成を採用しています。一方、Diffusion Policyはアクション列を生成し、その一部を実行して観測を更新し、再計画するreceding-horizon controlを用います。

ここで「チャンク長」という言葉を、予測する列の長さと、再計画まで実行する長さの両方に使うと、実装上の議論が曖昧になります。本稿では、予測長をH、実行してから次に推論する間隔をKと定義します。Hを長くしても、Kを短く保つことは可能です。逆にHとKを同じ値にして、予測列全体をオープンループで実行することもできますが、その場合は途中の観測を使った修正機会が減ります。

ステップ数ではなく時間で考える

HとKはステップ数だけでなく、低レベル制御周期 Δt_ctrl と組み合わせて評価します。予測時間はHΔt_ctrl、再計画時間はKΔt_ctrlです。同じKでも、制御周期が異なれば、ロボットが観測なしで動く物理的な時間は変わります。

さらに、観測、通信、方策推論を含むエンドツーエンド遅延を T_inf とします。同期推論では、少なくともT_infがKΔt_ctrlを超えないかを確認する必要があります。超える場合、推論完了までに現在のアクション列を使い切る可能性があります。そのときは、アクションバッファ、非同期推論、低レベルサーボ、安全な停止・ホールド機構などを設け、推論の遅さを単純なオープンループ時間の増加として放置しないことが重要です。

flowchart LR
  A["時刻 t0：観測"] --> B["方策推論"]
  B --> C["長さHのアクション列を予測"]
  C --> D["最初のKステップだけ実行"]
  D --> E["時刻 t0+K：新しい観測"]
  E --> F["次のアクション列を再計画"]
  F --> G["新しい列の一部を実行"]
  G --> H["次の観測と再計画"]
  C -. "HΔt_ctrl：予測時間" .-> D
  D -. "KΔt_ctrl：実行・再計画間隔" .-> E
  F -. "予測が重なる場合" .-> I["temporal ensembleや加重平均で融合"]
  I -. "滑らかさと反応遅れを評価" .-> G
  C -. "基本方針 H≥K" .-> F

予測長Hは先読みの長さ、再計画間隔Kは実際に実行してから次の推論を行うまでの長さを表す。基本方針はHをK以上とし、観測更新によって実行列を分割することです。

HとKの時間軸

時刻t0で方策が長さHのアクション列を予測し、そのうち最初のKステップを実行します。t0+Kで新しい観測を取得し、次の列を予測します。新しい予測と過去の予測が同じ時刻に対応する場合は、temporal ensembleや加重平均によって融合できます。これにより、チャンク境界での入力の不連続や急変を抑えられる可能性があります。

ロボットの失敗からの復旧設計：リトライ・再計画・人への引き継ぎを使い分ける

Wed, 23 Sep 2026 13:35:31 +0900

ロボットの失敗時に、単純な再試行が安全とは限らない点に着目しました。

先に結論

ロボットのタスク実行失敗は、すべて同じ動作を繰り返して解決するものではありません。失敗した原因、現在の状態を信頼できるか、再実行で副作用が生じるか、危険度がどの程度かを評価し、対応を分岐させます。

一時的な通信断やタイムアウトで、安全条件と状態が維持されているなら、回数や時間の上限を設けたリトライが候補です。障害物、物体姿勢、把持状態、マップ、位置推定などの前提が変化した、または不確実になった場合は、再観測と状態推定の更新を含む再計画を優先します。衝突、挟まれ、落下、過大な力、センサーやアクチュエータの異常、状態不明、反復失敗では、安全状態へ移行して人に引き継ぎます。

なぜ実行中の復旧設計が必要か

自律ロボットは、計画を一度生成して最後まで実行するだけでは運用できません。実行中には、観測された世界と計画が仮定した状態に差異が生じます。その差異や失敗を監視し、回復または再計画につなげる実行管理が必要です。計画、実行、監視、再計画を循環させる構成は、自律ロボットのdeliberationでも整理されています。

ここで扱うのは、ノードの起動や停止だけではなく、把持や搬送などのタスクが途中で失敗したとき、次に何をするかを決める上位の復旧ポリシーです。

前提となる用語

リトライは、同じタスクまたは局所動作を再実行することです。リカバリ動作は、再試行の前に待機、後退、再配置などの処置を行うことを指します。Nav2の行動木には、主タスクの失敗後にリカバリを実行し、主タスクへ戻るRecoveryNodeや、複数のリカバリ動作を順番に試す構成があります。

再計画は、最新の観測や状態推定を使って、目標までの手順や制約を組み直すことです。人への引き継ぎは、単に通知して停止することではありません。安全状態への移行、診断情報の提示、人の介入確認、再検証、明示的な再開承認までを含む状態遷移として設計します。

内部の仕組み

実装では、タスク実行器と安全監視を分離します。実行器は成功、失敗、フィードバック、観測結果をタスクオーケストレータへ返します。オーケストレータは失敗分類と状態信頼性を評価し、リトライ、再計画、停止を選択します。状態推定器は対象物や環境の最新状態を更新し、計画器はその結果を制約として使います。安全監視は、タスク側の再試行判断とは別に、危険時の停止要求を担います。

ROS 2のActionは、長時間実行される目標について、目標、フィードバック、結果、キャンセルを扱う通信方式です。実行監視や停止要求の受け渡しに利用できます。一方、ROS 2 Managed Nodeのライフサイクルは、未構成、非アクティブ、アクティブ、終了済みなどの状態と、設定、起動、停止、クリーンアップ、エラー処理の遷移を明示します。これらは、停止後の再初期化や再アクティベーションを、暗黙の再開と区別する基盤になります。

行動木では、BehaviorTree.CPPのRetryやRetryUntilSuccessfulのようなデコレータで、子ノードの失敗時の再実行や回数制御を表現できます。ただし、Retryノードは再実行機構であって、安全に再実行できる条件を自動的に定義するものではありません。

flowchart TD
  A["タスク実行中"] --> B["失敗を検出"]
  B --> C{"危険な兆候または安全機能の作動があるか"}
  C -->|"はい"| H["安全状態へ移行"]
  C -->|"いいえ"| D["現在の状態と安全条件を確認"]
  D --> E{"状態を信頼できるか"}
  E -->|"いいえ"| H
  E -->|"はい"| F{"原因は一時的で再実行は安全か"}
  F -->|"はい"| G["上限付きリトライ"]
  G --> I{"回数・時間・試行予算内か"}
  I -->|"はい"| J["状態を再確認して再実行"]
  J --> A
  I -->|"いいえ"| H
  F -->|"いいえ、前提が変化または不確実"| K["再観測と状態推定の更新"]
  K --> L["制約を反映して再計画"]
  L --> M{"更新後の計画は安全条件を満たすか"}
  M -->|"はい"| N["計画を検証して再開"]
  N --> A
  M -->|"いいえ"| H
  H --> O["失敗情報・観測・試行履歴を提示"]
  O --> P["人への引き継ぎ"]
  P --> Q["介入完了後にロボット・環境・対象物を再検証"]
  Q --> R{"明示的な再開承認と再検証に成功したか"}
  R -->|"はい"| S["検証済みチェックポイントから再開"]
  R -->|"いいえ"| T["タスクを中止"]

失敗原因、状態の信頼性、安全条件、試行予算に基づいて、リトライ・再計画・人への引き継ぎを選択する復旧フロー。

3つの復旧手段の比較

手段	適用条件	必要な確認	主な停止条件	再開条件
リトライ	原因が一時的で、状態と安全条件を確認できる	対象物、ロボット、周囲の状態	回数・時間・総試行予算の超過、副作用の兆候	状態を再確認し、同じ処理が安全に実行可能
再計画	前提条件が変化、または状態が不確実	再観測、状態推定、制約の更新	新しい計画でも安全条件を満たせない	更新後の計画と環境状態を検証
人への引き継ぎ	危険、状態不明、ハードウェア異常、反復失敗	失敗コード、観測データ、試行履歴	人の介入がない、再検証に失敗	介入完了、ロボット・環境・対象物の再検証、明示承認

リトライを設計する条件

リトライは、失敗原因が一時的である場合に限定します。通信タイムアウトのように、対象物やロボットの状態が変わっておらず、安全に再確認できるなら候補になります。ただし、回数、待機時間、バックオフ、総試行予算をあらかじめ設けます。Nav2のRecoveryNodeにも再試行回数を設定する構成がありますが、適切な回数や安全条件はタスクごとに決める必要があります。

ロボット経路計画の衝突判定設計：安全性・計算量・制御周期をどう両立するか

Thu, 07 May 2026 08:46:36 +0900

衝突判定の周期を一つの数値で決められない点が、このテーマで特に気になるところです。

先に結論

ロボットの衝突判定に、すべての用途で共通する固定周波数はありません。計画時の経路検証、実行時の軌道再検証、保護停止用の監視を分け、それぞれに適した精度と周期を設定します。

周期は単純なHzではなく、判定と判定の間にロボットと障害物が相対的にどれだけ移動するかで決めます。相対移動量が許容マージンを超えるなら、周期を短くするだけでなく、判定の細分化、連続衝突判定、保守的な掃引判定を検討します。

なぜ三つの層に分けるのか

計画層は、将来の状態列として生成された経路全体を、環境モデルと照合する役割を持ちます。実行層は、実行直前や実行中に、現在のロボット状態と最新の環境で軌道を再確認します。監視層はセンサー入力を使い、危険が迫った場合の速度制限や停止を担います。

計画用の判定頻度をそのまま保護監視へ使うことも、監視だけで計画経路全体の安全性を保証することも適切ではありません。再計画は新しい経路を生成する処理であり、衝突判定の代替ではないためです。再計画中もロボットが動くなら、別の監視層でその間を保護します。

前提となる用語と判定の仕組み

状態の有効性判定は、ある時点のロボット姿勢が障害物や自身のリンクと干渉していないかを調べる処理です。一方、モーション検証は二つの状態の間の動きを調べます。

始点と終点だけを判定すると、その間でリンクが障害物を通り抜ける衝突を見逃す可能性があります。OMPLでは状態の有効性判定と状態間のモーション検証を分け、離散的な検証では補間状態を検査します。MoveItのOMPLインターフェースでは、longest_valid_segment_fraction や longest_valid_segment_length により、モーション中に許す最大セグメント長を調整できます。

したがって、計画時の精度は「何Hzか」ではなく、状態空間における最大有効セグメント長として考える方が適切です。ロボット形状、障害物の薄さ、狭い隙間、姿勢変化による掃引領域を基準にします。長いリンクや大きな姿勢変化がある場合、同じ状態空間上の刻みでも空間内の移動量は大きくなり得ます。

flowchart LR
  A["状態A"] --> B["状態間の動き"]
  B --> C{"セグメント長は
形状・運動に対して適切か"}
  C -->|"適切"| D["補間状態を検査"]
  C -->|"長すぎる"| E["セグメントを細分化"]
  E --> D
  D --> F{"障害物・自己リンクとの
干渉を検出"}
  F -->|"衝突なし"| G["次のセグメントへ"]
  F -->|"衝突あり"| H["経路を不 valid として扱う"]
  G --> I["状態B"]
  A -.-> J["端点だけの判定では
途中の衝突を見逃し得る"]
  I -.-> J

端点だけでなく状態間の補間状態を検査し、形状や運動に応じてセグメント長を調整する考え方を示しています。

動的障害物と安全マージン

動的環境では、判定した瞬間に安全でも、次の判定までにロボットや障害物が接近します。相対速度を v_rel、判定周波数を f_check、許容距離を d_allow とすると、周期設計の概念的な目安は次のように表せます。

v_rel / f_check ≤ d_allow