In warehouse logistics robots, campus patrol robots, unmanned delivery vehicles, and outdoor mobile robot applications, a navigation system must do more than simply move a robot along a planned path. More importantly, it must perceive changes in the surrounding environment in real time and quickly make obstacle-avoidance decisions when hazards appear.

Within the ROS 2 ecosystem, Nav2 (Navigation2) has become a widely used navigation framework for mobile robots. MPPI (Model Predictive Path Integral), a local controller in Nav2, is well suited to improving path tracking, dynamic obstacle avoidance, and motion smoothness.

The basic idea behind MPPI is straightforward: during each control cycle, it generates a batch of candidate actions, uses a model to predict how those actions will evolve, and then evaluates them against criteria such as the reference path, obstacles, and the goal to determine the most appropriate control command.

01

What Problem Does MPPI Solve?

The global planner draws a reference route from the start point to the destination, while the local controller translates that route into real-time motion. In practice, the map, sensors, chassis controller, and surrounding environment all introduce deviations, so the robot must continuously correct its actions within a very short time window.

During every control cycle, MPPI generates a large number of candidate control sequences and predicts the trajectories the robot could follow over a short future horizon. It then scores these trajectories with a cost function and favors motion trends that are safer, smoother, and more goal-directed.

MPPI therefore acts like a local decision-making module with predictive capability: path tracking, obstacle avoidance, speed control, and attitude stability are weighed together within the same evaluation framework.

02

Core Workflow: Sampling, Prediction, Scoring, and Fusion

The MPPI workflow can be divided into four steps: sampling, prediction, scoring, and fusion. It first explores many possible ways to move, reduces the influence of high-risk options through scoring, and then combines the more reliable motion trends into the final control command.

Figure 1. MPPI core workflow: sampling, prediction, scoring, and fusion.

Control Sequence Sampling 

Similar to how DWB samples candidate velocities in velocity space, MPPI generates a large number of candidate control sequences around the current control input. Intuitively, the robot is simultaneously trying multiple combinations of speed and steering near its current state.

uᵢ = u + εᵢ

Here, u is the current control input, εᵢ is a random perturbation, and uᵢ is the i-th candidate control sequence.

These candidate sequences produce multiple potential motion trajectories, providing the basis for subsequent prediction and scoring.

Figure 2. Multiple candidate trajectories sampled around the current state.

Trajectory Prediction 

After sampling, MPPI uses the robot's motion model to predict future states for every candidate control sequence. In engineering terms, this is a short simulation: the robot first runs each option through the model to see where it would be after 0.5 s, 1.0 s, 1.5 s, and 2.0 s.

xₜ₊₁ = f(xₜ, uₜ)

Here, xₜ is the current state, uₜ is the control input, and f is the robot motion model.

This step allows the system to identify in advance whether a trajectory will approach an obstacle, deviate from the global path, or help the robot move toward the goal.

Figure 3. MPPI predicts future states for each candidate control sequence.

Critic Scoring 

Predicted trajectories cannot be executed directly; they must first be evaluated. Critics can be understood as independent scoring terms, each focusing on one dimension, such as path alignment, obstacle clearance, goal progress, or velocity constraints.

In practical applications, the following three types of critics are the most common and have the greatest impact on navigation performance:

Path Follow Critic: Measures how far a candidate trajectory deviates from the global path. The closer the trajectory stays to the path, the lower its cost.

Obstacle Critic: Measures the safety distance between the trajectory and obstacles. The closer the trajectory comes to an obstacle, the higher its cost.

Goal Critic: Measures whether the trajectory makes effective progress toward the goal. The closer the trajectory endpoint is to the goal, the lower its cost.

Nav2 MPPI also provides auxiliary critics such as Path Align, Goal Angle, Velocity Deadband, Prefer Forward, Twirling, Constraint, and Cost. These terms constrain heading, velocity, rotational behavior, and costmap risk. Which critics are enabled—and how their weights are configured—directly affects the final behavior in different scenarios.

The aggregate cost can be simplified as a weighted sum of multiple scoring terms:

J = Σ wₖ · Cₖ

Here, Cₖ is the cost produced by an individual critic and wₖ is its corresponding weight. A lower total cost indicates better overall trajectory performance.

Figure 4. Candidate trajectories evaluated by multiple critics.

Weight Fusion 

After scoring, MPPI converts the cost of each trajectory into a weight. Low-cost trajectories exert more influence, while high-cost trajectories have less influence.

ωᵢ ∝ exp(-(Jᵢ - Jₘᵢₙ) / λ)

This approach is more stable than selecting a single trajectory outright. It reduces abrupt switching between candidate trajectories and produces smoother control output.

03

How to Enable MPPI in Nav2

Enabling MPPI in Nav2 is straightforward. In nav2_params.yaml, set the FollowPath plugin to nav2_mppi_controller::MPPIController, and then configure the parameters for the robot platform and application scenario.

When tuning the controller, pay particular attention to the following parameters:

batch_size: The number of candidate trajectories sampled during each control cycle. A larger value provides a more thorough search but increases computational load.

time_steps: The number of future prediction steps, which determines how far ahead MPPI can look.

model_dt: The time interval between consecutive prediction steps.

critics and critic weights: Determine whether the robot prioritizes staying close to the path, keeping away from obstacles, or making more aggressive progress toward the goal.

The following is a reference configuration for differential-drive robot navigation. In a real project, the parameters must be iteratively tuned according to chassis dynamics, sensor field of view, costmap resolution, and operating speed.

Figure 5. MPPI controller parameter configuration example 1.

Figure 6. MPPI controller parameter configuration example 2.

Figure 7. MPPI critics and weight configuration example.

04

Simulation and Real-Robot Testing

In the Gazebo simulation environment, enabling MPPI allows the robot to generate smooth local trajectories on a map containing multiple static obstacles. Candidate trajectories explore different motion options, while the final output balances path tracking, obstacle-avoidance safety, and progress toward the goal.

Figure 8. MPPI navigation in a Gazebo simulation environment.

On a physical robot platform, MPPI performance is also affected by sensor data quality, localization stability, chassis control accuracy, computational resources, and parameter configuration. In an outdoor patrol scenario, for example, a robot traveling at approximately 1.2 m/s must quickly replan and steer around a person who suddenly appears ahead, while minimizing sudden stops, oscillation, and large deviations from the path.

Figure 9. Outdoor navigation and obstacle-avoidance demonstration on a real robot.

This is also one of the most frequently underestimated aspects of deploying navigation algorithms. The algorithm itself requires tuning, but mapping, localization, perception, control, computing power, and parameter settings must also work together. Instability in any one part will reduce the quality of the final experience.

05

From Algorithm Validation to Real-World Deployment

For research and education, robot development, and industrial validation, navigation algorithms such as MPPI must be tested on a physical platform before problems can be exposed and reusable engineering experience can be accumulated.

The AmovLab R300 indoor/outdoor autonomous navigation vehicle was designed around these validation needs. It ships with mapping, localization, and indoor/outdoor navigation capabilities. Its open-source code supports secondary development, reducing repetitive work in chassis adaptation, sensor integration, and navigation tuning so users can devote more time to algorithm validation, scenario iteration, and functional innovation.

The R300 can also be combined with AmovLab drone products to create air-ground coordination and swarm-operation solutions for inspection validation, teaching experiments, research and development, and multi-robot collaboration projects.