MPPI クリティックのデバッグとチューニング

ArtefactsパラメトリゼーションでMPPIクリティックのコストをデバッグし、ウェイトをチューニングする

Categories:

概要

Model Predictive Path Integral (MPPI) は最適な軌道を選択するためのサンプリングベースの予測コントローラーで、ロボティクスコミュニティで一般的に使用され、Nav2スタックによって十分にサポートされています。

Nav2のMPPIプラグインのコア機能はその目的関数(クリティック)のセットであり、ロボットプランナーに望ましい動作を達成するためにチューニングできます。

このデモでは、ロボット（Locobot）が後退移動を避けるべきターゲット動作を調査します。これは（ロボティクス実践者によって好まれ、）。また屋内環境での安全上の懸念によるもので、人間やペットがいる可能性があり、標準的なロボット(つまり: 前面センサーのみを持つ)が観測/認識なしに後退することは危険です。

この動作は、急旋回またはロボットに振り向くように求める再計画時(大きな角度距離)に、Nav2 MPPIのPath Angleクリティックが通常アクティブ化されスコアリングに貢献するために発生することが多いです。しかし、計画されたパスとの効率的な角度アライメントを達成するためにロボットを後退移動させる傾向があります。

初期アイデア

最も直感的なソリューションはPrefer Forwardクリティックを使用し、そのウェイトをPath Angleクリティックよりも高いコスト貢献になるようチューニングして、後退動作に対抗することです。しかし、手動でこれをチューニングする場合(つまり: 盲目的にウェイトを調整する)、いくつかの疑問が残ります:

これらのコストを実際の値で数値的にどのように見るか? そして2つのメトリック間でどちらが高いか比較するか
異なる潜在的なウェイト値(どのクリティックか不確実な場合は多数になる可能性)を結果軌道と並行して迅速かつ簡単に検証する方法は?

Artefactsを使用して、これらの答えをサポートします:

数値的なクリティックコストデバッグ: この機能はROS Kiltedのために最近開発されたもので、Nav2によるものです。私たちはそのMPPIプラグインをHumbleバージョンに移行し、プロッティングツールキットに統合しました。
パラメトリゼーションされたウェイト値: これらのパラメトリゼーションされたシナリオをクラウドインフラストラクチャで並列に迅速に実行し、Artefactsダッシュボードのラン比較で結果軌道と並行してクリティックコストを簡単に表示します。

テストのパラメトリゼーション

artefacts.yamlはテストをセットアップし、次のようにパラメトリゼーションします:

nav2_mppi_tuning:
    type: test
    runtime: 
      framework: ros2:humble
      simulator: gazebo:harmonic
    timeout: 10 # minutes
    scenarios:
      defaults:
        output_dirs: ["output"]
        metrics: "output/metrics.json"

        params:
          controller_server/FollowPath.PreferForwardCritic.cost_weight: [0.0, 5.0, 70.0] 

      settings:
        - name: reach_goal
          pytest_file: "src/locobot_gz_nav2_rtabmap/test/test_mppi.py"

キーポイント:

テストはpytestを使用して実施され、pytest_fileは私たちのテストファイルを指します
Artefactsはoutput_dirsで定義されたフォルダ内のファイルを収集し、ダッシュボードにアップロードします。
controller_server/FollowPath.PreferForwardCritic.cost_weight: ウェイト値をパラメトリゼーションします(クリティックコストデバッグプロットの観察後に取得)。ここでの構文はROSパラメータを示し、このフォーマットに従います: [NODE]/[PARAM]、そしてNav2パラメータ.yamlファイルで見つけることができます。

テストは3つのウェイト値で3回実行されます: 0.0(貢献なし)、5.0(中程度の貢献)、70.0(高い貢献)。

クイック分析

Artefactsダッシュボードのラン比較はクリティックデバッグプロット(“Critics vs Time”)と結果軌道プロット(“odom vs gt positions”)を可視化します。ここでodomはロボットの推定オドメトリで無視でき、gtグラウンドトゥルースポジションに注意を払います。

クリティックデバッグプロットでは、1つのクリティックをダブルクリックし、次に任意の次のクリティックをシングルクリックすることで、関心のあるクリティックを分離できます:

ウェイト0.0はゼロコスト貢献をもたらし、ウェイト5.0はPreferForwardCritic貢献をPathAngleCriticとほぼ同じに上げ、一方ウェイト70.0はその貢献を十分に上回ることができることがわかります。

軌道プロット(HTMLまたはCSVフォーマット)はPreferForwardCritic貢献の増加の影響を示します:

PreferForwardCriticの貢献がPathAngleCriticを上回るまで(ウェイト70.0)、ロボットのいくつかの「後退移動」動作が残り、一方ウェイト70.0はLocobotが前進のみすることを成功裏に保証できることがわかります。

出力ビデオも結果を確認します:

min_velocity_x、traverse_time、traverse_dist、PreferForwardCritic.costs_meanなどの数値メトリックは、可視化なしで結果を迅速に検証するために使用できます:

備考

PreferForwardCritic(ソフト制約)はロボットの後退を避けるためのチューニングプロセスでこのデモでターゲットとされましたが、別のアプローチは単にvx_min = 0.0(ハード制約)を設定することで、これはコントローラーが負の前進速度をサンプリングすることを防ぎます(本質的に後退の厳格な禁止)。「ソフト制約」のウェイトを増やすと前進移動がはるかに可能性が高くなりますが、すべての前進サンプルが悪い場合(つまり: パスがブロックされている、狭い廊下でゴールがロボットの後ろにある)、MPPIは後退軌道を選択できますが、これは「ハード制約」の場合は不可能です。

しかし、一般的な慣行として最も単純なアプローチ(vx_min = 0.0の設定)から始める場合、または後退動作が望ましくない他の状況に対処しようとする場合(つまり: 後退移動でのステアリング問題、またはロボットが単に後退できず、狭い廊下にいる)、同様のパラメトリゼーションされたテストプロセスは、Artefacts .yamlコンフィギュレーションを拡張する(新しいジョブを追加する)ことで単純に実施できます。

テスト後に利用可能なデータ

ROSbag
ログ
Locobotのビデオ/イメージ
jsonフォーマットのメトリック
HTMLフォーマットのクリティックデバッグプロット
HTML、CSVフォーマットの軌道

Artefactsツールキットヘルパー

このプロジェクトでは、Artefacts Toolkitから次のヘルパーを使用しました:

get_artefacts_params: どのPreferForwardCriticウェイト値を使用するかを決定するため
extract_video: 記録されたrosbagからビデオを作成しました

最終更新 22.12.2025: Fix incorrect UV guidance (#78) (479af07)