mppi-controller

Start from a baseline YAML with batch_size around 2000, time_steps of 56, and model_dt of 0.05, then enable visualize in RViz2 to observe trajectories. Adjust critic weights based on symptoms: raise CostCritic weight for wall-hugging, or GoalCritic weight for goal overshoot.

The prediction horizon equals time_steps multiplied by model_dt. For example, 56 steps at 0.05 seconds gives a 2.8-second lookahead. Longer horizons produce smoother trajectories but react more slowly to sudden obstacles.

Yes, the motion_model parameter accepts DiffDrive, Omni, or Ackermann. DiffDrive constrains lateral velocity vy to zero, while Ackermann models car-like steering kinematics for vehicles that cannot turn in place.

CPU cost scales with iteration_count times batch_size times time_steps times critic evaluation cost. Reduce batch_size, increase trajectory_point_step on critics, and set consider_footprint to false on CostCritic to cut compute time significantly.

Temperature controls the softmin weighting of sampled trajectories. Low values near 0.01 make the controller greedy toward the single best trajectory, while values near 1.0 average all trajectories nearly equally. A range of 0.15 to 0.3 works well for most indoor use.

Oscillation near obstacles usually means CostCritic.cost_weight is too low relative to PathAlignCritic, or sampling noise (vx_std, wz_std) is too large. Increase the CostCritic weight or reduce PathAlignCritic weight, and verify noise values stay near 0.2 and 0.4.