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

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

---

Site [llms.txt](/ja/llms.txt)

---

[デモはこちらで利用可能](https://app.artefacts.com/artefacts-demos/locobot-gz-demo)。注意: 登録が必要です。

## 概要
[Model Predictive Path Integral (MPPI)](https://docs.nav2.org/configuration/packages/configuring-mppic.html) は最適な軌道を選択するためのサンプリングベースの予測コントローラーで、ロボティクスコミュニティで一般的に使用され、Nav2スタックによって十分にサポートされています。

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

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

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

## 初期アイデア

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

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

Artefactsを使用して、これらの答えをサポートします:
- **数値的な**クリティックコストデバッグ: この機能は[ROS Kiltedのために最近開発されたもの](https://github.com/ros-navigation/navigation2/tree/kilted/nav2_mppi_controller)で、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`グラウンドトゥルースポジションに注意を払います。

![](/images/example-projects/mppi/runs-comparison.png)

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

![](/images/example-projects/mppi/critics-debugging.png)

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

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

![](/images/example-projects/mppi/trajectories.png)

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

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

![](/images/example-projects/mppi/vids.gif)

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

![](/images/example-projects/mppi/metrics.png)


## 備考

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

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

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

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


## Artefactsツールキットヘルパー

このプロジェクトでは、[Artefacts Toolkit](/artefacts-toolkit)から次のヘルパーを使用しました:

* [`get_artefacts_params`](/artefacts-toolkit/config/#get_artefacts_params): どの`PreferForwardCritic`ウェイト値を使用するかを決定するため
* [`extract_video`](/artefacts-toolkit/rosbag/#image_topicsextract_video): 記録されたrosbagからビデオを作成しました
* [`make_chart`](/artefacts-toolkit/charts/#make_chart): 同一のHTMLチャート上に複数のプロットを作成し、クリティクスのデバッグをサポート