ロボットの失敗時に、単純な再試行が安全とは限らない点に着目しました。
先に結論
ロボットのタスク実行失敗は、すべて同じ動作を繰り返して解決するものではありません。失敗した原因、現在の状態を信頼できるか、再実行で副作用が生じるか、危険度がどの程度かを評価し、対応を分岐させます。
一時的な通信断やタイムアウトで、安全条件と状態が維持されているなら、回数や時間の上限を設けたリトライが候補です。障害物、物体姿勢、把持状態、マップ、位置推定などの前提が変化した、または不確実になった場合は、再観測と状態推定の更新を含む再計画を優先します。衝突、挟まれ、落下、過大な力、センサーやアクチュエータの異常、状態不明、反復失敗では、安全状態へ移行して人に引き継ぎます。
なぜ実行中の復旧設計が必要か
自律ロボットは、計画を一度生成して最後まで実行するだけでは運用できません。実行中には、観測された世界と計画が仮定した状態に差異が生じます。その差異や失敗を監視し、回復または再計画につなげる実行管理が必要です。計画、実行、監視、再計画を循環させる構成は、自律ロボットの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にも再試行回数を設定する構成がありますが、適切な回数や安全条件はタスクごとに決める必要があります。
把持や搬送では、再実行が二重動作にならないよう注意が必要です。リトライ前に対象物の存在、把持状態、接触状態、周囲の占有状態を確認し、識別子やチェックポイントで処理の重複を防ぎます。外界に不可逆な副作用を与える操作ほど、単純な再送を避けるべきです。
再計画へ切り替える条件
障害物の出現、物体姿勢の変化、把持状態の不確実性、マップや位置推定のずれは、同じ軌道を繰り返しても解決しない可能性があります。この場合は、まず再観測し、状態推定を更新します。その後、最新の制約を反映して局所的またはタスク全体を再計画します。
再計画は「失敗した動作を別の動作に置き換える」だけではありません。目標までの経路、タスク分解、利用できる対象や手順を見直す処理です。再計画後も状態が不明、または安全条件を満たさないなら、リトライへ戻すのではなく停止と引き継ぎへ進めます。
人への引き継ぎを状態遷移にする
引き継ぎ時には、まず安全監視の判断に従って安全状態へ移行します。そのうえで、失敗コード、直前の観測、状態推定、実行した動作、試行回数、停止理由を提示し、試行履歴を保存します。人の介入が完了したことを確認した後、ロボット、環境、対象物を再検証し、明示的な再開承認を受けます。再開位置は、検証済みのチェックポイントから選び、条件が満たせなければタスクを中止します。
非常停止、保護停止、速度・力の制限などの安全機能は、タスクオーケストレータのリトライ処理とは別に設けます。安全境界を越えてタスク側が再試行できない構成にすることが重要です。ISO 10218-1およびISO/TS 15066は、安全要求、リスク低減、保護措置を扱いますが、個別タスクのリトライ回数や人への引き継ぎ閾値を一律に定めているわけではありません。
flowchart LR E["タスク実行器"] -->|"成功・失敗・フィードバック・観測結果"| O["タスクオーケストレータ"] O -->|"実行指示"| E O -->|"状態更新要求"| S["状態推定器"] S -->|"対象物・環境・ロボットの最新状態"| O O -->|"再計画要求と制約"| P["計画器"] S -->|"更新された状態"| P P -->|"計画または再計画結果"| O O -->|"リトライ・再計画・停止の選択"| E M["安全監視"] -->|"独立した停止要求"| E M -->|"安全状態への移行要求"| O O -->|"失敗コード・観測・試行履歴"| H["人間インターフェース"] H -->|"介入完了・明示的な再開承認"| O L["ライフサイクル管理"] -->|"停止・再初期化・再アクティベーション"| E A["ROS 2 Action等の通信"] -.->|"目標・フィードバック・結果・キャンセル"| O
判断基準と失敗しやすい点
判断には、少なくとも次の順序を使います。
- 危険な兆候や安全機能の作動があるか。
- ロボット、対象物、環境の現在状態を信頼できるか。
- 失敗原因は一時的か、前提条件の破綻か。
- 再実行は冪等か、副作用を管理できるか。
- 試行回数、時間、リスクの予算を残しているか。
失敗しやすいのは、フレームワークのRetry機能を安全ポリシーとみなすこと、ナビゲーション向けのリカバリ回数を把持や搬送へそのまま適用すること、停止後に状態を再検証せず再開することです。最適なリトライ回数、待機時間、信頼度閾値、オペレータ応答時間には普遍的な数値がありません。ロボット、対象物、周辺設備、危険度、運用体制に応じた評価が必要です。
まとめ
復旧設計の中心は、失敗を検出したら何度も繰り返すことではなく、状態と危険度に応じて復旧手段を選ぶことです。一時的で安全に再確認できる失敗には上限付きリトライ、前提条件の変化や不確実性には再観測を伴う再計画、危険・状態不明・反復失敗には安全停止と人への引き継ぎを適用します。行動木やROS 2のAction、ライフサイクル状態はその構造化に役立ちますが、安全条件や閾値そのものはタスク固有に設計しなければなりません。
参考情報
- Nav2 Detailed Behavior Tree Walkthrough
- BehaviorTree.CPP Decorator Nodes
- ROS 2 Managed nodes
- ROS 2 Actions
- Deliberation for Autonomous Robots: A Survey
- ISO 10218-1:2011
- ISO/TS 15066:2016
復旧処理と安全機能の責務を分けることが、設計の判断を明確にします。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。
