Nav2挙動ツリーはナビゲーションアクション、条件、回復動作を調整します。再計画、選択したコストマップのクリア、待機、スピン、バックアップ、または別のシステム応答の要求が可能です。この木は既知の失敗を有界の決定に変換するべきです。すべてのエラーをロボットの動きの繰り返しにしてはいけません。
回復の質は状況によって異なります。プランナーの誤りは経路近くのローカル修理の正当化となり得ますが、持続的な局所化やシステム障害はキャンセルやオペレーターの支援を必要とすることがあります。介入で上書きされる前に元のエラーを保持し、再試行で再試行予算を消費する前に測定可能な進行状況を要求します。
このガイドをROS 2ライフサイクルリカバリーガイドおよびコストマップガイドNav2併用してください。展開したロボット構成にフォールトを注入してツリーをテストします。
ツリーを明示的なナビゲーションポリシーとして使用する
ビヘイビアツリーは、シーケンス、フォールバック、デコレーター、条件、アクションノードを通じて制御フローを可視化します。 Nav2 これらのノードをプランナー、コントローラー、ビヘイビアサーバーに接続します。したがって、XMLはどの障害を再試行、修理、エスカレーション、または発信者に返すかを決定する運用ポリシーとなります。
Nav2 behavior-tree ドキュメントは、アプリケーションに合わせて変更可能な例ツリーを提供しています。例を出発点として扱いましょう。ミッション制約、物理的回収権限、再試行制限、実際の車両や現場に求められる観測性を加えます。
コンテキストリカバリーとシステムリカバリーを分離する
文脈的回復は失敗した行動のすぐ近くにあります。経路計画の分岐はグローバルコストマップをクリアしたり、別のプランナーを試したりでき、経路追従分岐はローカルのコストマップやコントローラーの状態を扱うことができます。この近接性により有用な故障識別が保たれ、早期の広範な介入を回避できます。
システム復旧は、より狭い対策が尽きた後や故障が局所的に発生しない状態の後に実行されます。環境を待つか、状態全体をクリアするか、許可された動きを行うか、航行リクエストを終了するかのどちらかです。エラークラスと証拠のレベル間の遷移を定義し、単なる失敗カウントからではなく定義してください。
| 失敗の証拠 | おそらく所有者 | 文脈的応答 | エスカレーションの例 |
|---|---|---|---|
| 有効なグローバルパスはありません | プランナーまたはグローバルマップ | 再計算またはターゲットクリア | 到達できない目標を拒否する |
| コントローラーは進行できません | 局所的な管理または障害 | 局所クリアまたは制御待ち | キャンセルしてホールドする |
| ポーズは無効かジャンプ | 局所化 | マップクリア時は隠れないでください | 再ローカライズか助けを求める |
| サーバーは利用できません | ライフサイクルまたはプロセス | 管理状態のチェック | 監督者回復 |
| 物理的な経路が遮られている | 環境 | 待機か代替ルートか | 人的介入 |
RecoveryNodeのリトライの意味を理解する
RecoveryNodeは通常、プライマリ子を実行し、失敗後にリカバリー子を呼び出します。リトリー回数は設定されています。この構造は、故障の原因となった条件を回復が変えられる場合にのみ有用です。同じ入力や状態を繰り返すことは単なる遅延であり、繰り返しの動きを生み出すことがあります。
再試行回数が展開された実装における総プライマリ試行数か復旧サイクルかを文書化してください。各試み回数、エラーコード、経過時間を記録してください。カウントとウォールクロックの持続時間の両方を制限してください。なぜなら、1つの遅い動作が小さなリトライ数でも運用限界を超える可能性があるからです。
回復状態が変わる前に最初の故障を保持する
マップのクリア、サーバーの再起動、ロボットの移動などで証拠が消されることがあります。最初の失敗したアクション、サーバーエラー、目標、経路、ポーズ、コストマップ、変換、関連するセンサーの年齢を記録してから、リカバリーブランチがそれらを変異させる。すべての記録を共通の時計に照合します。
最終エラーと回復履歴は別々に保管してください。もしスピンが後で失敗しても、インシデント報告における元のプランナーやローカライゼーションの誤りを置き換えるべきではありません。オペレーターは、起因と最後の失敗した介入の両方が必要です。
繰り返しの挑戦間で進行を要求する
再挑戦は、該当状態が変化した場合に正当化されます。すなわち、経路が有効になった、障害物がクリアされた、位置定位の信頼度が回復した、またはロボットが意味のある距離を移動した場合です。各部門の進捗を定義してください。ブロック条件を変更しずに成功を返すノードは、リトライ予算全体をリセットすべきではありません。
動きには進捗チェッカーを使い、他の作業には支部固有の条件を使いましょう。低速運転時の時間と距離のウィンドウを測定し、通常の慎重な動きが失速と間違われないようにしましょう。逆に、ベース排気量のない車輪の回転はナビゲーションの進行とは言えません。
| 回収行動 | 必要な許可 | 進捗の証拠 | 中止証拠 |
|---|---|---|---|
| 待って | エリアは安全にクリアできるかもしれません | 障害物や計画の変更 | 期限を過ぎました |
| コストマップはクリアです | 源は真実を再構築できる | 新たな観測が届く | 必要な出典不在 |
| スピン | クリアランスは回転を支えます | 新しい有効な観測または経路 | フットプリントリスクか、変化なしか |
| 下がれ | 後部スペースの確認済み | 局所トラップからの出口 | 不明または後方が遮断されている |
| サーバーを再起動 | 故障クラスは再起動を許可します | 準備態勢が現状化 | 繰り返しクラッシュや無効なデータ |
スピンとバックアップは物理的な操作として扱う
回転や後退アクションは実際の動きを要求します。フットプリントクリアランス、センサーのカバレッジ、ペイロードの安定性、近隣の人やサイトの許可を有効にする前に確認してください。空の研究フロアで許容される回収操作は、ラックや階段、共有作業場のそばでは禁止されることがあります。
ロボットのリスク評価から加速度、速度、距離、持続時間の制限を設定します。キャンセルレイテンシと応答停止を確認しましょう。後方検知が不十分の場合、前方管制官が経路を報告しなかったからといってバックアップが安全であるとは限りません。
既知のステールステート障害にのみコストマップクリアリングを使用する
クリアリングは環境に合わない観測を除去するかもしれませんが、一時的に本当の障害物を消すこともあります。クリアリングは、現在のセンサーから迅速にデータを再構築でき、かつソースの健康状態が確認される層や領域に限定します。
クリア後は、計画や動議を再開する前に、宣言された更新条件を待ちましょう。どの層とエリアが変更されたかを記録してください。繰り返しクリアリングが一時的に道を開くことは、知覚、変換、クリアの欠陥の証拠であり、長期的な回復の成功とは言えません。
再計画のトリガーは意図的に選ぶ
再計画は、道が無効になったり、目標が変わったり、進捗が停滞したりしたときに定期的に行われます。過度な再計画はCPUを消費し、ルートのチャーンを引き起こすことがあります。計画の再計画がまばらになると、コントローラーが時代遅れの道をたどってしまうことがあります。トリガーを環境のダイナミクスとコントローラーのコントラクトに合わせて調整します。
Nav2例の木には、異なる再計画の配置が含まれています。交換時の経路年齢、計算時間、コントローラの挙動を測定します。新たに計算された経路が検証され、時間的に整合性があるかを確認してから、現在たどっている経路を上書きします。
異なるツリー枝へのマップサーバーエラー
プランナー、コントローラー、行動アクションは構造化された結果を返します。すべての失敗した状態を一つのフォールバックにまとめてはいけません。キャンセル、タイムアウト、無効な目標、パスなし、進行失敗、変換の問題、インターフェースがそれらを露出したサーバーの可用性を区別してください。
バージョン管理されたエラーからポリシーへのテーブルを維持しましょう。未知のエラーコードは保守的なデフォルトパスを取り、テレメトリ上で見えるべきです。ソフトウェアのアップグレードで結果コードが追加されたり変更されたりする際、回帰テストは各コードが意図したブランチに到達していることを証明すべきです。
座標キャンセルとプリエンプション
新たなミッション目標、オペレーター停止、またはフリート再割り当てにより、回収中の航行が先取りされることがあります。どの動作が停止されるか、キャンセルにかかる時間、そして部分的に完了した操作がロボットを有効な状態に残すかどうかを定義します。古いモーションの所有権が曖昧なまま、新しい目標を始めないでください。
待機、クリア、スピン、バックアップ、サーバーコール内でプリエンプションをテストします。リクエスターと最終行動の結果を記録してください。中断なく正しい挙動ツリーでも、キャンセル確認とコマンドタイムアウトが調整されていなければ、ステイルモーションを発行し得ます。
すべての回復レベルでフォルトを注入します
ブロックされた計画、動く障害物、センサーの喪失、変形の不一致、無効なポーズ、サーバークラッシュ、拒否されたコマンド、失敗した回復動作に対して繰り返しテストを作成できます。各ケースで、選択した分岐、試み回数、経過時間、物理出力、最終結果をミッション層に返す検証を行います。
CPUやネットワーク負荷、そして現実的なペイロードでテストを実行しましょう。バックアップ中のローカライゼーション喪失や、新しい目標が到達する際のコントローラ再起動などの複合的な失敗も含めてください。復旧ポリシーは、障害の発生を隠さずに中断を処理している場合にのみ信頼性があります。
制限付きかつ可観測可能な回収契約を解除する
XML、プラグインセット、エラーマッピング、リトライ予算、操作権限、タイムアウト値をまとめてバージョン化します。何が失敗したか、どの復旧が進行中か、次に何が起こるかを示すオペレーターが読みやすい状態を公開します。一般的な回復ラベルでは、繰り返しの物理的動作では不十分です。
証拠と退去条件を強調したリリースチェックリストを使いましょう。
- 失敗したアクションの近くにコンテキスト修理を置いてください。
- バウンドの試みと壁時計の回復時間。
- 再挑戦する前に測定可能な状態の変化を求めてください。
- 元の故障とすべての介入を保存してください。
- テストのキャンセルと物理的な操縦制限。
よくある質問
Nav2挙動ツリーは何を制御するのでしょうか？
XMLポリシーに従って Nav2 サーバーを呼び出してナビゲーションアクション、条件、再試行、復旧を調整します。
すべての失敗が両方のコストマップをクリアすべきでしょうか？
いいえ。明確なのは、古い地図の状態が支持された仮説であり、現在の情報源が有効な証拠を再構築できる場合に限られます。
回復リトライは何回許されるべきでしょうか？
故障ごとのカウントと運用リスクと測定された回収効果から時間予算を設定すること;普遍的な数字は存在しません。
スピニングはいつも安全な回復なのでしょうか？
いいえ。これはクリアランス、センシング、動作制限、そしてサイト許可を必要とする物理的な操作です。
回復中に何を記録しるべきでしょうか？
最初のエラー、状態スナップショット、各介入、進捗証拠、試み回数、タイミング、最終結果を保存します。
回復運動と故障境界
行動樹復元はロボットの動きを指令し、環境状態を変えることができます。これは、申請で求められる独立した停止、安全、またはオペレーター手順に代わるものではありません。