PaperlayerView exact revision on arXiv

Source-linked AI summary

MPPI-Generic: A CUDA Library for Stochastic Trajectory Optimization

Bogdan Vlahov, Jason Gibson, Manan Gandhi, Evangelos A. Theodorou

arXiv:2409.07563v4cs.MScs.DCcs.ROcs.SYeess.SY

TL;DR

Sampling-based control can represent arbitrary dynamics and costs, but requires many samples and must still respond in real time. MPPI-Generic provides GPU-accelerated MPPI variants and an extensible C++/CUDA API. Its comparisons show performance across hardware, including use on an older Jetson Nano.

  • Problem

    Sampling-based methods handle arbitrary dynamics and cost functions, but need many samples, while robotic planning must respond to changing conditions in real time.

    Source: §I · p. 1

  • Method

    MPPI-Generic implements MPPI, Tube-MPPI, and RMPPI in C++/CUDA and provides an API for existing or researcher-defined dynamics and cost functions.

    Source: §I · pp. 1–2

  • Results

    Across tested hardware, MPPI-Generic performs well at lower sample counts while other implementations can become faster at higher counts; on Jetson Nano, AutoRally becomes faster around 512 samples.

    Source: A. Results · p. 15

  • Takeaways & Limitations

    The comparisons show that MPPI-Generic can be used on relatively low-power, older hardware such as the Jetson Nano.

    Source: A. Results · p. 15, §VI · p. 17

Abstract

from arXiv · show

This paper introduces a new C++/CUDA library for GPU-accelerated stochastic optimization called MPPI-Generic. It provides implementations of Model Predictive Path Integral control, Tube-Model Predictive Path Integral Control, and Robust Model Predictive Path Integral Control, and allows for these algorithms to be used across many pre-existing dynamics models and cost functions. Furthermore, researchers can create their own dynamics models or cost functions following our API definitions without needing to change the actual Model Predictive Path Integral Control code. Finally, we compare computational performance to other popular implementations of Model Predictive Path Integral Control over a variety of GPUs to show the real-time capabilities our library can allow for. Library code can be found at: https://acdslab.github.io/mppi-generic-website/ .

I. INTRODUCTION

MPPI-Generic is a GPU-accelerated C++/CUDA library intended to make sampling-based control practical for complex, changing systems. It combines existing MPPI variants and reusable components with an API for researcher-defined dynamics and costs.

I. INTRODUCTION

  • The library is motivated by robotics needs for intricate dynamics, expressive costs, adaptation to changing conditions, and real-time response.The paper illustrates these requirements with a self-driving car facing changing roads, multiple goals, and sudden hazards.Source: §I · p. 1
  • Sampling-based methods support arbitrary dynamics and cost functions, but require many samples; GPU parallelization can make them usable in real time.Unlike gradient-based methods, sampling-based approaches do not require continuously differentiable dynamics and costs.Source: §I · p. 1
  • The library builds on MPPI and its Tube-MPPI and RMPPI extensions, which use two-layer control architectures to improve robustness to disturbances and model errors.The paper also notes MPPI applications in model-based reinforcement learning and domains beyond robotics.Source: §I · p. 1
  • The paper frames MPPI-Generic as a flexible framework for researchers to reuse prior advances, test across platforms, and develop new ideas toward hardware deployment.Its stated target includes real-time operation on older hardware platforms.Source: §I · p. 1
  • MPPI-Generic provides MPPI, Tube-MPPI, and RMPPI controllers alongside an API for new sampling-based controllers, dynamics, and cost functions.Researchers can extend the library without changing the existing controller code.Source: §I · pp. 1–2

1) Information Theoretic Derivation:

The derivation generalizes running cost to include both state and control, then uses importance sampling to connect a free-energy bound to a tractable parameterized distribution. The resulting update rule matches that distribution to an optimal one.

1) Information Theoretic Derivation:

  • The derivation generalizes the running cost to depend on both state and control, rather than only on the state trajectory.It follows the information-theoretic derivation in with this change.Source: 1) Information Theoretic Derivation · p. 2
  • Importance sampling with a distribution Q yields an upper bound on free energy, with equality when Q uses the specified optimal density.The bound involves expected trajectory cost and the KL divergence between Q and the base distribution P.Source: 1) Information Theoretic Derivation · p. 2
  • Because the optimal density still depends on the potentially intractable base distribution, the derivation introduces a controllable distribution Sθ to approximate it.Sθ is chosen to minimize its KL divergence from Q*.Source: 1) Information Theoretic Derivation · p. 2
  • The update rule matches a parameterized distribution to the optimal distribution, while the control sequence is obtained from the optimal distribution’s mean.The derivation then relates the update rule and control sequence to the chosen distribution family.Source: 1) Information Theoretic Derivation · pp. 2–3

B. Other MPPI Modifications

The paper reviews robustness-oriented MPPI variants and describes how MPPI-Generic samples control trajectories, evaluates them, and averages them into an updated sequence. Its implementations include multiple controllers because different scenarios may favor different algorithms.

B. Other MPPI Modifications

  • Tube-MPPI uses a tracking controller to return the real system toward a nominal system, while RMPPI incorporates tracking feedback in samples and constrains the nominal initial state.RMPPI’s constrained choice bounds how quickly optimal-trajectory cost can grow under disturbance, but robustness can struggle when the cost function changes over time.Source: B. Other MPPI Modifications · p. 3
  • The library includes multiple controllers because different algorithms are the best choice in different scenarios.The authors identify Tube-MPPI and RMPPI as modifications addressing limitations of MPPI.Source: B. Other MPPI Modifications · p. 3
  • MPPI extensions address sampling efficiency and robustness, but rapid community development makes it nearly impossible for the library to keep up with every extension.The paper names methods including Covariance Control MPPI, Colored MPPI, and Risk-Aware MPPI,,.Source: B. Other MPPI Modifications · p. 3

C. MPPI-Generic’s MPPI Implementation

  • MPPI-Generic samples control trajectories, simulates them through the dynamics, evaluates their costs, and uses a weighted average to update the optimal control sequence.The importance-sampling ratio can be enabled or disabled; the authors report better trajectories without it in some AutoRally experiments.Source: C. MPPI-Generic’s MPPI Implementation · p. 3
  • Gaussian control samples are centered on the previous optimal control and use zero-mean noise with covariance Σ, while other distributions require different sampling and importance-sampling equations.Sampling in control space yields dynamically feasible trajectories and permits nondifferentiable dynamics and cost functions.Source: C. MPPI-Generic’s MPPI Implementation · p. 3

D. Library Description

MPPI-Generic organizes its functionality into six major class types, separating dynamics and costs, optimization, sampling, feedback, and plant interfaces. Their parameter structures encapsulate adjustable settings for each class instance.

D. Library Description

  • The library has six major class types, with Dynamics and Cost Function classes describing the system functions F, G, ℓ, and ϕ.The Controller finds an optimal control sequence minimizing cost using algorithms such as MPPI.Source: D. Library Description · pp. 3–4
  • Sampling Distributions generate control samples for the Controller, while Feedback Controllers provide optional tracking feedback and are required by Tube-MPPI and RMPPI.Feedback Controllers are instantiated but turned off by default in code examples unless otherwise specified.Source: D. Library Description · p. 4
  • Plants wrap a controller in an MPC interface, where platform-specific input and output methods can connect systems such as ROS to MPPI-Generic.Examples include ROS subscribers, control-output publishers, and conversions between ROS messages and library equivalents.Source: D. Library Description · p. 4
  • Each class type has parameter structures that encapsulate adjustable parameters for its specific instantiation.Source: D. Library Description · p. 4

III. PERFORMANCE IMPLEMENTATION

MPPI-Generic’s performance implementation combines CUDA scheduling and memory-access optimizations with controller-specific parallelization. The design uses GPU hardware characteristics while retaining CPU work where it is faster.

A. GPU Parallelization Overview

  • CUDA organizes computation into 32-thread warps, thread blocks, and grids, with indexed dimensions supporting different parallelization patterns and shared memory available within blocks.Kernels can receive grid and block dimensions at runtime.Source: A. GPU Parallelization Overview · p. 4

B. General GPU speedups

  • CUDA streams schedule memory transfers and kernel calls asynchronously, allowing CPU work to proceed concurrently and separating controller optimization from visualization computations.Source: B. General GPU speedups · p. 4
  • Moving commonly accessed data from global memory to shared memory and using CRTP polymorphism can reduce costly global-memory access.CRTP avoids constructing and reading a virtual method table stored in global memory.Source: B. General GPU speedups · pp. 4–5
  • Vectorized-memory access can load up to four 32-bit floats in one instruction, reducing global-memory calls and computation time.Source: B. General GPU speedups · p. 5
  • The library uses approximate trigonometric intrinsics selectively because other tested intrinsics changed optimal control calculations significantly.The authors also use float-specific methods such as expf() to avoid unnecessary conversions to and from double.Source: B. General GPU speedups · p. 5

C. Library-Specific Performance Optimizations

Library-specific performance choices include passing intermediate dynamics calculations to cost functions and splitting dynamics from cost computation into kernels. The split design exploits different parallelism across samples, systems, state derivatives, and time.

1) Intermediate Calculation Passthrough:

  • Passing intermediate values from Dynamics to the Cost Function can avoid recalculating quantities, such as vehicle wheel locations, that both computations need.The output y_t is usually the true state x_t but can include additional calculations produced by the Dynamics.Source: 1) Intermediate Calculation Passthrough · p. 5

2) Split Kernel Description:

  • The dynamics kernel parallelizes across samples, systems, and state derivatives using the x, z, and y thread dimensions, respectively.Tube-MPPI and RMPPI run nominal and real systems; when x block size is a multiple of 32, y threads occupy separate warps, while divergent branches can slow execution.Source: 2) Split Kernel Description · p. 5
  • The dynamics kernel advances each sample through time, applying the control sample through the Dynamics step() method and saving each output to global memory.Source: 2) Split Kernel Description · p. 5
  • A separate cost kernel parallelizes across time because the cost function need not run sequentially, summing each sample’s running and terminal costs.Threads are reused to cover horizons beyond the 1024-thread block limit, bringing cost computation closer to a single-timestep duration than sequential evaluation alongside dynamics.Source: 2) Split Kernel Description · pp. 5–6

C. Library-Specific Performance Optimizations

  • The execution-flow diagram distinguishes variables, GPU methods, and CPU methods, and shows the selected operation combined in one GPU kernel or separated for split kernels.Finding the baseline and calculating the normalizer η run faster on the CPU.Source: Figure 1 · p. 6

3) Combined Kernel Description:

The section explains how MPPI-Generic runs rollout kernels, chooses between combined and split execution, and applies performance-oriented GPU configuration recommendations.

3) Combined Kernel Description:

  • The Combined Kernel loops over the horizon, applying dynamics and cost computation to each sample while parallelizing across samples, systems, and method dimensions.It keeps intermediate outputs in shared memory rather than writing them to global memory.Source: 3) Combined Kernel Description · p. 6

4) Choosing between the Split and Combined Kernels:

  • Combined execution saves global-memory traffic but uses more shared memory and runs costs sequentially; split execution allows parallel cost computation but saves trajectories to global memory.The library benchmarks both options, chooses the faster one when combined-kernel shared-memory use fits the hardware limit, and lets users override the choice.Source: 4) Choosing between the Split and… · p. 6

5) Weight Transform and Update Rule Kernels:

  • For thousands of samples, the library finds the minimum trajectory cost on the CPU as baseline ρ, exponentiates costs on the GPU, then computes normalizer η on the CPU before the control update.The CPU baseline search was found faster than a GPU search at that sample scale.Source: 5) Weight Transform and Update Rule… · p. 6

D. Performance Recommendations

  • Use an x-dimension block size divisible by 32, set the dynamics y dimension to the state dimension and cost y dimension to 1, and keep blocks small to limit synchronization waits.The y-dimension choices depend on whether dynamics or cost functions use that axis for parallelization.Source: D. Performance Recommendations · pp. 6–7
  • For custom dynamics, output dimensions divisible by 2 or 4 can reduce memory calls by at least a factor of 2, while making control dimensions divisible by 4 may slow sample generation.The guidance also recommends minimizing warp divergence; in some cases, converting a boolean expression to a float can make branching faster.Source: D. Performance Recommendations · p. 7

IV. API STRUCTURE

The API is organized from using built-in components to implementing custom dynamics or costs and, at the advanced level, custom feedback controllers, controllers, or sampling distributions. The beginner example shows how to use a controller with a Plant wrapper for repeated MPC updates.

IV. API STRUCTURE

  • The API has beginner, intermediate, and advanced stages, ranging from provided components to custom dynamics or costs and then custom feedback controllers, controllers, or sampling distributions.At the beginner level, users mainly provide a Plant class and an executable.Source: §IV · p. 7

A. Beginner

  • The beginner example initializes controller components and parameters, computes an optimal control sequence from an initial state, and retrieves the sequence as a matrix.The example uses one MPPI iteration for a cartpole system.Source: A. Beginner · pp. 7–8
  • For repeated MPC use, a Plant wrapper obtains new system data, computes and sends controls, and manages synchronization; its control loop can run in a separate thread at a specified replanning rate.The example’s Plant implements system updates internally, while the Plant interface must be adapted for each use case.Source: A. Beginner · pp. 8–9

B. Intermediate

The intermediate API supports custom dynamics through CPU and GPU implementations, typed state/control/output definitions, and methods for adapting the model to the library. It also exposes additional customization options such as integration schemes and state interpolation.

1) Custom Dynamics:

  • A custom dynamics class needs a parameter structure defining state, control, and output dimensions, with enums that also determine statically sized array dimensions.The library runs dynamics and cost methods on both CPU and GPU, so implementations may require paired functions.Source: B. Intermediate · p. 9, 1) Custom Dynamics · p. 9
  • Custom dynamics provide CPU and GPU versions of computeStateDeriv(); CPU code uses Eigen matrices, GPU code uses raw float pointers, and shared enum macros support dynamics-cost compatibility.The enum-based macros avoid dependence on the underlying state or control ordering.Source: 1) Custom Dynamics · p. 9
  • CPU and GPU dynamics instances are separate, so paramsToDevice() must copy updated parameters and invoke copy methods for any added helper classes.Source: 1) Custom Dynamics · pp. 9–10
  • Custom dynamics can translate named state values with stateFromMap() and can replace Euler integration with Runge-Kutta or implicit integration, or customize zero states, controls, and interpolation.Source: 1) Custom Dynamics · p. 10

2) Custom Cost Function:

The custom-cost example defines a road-boundary penalty for a unicycle and shows the CPU/GPU methods needed to implement it. The resulting dynamics and cost can be incorporated into the earlier controller examples.

2) Custom Cost Function:

  • The unicycle cost penalizes absolute lateral position linearly within the road width and quadratically outside it.The example uses road width and a cost coefficient as parameters.Source: 2) Custom Cost Function · p. 10
  • A custom cost derives from CostParams and implements computeStateCost() and terminalCost() for both CPU and GPU; its state-cost method operates on dynamics output.The example’s output matches its state, and its terminal cost returns zero.Source: 2) Custom Cost Function · p. 10
  • The custom dynamics and cost are readily incorporated into the earlier controller examples.Source: 2) Custom Cost Function · p. 10

C. Advanced

The advanced examples show how to extend MPPI-Generic with custom controllers, feedback controllers, and sampling distributions. Feedback controllers separate GPU feedback calculation from CPU-side gain computation, and a PID example demonstrates the API.

C. Advanced

  • The API permits users to create new sampling-based controllers or change the sampling distributions used in specific scenarios.The advanced subsection presents both as customization options.Source: C. Advanced · p. 10

1) Feedback Controllers:

  • Feedback controllers separate GPU feedback calculation from CPU-side work such as recomputing gains for a new desired trajectory.The GPU class contains what is needed to calculate feedback; the CPU wrapper can access dynamics, Jacobians, and cost functions to recompute gains.Source: 1) Feedback Controllers · p. 11, Figure 2 · p. 11
  • A custom PID feedback controller implements k() on the GPU and requests shared memory per trajectory sample to retain integral and derivative history.The example uses a dynamics-templated parameter structure for its gain arrays; its constant PID gains leave computeFeedback() empty.Source: 1) Feedback Controllers · pp. 10–11

2) Controller:

The examples describe implementing a custom CEM controller and sampling distributions, followed by a benchmark design that compares MPPI implementations under shared algorithm settings. The benchmarks span multiple hardware configurations and sample counts, with fewer runs for TorchRL.

2) Controller:

  • The CEM example updates a Gaussian sampling distribution’s mean using its elite control samples, with the elite-set size specified as a percentage of all samples.The example holds variance constant and implements the controller’s sampling, trajectory-cost, elite-set, and distribution-update steps.Source: 2) Controller · pp. 11–12

3) Sampling Distributions:

  • The sampling-distribution API supports multiple existing distributions and provides generateSamples() and readControlSample() as the key methods for new implementations.Its flexibility also allows multi-hypothesis distributions and feedback-based sampling approaches.Source: 3) Sampling Distributions · p. 12

V. BENCHMARKS

  • The benchmark recreates shared differential-drive dynamics, cost components, and MPPI settings across implementations, then times optimization across sample counts and hardware.The implementations were run 10,000 times, except TorchRL, which was run 1,000 times; the Jetson Nano supported only MPPI-Generic and AutoRally.Source: §V · p. 14

A. Results

The benchmarks compare optimization time across GPUs and sample counts, with performance varying by hardware and implementation. MPPI-Generic remains competitive on older hardware, while its combined kernel and the Jetson Nano comparisons reveal trade-offs and scope boundaries.

A. Results

  • The results section focuses on computational speed with fairly simple dynamics and cost functions; real-world application results are not included in this paper.The authors point to other papers using the code base in more complex scenarios.Source: A. Results · pp. 14–15
  • At 16,384 samples on an RTX 4090 and Intel i9-13900K, AutoRally’s optimization time becomes lower than MPPI-Generic’s, while Nav2’s CPU time grows linearly with sample count.The other tested implementations use GPUs, which provide headroom to increase sample counts at small sizes.Source: Figure 3 · p. 14, A. Results · p. 15
  • On a GTX 1050 Ti, MPPI-Generic outperforms the other implementations at lower sample counts, but its optimization time eventually exceeds AutoRally’s after switching to the combined kernel.The split kernel is faster through 2,048 samples; the combined kernel supports more features, including multithreaded cost functions and more computationally heavy integration methods.Source: A. Results · p. 15, Figure 4 · p. 15
  • TorchRL runtimes are around 28 ms across sample counts in Figs. 3 and 4, and the RTX 3080 with an AMD 5600X is slower than a GTX 1050 Ti with an Intel 13900K.The paper describes TorchRL as heavily CPU-bound.Source: A. Results · p. 15, Figure 5 · p. 15
  • On the Jetson Nano, AutoRally becomes faster around 512 samples, while MPPI-Generic’s optimization time at 2,048 samples is roughly equivalent to Nav2’s on an Intel i9-13900K.TorchRL and Nav2 were incompatible with the Jetson Nano test setup, so that comparison includes only MPPI-Generic and AutoRally.Source: A. Results · p. 15, Figure 6 · p. 16

B. Comparisons to sampling-efficient algorithms

The section compares MPPI-Generic’s faster sampling with methods that reduce the samples needed: DMD-MPC’s step size helps at low sample counts, but becomes unnecessary as counts rise. The authors report that more sampling remains practical on their tested GPU, with little added computation time.

B. Comparisons to sampling-efficient algorithms

  • Adding 20+ sequential cosine operations to the cost function is where MPPI-Generic starts to outperform AutoRally on an Intel 13900K and GTX 1050 Ti with 8192 samples.Fig. 7 compares optimization times as cost-function computation increases.Source: Figure 7 · p. 16
  • At higher sample counts, the best DMD-MPC step size is γt = 1.0—the normal MPPI update law—while lower step sizes give the lowest average cost with fewer samples.The Fig. 8 caption reports that increasing samples until the step size is no longer useful still runs at over 800 Hz on an NVIDIA GTX 1050 Ti.Source: Figure 8 · p. 16, B. Comparisons to sampling-efficient… · p. 16
  • On the 2D double-integrator test, the optimal step size increases to 1.0 as sample count rises, with about 0.4 ms added computation time when the step size becomes irrelevant.The simulation accumulated cost over 1000 timesteps and was run 1000 times; the authors report headroom for more complex dynamics and costs while remaining above 100 Hz.Source: B. Comparisons to sampling-efficient… · pp. 16–17

VI. CONCLUSION

  • The conclusion presents faster sampling as a practical alternative to reducing the number of samples, with little computation-time impact.The paper reports performance comparisons against other MPPI implementations across varied computer hardware.Source: §VI · p. 17
Loading 2409.07563v4…