Model Predictive Path Integral Controller

源代码在 Github.

MPPI 控制器实现了“模型预测路径积分控制器 <https://ieeexplore.ieee.org/document/7487277>”。

新的 Nav2 MPPI 控制器是一种预测控制器 - TEB 和纯路径跟踪 MPC 控制器的后继者。它使用基于采样的方法来选择最佳轨迹，并在连续迭代之间进行优化。它包含基于插件的目标函数，用于定制和扩展各种行为和行为属性。

它目前适用于差分、全向和阿克曼机器人。

该控制器在适中的英特尔处理器（第 4 代 i5）上以 50+ Hz 的速度运行。

MPPI 算法是一种 MPC 变体，它使用迭代方法为机器人找到控制速度。使用前一个时间步骤的最佳控制解决方案和机器人的当前状态，应用一组来自高斯分布的随机采样扰动。这些噪声控制经过前向模拟，在机器人的运动模型中生成一组轨迹。接下来，使用一组基于插件的批评函数对这些轨迹进行评分，以找到批次中的最佳轨迹。输出分数用于使用软最大函数设置最佳控制。然后重复此过程多次并返回收敛解决方案。然后将此解决方案用作下一个时间步骤的初始控制的基础。

这项工作的一个强大结果是能够利用不需要凸或可微的目标函数，从而为设计者提供更大的行为灵活性。

有关更完整的信息，请参阅软件包的“README”。

MPPI 参数

motion_model:

Type	Default
string	“DiffDrive”

Description: 用于轨迹规划的所需运动模型。选项包括“DiffDrive”、“Omni”或“Ackermann”。差速驱动机器人可以使用正向/反向和角速度；Omni 添加横向运动；Ackermann 添加最小曲率约束。

critics:

Type	Default
string vector	N/A

Description: 要使用的评论家插件函数向量，没有“mppi::critic::”命名空间，该命名空间将在加载时自动添加。

iteration_count:

Type	Default
int	1

Description: MPPI 算法中的迭代次数。建议保留为 1，并且优先选择更大的批量大小。

batch_size:

Type	Default
int	1000

Description: 在给定迭代中从当前最佳控制序列中随机采样的候选轨迹的数量。1000 @ 50 Hz 或 2000 @ 30 Hz 似乎可以产生良好的结果。

time_steps:

Type	Default
int	56

Description: 候选轨迹中的时间步长（点）数

model_dt:

Type	Default
double	0.05

Description: 每个时间步长的“dt”时间步的长度，以秒为单位。“time_steps * model_dt”是预测范围。

vx_std:

Type	Default
double	0.2

Description: Vx 的抽样标准差

vy_std:

Type	Default
double	0.2

Description: Vy 的抽样标准差

wz_std:

Type	Default
double	0.2

Description: Wz（角速度）的抽样标准差

vx_max:

Type	Default
double	0.5

Description: 目标最大前进速度（米/秒）。

vy_max:

Type	Default
double	0.5

Description: 如果使用“Omni”运动模型，目标最大横向速度（m/s）。

vx_min:

Type	Default
double	-0.35

Description: 最大反向速度（米/秒）。

wz_max:

Type	Default
double	1.9

Description: 最大旋转速度（弧度/秒）。

ax_max:

Type	Default
double	3.0

Description: 最大前向加速度（m/s^2）。

ay_max:

Type	Default
double	3.0

Description: 如果使用“Omni”运动模型，则任一方向的最大横向加速度（m/s^2）。

ax_min:

Type	Default
double	-3.0

Description: 沿 X 轴的最大减速度（m/s^2）。

az_max:

Type	Default
double	3.5

Description: 最大角加速度（rad/s^2）。

temperature:

Type	Default
double	0.3

Description: 根据成本选择轨迹（该值越接近 0，我们考虑成本较低的控制就“越多”），0 表示使用成本最佳的控制，巨大的值将导致仅取所有轨迹的平均值而不考虑成本。

gamma:

Type	Default
double	0.015

Description: 平滑度（高）和低能量（低）之间的权衡。这是一个复杂的参数，可能不需要从默认值更改。有关详细信息，请参阅“信息理论模型预测控制：自动驾驶的理论和应用”中的第 3D-2 节。

visualize:

Type	Default
bool	false

Description: 是否发布调试轨迹以供可视化。这会大大降低控制器的速度（例如，每 30hz 1000 个 56 大小的批次是大量数据）。

retry_attempt_limit:

Type	Default
int	1

Description: 在报告彻底失败之前，尝试寻找软复位可行失败轨迹的次数。

reset_period:

Type	Default
double	1.0

Description: 重置优化器所需的不活动时间（由于反向移植 ABI 策略，仅在 Humble 中）。

regenerate_noises:

Type	Default
bool	false

Description: 是否在每次迭代时重新生成噪声或使用在初始化和重置时计算的单一噪声分布。实际上，这被发现工作得很好，因为轨迹是从正态分布中随机采样的，并且减少了由于线程唤醒以重新采样正态分布而导致的运行时计算抖动。

轨迹可视化

trajectory_step:

Type	Default
int	5

Description: 轨迹之间的步骤可视化以对候选轨迹池进行下采样。

time_step:

Type	Default
int	3

Description: 轨迹上点之间的步骤可视化以降低轨迹密度的采样。

路径处理器

transform_tolerance:

Type	Default
double	0.1

Description: 使用 TF（s）进行数据转换的时间容差。

prune_distance:

Type	Default
double	1.5

Description: 路径上距离机器人最近点的距离（米）

max_robot_pose_search_dist:

Type	Default
double	Costmap size / 2

Description: 当路径循环时，搜索机器人位姿前方最近路径点的最大综合距离。

enforce_path_inversion:

Type	Default
bool	false

Description: 如果为 true，它将修剪包含改变方向（例如路径反转）的段的尖点的路径，这样控制器将被迫在规划器请求的反转点处或非常接近该点处改变方向。这针对的是具有可行路径的 Smac Planner 用户，他们需要机器人在特定请求时切换方向。

inversion_xy_tolerance:

Type	Default
double	0.2

Description: 与路径反转点的笛卡尔接近度 (m) 被认为“已实现”，以便在路径反转之后传递剩余路径。

inversion_yaw_tolerance:

Type	Default
double	0.4

Description: 与路径反转点的角度接近度（弧度）被认为“实现”以在路径反转后传递剩余路径。0.4 弧度 = 23 度。

阿克曼运动模型

min_turning_r:

Type	Default
double	0.2

Description: 车辆平台可能的最小转弯半径（米）。

限制性批评家

该批评者会惩罚那些超出设定的动态或运动学约束的轨迹

cost_weight:

Type	Default
double	4.0

Description: Weight to apply to critic term.

cost_power:

Type	Default
int	1

Description: 权力令适用于任期。

目标角度评论家

当距离目标较近时，该批评者会激励导航以达到目标姿势的角度

cost_weight:

Type	Default
double	3.0

Description: 适用于批评术语的权重。

cost_power:

Type	Default
int	1

Description: 权力令适用于任期。

threshold_to_consider:

Type	Default
double	0.5

Description: 机器人与目标之间的最小距离（米），超过该距离则考虑角度目标成本。

Goal Critic

当距离目标合理接近时，该批评者会激励在空间上向目标导航

cost_weight:

Type	Default
double	5.0

Description: 适用于批评术语的权重。

cost_power:

Type	Default
int	1

Description: 权力令适用于任期。

threshold_to_consider:

Type	Default
double	1.4

Description: 机器人与目标之间的最小距离（米），超过此距离则要考虑目标距离成本。明智的做法是将此距离作为您的预测范围，以便与路径跟随器评论家进行干净的交接。

Obstacles Critic

该评论家通过使用圆形机器人点检查或使用与障碍物的距离的完整 SE2 足迹检查来激励机器人避开障碍物和关键碰撞。

critical_weight:

Type	Default
double	20.0

Description: 应用于临界点的权重，用于在比“collision_margin_distance”更近的近距离碰撞中防止近距离碰撞，**仅**是作为一种虚拟膨胀足迹的方法。这不应该被用来影响远离临界碰撞的避障。

repulsion_weight:

Type	Default
double	1.5

Description: 应用于批评者的权重，通常优先选择成本较低的空间中的路线。这与关键术语分开，以便对动态场景中的障碍物行为进行路径对齐微调，而不会影响可能直接导致近距离碰撞的动作。这适用于距离障碍物的“inflation_radius”距离内。

cost_power:

Type	Default
int	1

Description: 权力令适用于任期。

consider_footprint:

Type	Default
bool	false

Description: 是否使用点成本（如果机器人是圆形的或者计算能力低）或计算 SE2 足迹成本。

collision_cost:

Type	Default
double	100000.0

Description: 应用于轨迹中真实碰撞的成本。

collision_margin_distance:

Type	Default
double	0.10

Description: 距离碰撞的边距（米）以施加严厉惩罚，类似于足迹膨胀。0.05-0.2 之间是合理的。请注意，这将极大地影响控制器不进入比这更狭窄的空间，因此请确保将此参数设置为低于您预计机器人需要穿越的最窄空间。

near_goal_distance:

Type	Default
double	0.50

Description: 靠近目标的距离（米）停止应用优先障碍物项，以允许机器人平稳地收敛到靠近障碍物的目标姿势。

cost_scaling_factor:

Type	Default
double	10.0

Description: 膨胀半径内的指数衰减因子。这应该与膨胀层相同（仅限 Humble）

inflation_radius:

Type	Default
double	0.55

Description: 致命障碍物周围成本地图膨胀的半径。这应该与膨胀层相同（仅限 Humble）

inflation_layer_name:

Type	Default
string	“”

Description: 膨胀层的名称。如果为空，则使用成本图中的最后一个膨胀层。如果您有多个膨胀层，您可能需要指定要使用的层的名称。

Cost Critic

该评论家通过使用代价地图值的圆形机器人点检查或完整 SE2 足迹检查来激励机器人避开障碍物和关键碰撞。

cost_weight:

Type	Default
double	3.81

Description: Weight to apply to critic.

cost_power:

Type	Default
int	1

Description: 权力令适用于任期。

consider_footprint:

Type	Default
bool	false

Description: 是否使用点成本（如果机器人是圆形的或者计算能力低）或计算 SE2 足迹成本。

collision_cost:

Type	Default
double	1000000.0

Description: 应用于轨迹中真实碰撞的成本。

critical_cost:

Type	Default
double	300.0

Description: 在充气空间中任意点应用姿势以与障碍物保持较远距离的成本。

near_goal_distance:

Type	Default
double	0.50

Description: 靠近目标的距离（米）停止应用优先障碍物项，以允许机器人平稳地收敛到靠近障碍物的目标姿势。

inflation_layer_name:

Type	Default
string	“”

Description: 膨胀层的名称。如果为空，则使用成本图中的最后一个膨胀层。如果您有多个膨胀层，您可能需要指定要使用的层的名称。

trajectory_point_step:

Type	Default
int	2

Description: 在评论家评估轨迹时要采取的步骤。由于轨迹非常密集，因此没有必要评估每个点，而且计算成本很高。

Path Align Critic

如果相关，此批评家会激励与全局路径保持一致。它不实现路径跟随行为。

cost_weight:

Type	Default
double	10.0

Description: 适用于批评术语的权重。

cost_power:

Type	Default
int	1

Description: 权力令适用于任期。

threshold_to_consider:

Type	Default
double	0.5

Description: 机器人与目标之间的距离（米）**停止**考虑路径对齐并允许目标批评者接管。

offset_from_furthest:

Type	Default
int	20

Description: 检查候选轨迹是否在跟踪路径的过程中走了足够远以应用对齐评判器。这可确保仅在实际跟踪路径时才考虑路径对齐，从而防止尴尬的初始化动作阻止机器人偏离路径以实现适当的航向。

max_path_occupancy_ratio:

Type	Default
double	0.07

Description: 在不考虑此批评者之前可以占用的路径的最大比例，以允许障碍物和路径跟随批评者在场景中存在动态物体的情况下避开障碍物，同时遵循路径的意图。0-1 之间为 0-100%。

use_path_orientations:

Type	Default
bool	false

Description: 是否在路径对齐中考虑路径的方向，这在与可行的 smac 规划器配合使用时非常有用，可以仅在 smac 规划器要求时激励方向变化。如果您希望机器人在控制器认为合适的地方偏离和反转方向，请保留为 false。如果您的计划不包含方向信息（例如 navfn），请保留为 false。

trajectory_point_step:

Type	Default
int	4

Description: 在评论家评估轨迹时要采取的步骤。由于轨迹非常密集，因此没有必要评估每个点，而且计算成本很高。

Path Angle Critic

此批评者会惩罚与路径成较大相对角度的轨迹。这有助于机器人在因累积角度误差较大而需要时进行急转弯。

cost_weight:

Type	Default
double	2.2

Description: Weight to apply to critic term.

cost_power:

Type	Default
int	1

Description: Power order to apply to term.

threshold_to_consider:

Type	Default
double	0.5

Description: 机器人与球门之间的距离（米）**停止**考虑路径角度并允许球门批评家接管。

offset_from_furthest:

Type	Default
int	20

Description: 任何轨迹达到最远路径点之后的路径点数，用于计算相对于的路径角度。

max_angle_to_furthest:

Type	Default
double	0.785398

Description: 机器人与目标之间的角距离（rad），超过该距离后开始考虑路径角度成本

mode:

Type	Default
int	0

Description: 根据路径输入类型和行为需求，路径角度批评器的操作模式的枚举类型。0：前向偏好，惩罚相对于机器人方向的大路径角度以激励转向路径。1：无方向偏好，当某个特定的行进方向不可取时，惩罚相对于机器人方向或镜像方向（例如反向）的大路径角度，以较小者为准。2：考虑可行的路径方向，当使用可行路径时，而路径点具有方向信息（例如 Smac 规划器），考虑路径请求的行进方向来惩罚路径角度，使得机器人将按照请求的方向遵循路径。

Path Follow Critic

这个批评者激励机器人沿着路径前进。这就是推动机器人沿着路径前进的动力。

cost_weight:

Type	Default
double	5.0

Description: 适用于批评术语的权重。

cost_power:

Type	Default
int	1

Description: Power order to apply to term.

threshold_to_consider:

Type	Default
double	1.4

Description: 机器人与目标之间的距离（米），停止考虑路径跟随，并允许目标评论家接管。明智的做法是将此作为您的预测范围开始，以便与目标评论家进行干净的交接。

offset_from_furthest:

Type	Default
int	6

Description: 任何轨迹达到最远路径点之后的路径点数，相对于该路径点驱动路径跟踪。

Prefer Forward Critic

This critic incentivizes moving in the forward direction, rather than reversing.

cost_weight:

Type	Default
double	5.0

Description: Weight to apply to critic term.

cost_power:

Type	Default
int	1

Description: Power order to apply to term.

threshold_to_consider:

Type	Default
double	0.5

Description: 机器人与球门之间的距离（米）**停止**考虑向前推进，并允许球门批评者接管。

Twirling Critic

此批评者惩罚了完整车辆不必要的“扭曲”。它对旋转角度增加了限制，以使其保持一致。

cost_weight:

Type	Default
double	10.0

Description: Weight to apply to critic term.

cost_power:

Type	Default
int	1

Description: Power order to apply to term.

Velocity Deadband Critic

该批评家对低于死区阈值的速度进行惩罚，有助于减轻某些平台上的硬件限制。

cost_weight:

Type	Default
double	35.0

Description: Weight to apply to critic term.

cost_power:

Type	Default
int	1

Description: Power order to apply to term.

deadband_velocities:

Type	Default
array of double	[0.05, 0.05, 0.05]

Description: The array of deadband velocities [vx, vz, wz]. A zero array indicates that the critic will take no action.

Example

controller_server:
  ros__parameters:
    controller_frequency: 30.0
    FollowPath:
      plugin: "nav2_mppi_controller::MPPIController"
      time_steps: 56
      model_dt: 0.05
      batch_size: 2000
      vx_std: 0.2
      vy_std: 0.2
      wz_std: 0.4
      vx_max: 0.5
      vx_min: -0.35
      vy_max: 0.5
      wz_max: 1.9
      ax_max: 3.0
      ax_min: -3.0
      ay_max: 3.0
      az_max: 3.5
      iteration_count: 1
      prune_distance: 1.7
      transform_tolerance: 0.1
      temperature: 0.3
      gamma: 0.015
      motion_model: "DiffDrive"
      visualize: false
      reset_period: 1.0 # (only in Humble)
      regenerate_noises: false
      TrajectoryVisualizer:
        trajectory_step: 5
        time_step: 3
      AckermannConstraints:
        min_turning_r: 0.2
      critics: ["ConstraintCritic", "CostCritic", "GoalCritic", "GoalAngleCritic", "PathAlignCritic", "PathFollowCritic", "PathAngleCritic", "PreferForwardCritic"]
      ConstraintCritic:
        enabled: true
        cost_power: 1
        cost_weight: 4.0
      GoalCritic:
        enabled: true
        cost_power: 1
        cost_weight: 5.0
        threshold_to_consider: 1.4
      GoalAngleCritic:
        enabled: true
        cost_power: 1
        cost_weight: 3.0
        threshold_to_consider: 0.5
      PreferForwardCritic:
        enabled: true
        cost_power: 1
        cost_weight: 5.0
        threshold_to_consider: 0.5
      # ObstaclesCritic:
      #   enabled: true
      #   cost_power: 1
      #   repulsion_weight: 1.5
      #   critical_weight: 20.0
      #   consider_footprint: false
      #   collision_cost: 10000.0
      #   collision_margin_distance: 0.1
      #   near_goal_distance: 0.5
      #   inflation_radius: 0.55 # (only in Humble)
      #   cost_scaling_factor: 10.0 # (only in Humble)
      CostCritic:
        enabled: true
        cost_power: 1
        cost_weight: 3.81
        critical_cost: 300.0
        consider_footprint: true
        collision_cost: 1000000.0
        near_goal_distance: 1.0
        trajectory_point_step: 2
      PathAlignCritic:
        enabled: true
        cost_power: 1
        cost_weight: 14.0
        max_path_occupancy_ratio: 0.05
        trajectory_point_step: 4
        threshold_to_consider: 0.5
        offset_from_furthest: 20
        use_path_orientations: false
      PathFollowCritic:
        enabled: true
        cost_power: 1
        cost_weight: 5.0
        offset_from_furthest: 5
        threshold_to_consider: 1.4
      PathAngleCritic:
        enabled: true
        cost_power: 1
        cost_weight: 2.0
        offset_from_furthest: 4
        threshold_to_consider: 0.5
        max_angle_to_furthest: 1.0
        mode: 0
      # VelocityDeadbandCritic:
      #   enabled: true
      #   cost_power: 1
      #   cost_weight: 35.0
      #   deadband_velocities: [0.05, 0.05, 0.05]
      # TwirlingCritic:
      #   enabled: true
      #   twirling_cost_power: 1
      #   twirling_cost_weight: 10.0

Notes to Users

General Words of Wisdom

The model_dt parameter generally should be set to the duration of your control frequency. So if your control frequency is 20hz, this should be 0.05. However, you may also set it lower but not larger.

Visualization of the trajectories using visualize uses compute resources to back out trajectories for visualization and therefore slows compute time. It is not suggested that this parameter is set to true during a deployed use, but is a useful debug instrument while tuning the system, but use sparingly. Visualizing 2000 batches @ 56 points at 30 hz is a lot.

The most common parameters you might want to start off changing are the velocity profiles (vx_max, vx_min, wz_max, and vy_max if holonomic) and the motion_model to correspond to your vehicle. Its wise to consider the prune_distance of the path plan in proportion to your maximum velocity and prediction horizon. The only deeper parameter that will likely need to be adjusted for your particular settings is the Obstacle critics’ repulsion_weight since the tuning of this is proprtional to your inflation layer’s radius. Higher radii should correspond to reduced repulsion_weight due to the penalty formation (e.g. inflation_radius - min_dist_to_obstacle). If this penalty is too high, the robot will slow significantly when entering cost-space from non-cost space or jitter in narrow corridors. It is noteworthy, but likely not necessary to be changed, that the Obstacle critic may use the full footprint information if consider_footprint = true, though comes at an increased compute cost.

Otherwise, the parameters have been closely pre-tuned by your friendly neighborhood navigator to give you a decent starting point that hopefully you only need to retune for your specific desired behavior lightly (if at all). Varying costmap parameters or maximum speeds are the actions which require the most attention, as described below:

Prediction Horizon, Costmap Sizing, and Offsets

As this is a predictive planner, there is some relationship between maximum speed, prediction times, and costmap size that users should keep in mind while tuning for their application. If a controller server costmap is set to 3.0m in size, that means that with the robot in the center, there is 1.5m of information on either side of the robot. When your prediction horizon (time_steps * model_dt) at maximum speed (vx_max) is larger than this, then your robot will be artificially limited in its maximum speeds and behavior by the costmap limitation. For example, if you predict forward 3 seconds (60 steps @ 0.05s per step) at 0.5m/s maximum speed, the minimum required costmap radius is 1.5m - or 3m total width.

The same applies to the Path Follow and Align offsets from furthest. In the same example if the furthest point we can consider is already at the edge of the costmap, then further offsets are thresholded because they’re unusable. So its important while selecting these parameters to make sure that the theoretical offsets can exist on the costmap settings selected with the maximum prediction horizon and velocities desired. Setting the threshold for consideration in the path follower + goal critics as the same as your prediction horizon can make sure you have clean hand-offs between them, as the path follower will otherwise attempt to slow slightly once it reaches the final goal pose as its marker.

The Path Follow critic cannot drive velocities greater than the projectable distance of that velocity on the available path on the rolling costmap. The Path Align critic offset_from_furthest represents the number of path points a trajectory passes through while tracking the path. If this is set either absurdly low (e.g. 5) it can trigger when a robot is simply trying to start path tracking causing some suboptimal behaviors and local minima while starting a task. If it is set absurdly high (e.g. 50) relative to the path resolution and costmap size, then the critic may never trigger or only do so when at full-speed. A balance here is wise. A selection of this value to be ~30% of the maximum velocity distance projected is good (e.g. if a planner produces points every 2.5cm, 60 can fit on the 1.5m local costmap radius. If the max speed is 0.5m/s with a 3s prediction time, then 20 points represents 33% of the maximum speed projected over the prediction horizon onto the path). When in doubt, prediction_horizon_s * max_speed / path_resolution / 3.0 is a good baseline.

Obstacle, Inflation Layer, and Path Following

There also exists a relationship between the costmap configurations and the Obstacle critic configurations. If the Obstacle critic is not well tuned with the costmap parameters (inflation radius, scale) it can cause the robot to wobble significantly as it attempts to take finitely lower-cost trajectories with a slightly lower cost in exchange for jerky motion. It may also perform awkward maneuvers when in free-space to try to maximize time in a small pocket of 0-cost over a more natural motion which involves moving into some low-costed region. Finally, it may generally refuse to go into costed space at all when starting in a free 0-cost space if the gain is set disproportionately higher than the Path Follow scoring to encourage the robot to move along the path. This is due to the critic cost of staying in free space becoming more attractive than entering even lightly costed space in exchange for progression along the task.

Thus, care should be taken to select weights of the obstacle critic in conjunction with the costmap inflation radius and scale so that a robot does not have such issues. How I (Steve, your friendly neighborhood navigator) tuned this was to first create the appropriate obstacle critic behavior desirable in conjunction with the inflation layer parameters. Its worth noting that the Obstacle critic converts the cost into a distance from obstacles, so the nature of the distribution of costs in the inflation isn’t overly significant. However, the inflation radius and the scale will define the cost at the end of the distribution where free-space meets the lowest cost value within the radius. So testing for quality behavior when going over that threshold should be considered.

As you increase or decrease your weights on the Obstacle, you may notice the aforementioned behaviors (e.g. won’t overcome free to non-free threshold). To overcome them, increase the FollowPath critic cost to increase the desire for the trajectory planner to continue moving towards the goal. Make sure to not overshoot this though, keep them balanced. A desirable outcome is smooth motion roughly in the center of spaces without significant close interactions with obstacles. It shouldn’t be perfectly following a path yet nor should the output velocity be wobbling jaggedly.

Once you have your obstacle avoidance behavior tuned and matched with an appropriate path following penalty, tune the Path Align critic to align with the path. If you design exact-path-alignment behavior, its possible to skip the obstacle critic step as highly tuning the system to follow the path will give it less ability to deviate to avoid obstacles (though it’ll slow and stop). Tuning the critic weight for the Obstacle critic high will do the job to avoid near-collisions but the repulsion weight is largely unnecessary to you. For others wanting more dynamic behavior, it can be beneficial to slowly lower the weight on the obstacle critic to give the path alignment critic some more room to work. If your path was generated with a cost-aware planner (like all provided by Nav2) and providing paths sufficiently far from obstacles for your satisfaction, the impact of a slightly reduced Obstacle critic with a Path Alignment critic will do you well. Not over-weighting the path align critic will allow the robot to deviate from the path to get around dynamic obstacles in the scene or other obstacles not previous considered during path planning. It is subjective as to the best behavior for your application, but it has been shown that MPPI can be an exact path tracker and/or avoid dynamic obstacles very fluidly and everywhere in between. The defaults provided are in the generally right regime for a balanced initial trade-off.