MPPI controller (Model Predictive Path Integral)

MPPI controller – definition

An MPPI controller, or Model Predictive Path Integral controller, is a sampling-based model predictive control method used to generate short-horizon velocity commands for a mobile robot. In UGV navigation, it evaluates many possible control sequences, predicts the robot motion for each sequence, assigns a cost to every predicted trajectory, and forms an updated command that favours low-cost trajectories.

MPPI is implemented in ROS 2 Navigation2 as the nav2_mppi_controller plugin. It can operate as the local controller in a Nav2 navigation stack, receiving a global path, current robot pose, local costmap, velocity limits, and robot motion model. The Nav2 controller server publishes velocity commands, typically on /cmd_vel, using geometry_msgs/msg/Twist or geometry_msgs/msg/TwistStamped, depending on the Nav2 version and configuration.

For a differential-drive UGV such as Leo Rover, MPPI generates linear velocity v_x and angular velocity ω_z. Lateral velocity v_y is constrained to zero because a differential-drive platform cannot move sideways without skidding. Raph Rover uses Ackermann steering, so it should use the MPPI Ackermann motion model instead.

How MPPI works in mobile robot navigation

At each control cycle, MPPI samples noise around a nominal control sequence. Every sampled sequence is propagated through a motion model over a finite prediction horizon. The controller then evaluates trajectory costs using critics such as obstacle proximity, path alignment, goal heading, velocity constraints, and reverse-motion penalties.

A simplified MPPI update model can be written as follows:

u* = u_nom + Σ wi εi

wi = exp(-Si / λ) / Σ exp(-Sj / λ)

In this expression, u_nom is the nominal control sequence, ε_i is the perturbation applied to a sampled sequence, S_i is its cumulative cost, and λ is the temperature parameter. A lower temperature increases preference for low-cost trajectories. A higher temperature produces more distributed weighting across sampled trajectories.

The controller does not create a global map or perform SLAM. It depends on upstream components for localization, route planning, transforms, and obstacle data. A typical ROS 2 navigation pipeline includes the following elements:

robot_localization or another state-estimation node for odometry and IMU fusion.
A TF tree compliant with REP 105, usually map → odom → base_link.
A global planner producing nav_msgs/msg/Path.
Local and global costmaps populated from map data, LiDAR, depth camera, or point-cloud observations.
The Nav2 controller server running the MPPI controller plugin.

MPPI in ROS 2 Navigation2

Navigation2 provides MPPI as a controller-server plugin. Its documented plugin class is nav2_mppi_controller::MPPIController. The exact available parameters can differ between ROS 2 distributions and Nav2 releases, so configuration should be verified against the documentation for the deployed Nav2 version.

The following YAML fragment shows a representative configuration for a differential-drive UGV. The values are examples from the Nav2 MPPI configuration model and must be tuned against the robot footprint, payload, wheel traction, braking behaviour, and compute capacity.

controller_server:
  ros__parameters:
    controller_plugins: ["FollowPath"]

    FollowPath:
      plugin: "nav2_mppi_controller::MPPIController"
      motion_model: "DiffDrive"
      time_steps: 56
      model_dt: 0.05
      batch_size: 2000
      iteration_count: 1
      vx_std: 0.2
      vy_std: 0.0
      wz_std: 0.4
      temperature: 0.3
      gamma: 0.015
      critics:
        ["ConstraintCritic", "CostCritic", "GoalCritic",
         "GoalAngleCritic", "PathAlignCritic", "PathFollowCritic",
         "PathAngleCritic", "PreferForwardCritic"]

With time_steps: 56 and model_dt: 0.05, the prediction horizon is 2.8 seconds. This follows directly from 56 × 0.05 s. The Nav2 documentation identifies these parameters as the number of trajectory points and the motion-model integration period.

Key parameters and integration requirements

MPPI performance depends on both controller tuning and input quality. It is sensitive to incorrect robot geometry, delayed transforms, inconsistent odometry, and costmaps that do not represent nearby obstacles accurately.

Parameter or input	Function in a UGV system
`motion_model`	Selects the predicted kinematic model. Use `DiffDrive` for Leo Rover and `Ackermann` for Raph Rover.
`batch_size`	Defines the number of sampled trajectories evaluated per iteration. Larger values increase trajectory coverage and computational load.
`model_dt`	Defines the simulated interval between predicted states.
`time_steps`	Defines the number of points in each sampled trajectory.
`vx_std`, `wz_std`	Define sampling noise around linear and angular controls.
Robot footprint	Must match the physical chassis and attached sensors. It is used by costmap collision checking.

Use with Leo Rover and Raph Rover

Leo Rover can run ROS 2 on its onboard Raspberry Pi computer. MPPI can be used after integrating a complete navigation stack, but Leo Rover is not autonomous out of the box. The platform requires a localization source, valid wheel odometry, TF configuration, a costmap sensor, and a Nav2 setup.

For indoor or structured outdoor testing, a 2D LiDAR can provide obstacle observations for the local costmap. An IMU can improve orientation estimation when fused with wheel odometry. GNSS RTK may be used for outdoor global localization, but it does not replace short-range obstacle sensing required by the local costmap.

Raph Rover is suitable when the application requires a larger payload, such as a higher-mounted LiDAR, stereo camera, GNSS receiver, or an NVIDIA Jetson compute unit. The MPPI configuration must then use the Ackermann motion model with a measured minimum turning radius and be retuned for the larger footprint, velocity limits, safety margins, and stopping distance.

Limitations and trade-offs

MPPI is computationally heavier than simple trajectory-following controllers because it evaluates many sampled trajectories at every controller update. On embedded computers, excessive batch_size, long prediction horizons, dense costmaps, or multiple expensive critics can increase latency. The selected command can become stale if controller computation takes longer than the intended control period.

MPPI also depends on a valid local environment model. It cannot avoid obstacles missing from the sensor field of view or absent from the costmap. Dynamic obstacle handling is limited by sensor update latency, tracking quality, prediction assumptions, and the configured robot velocity limits.

Normative references and technical sources

The ROS coordinate-frame conventions relevant to MPPI integration are defined in REP 103 and REP 105. Nav2 configuration and controller behaviour are documented by the Navigation2 project.