PaperlayerView exact revision on arXiv

Source-linked AI summary

OpenSCvx: An Open-Source Modular and Extensible Nonlinear Trajectory Planning Package

Christopher R. Hayner, Griffin J. Norris, Fabio Spada, Samet Uzun, Avi Mittal, Behcet Acıkmese, Karen Leung

arXiv:2608.21631v1cs.ROmath.OC

TL;DR

Autonomous systems need dynamically feasible trajectories that satisfy nonlinear dynamics, constraints, and task objectives, but integrating modeling and optimization layers remains challenging. OPENSCVX addresses this gap with an open-source symbolic and modular continuous-time successive-convexification framework backed by JAX. Verification benchmarks reproduce analytical optima with relative objective errors below 10^-5%, while the framework supports extensible and scalable trajectory optimization.

  • Problem

    Integrating symbolic modeling, differentiation, optimization backends, caching, batching, and acceleration into a flexible reusable trajectory-optimization framework remains challenging.

  • Method

    OPENSCVX separates problem specification from transcription, convexification, and numerical solution through a symbolic interface, modular CT-SCvx architecture, and JAX-based computational backend.

  • Results

    Relative objective errors below 10^-5% on two verification benchmarks show that OPENSCVX reproduces analytical optima across substantially different problem classes.

  • Takeaways & Limitations

    OPENSCVX provides a general-purpose environment for formulating, solving, and extending nonlinear trajectory-optimization problems with continuous-time, logical, parameterized, batched, and interchangeable computational components.

Abstract

from arXiv · show

Trajectory optimization computes dynamically feasible motions that enable autonomous systems to accomplish complex tasks while satisfying operational and environmental constraints. This tutorial presents OpenSCvx, an open-source Python framework that bridges the gap between high-level problem specification and efficient numerical optimization. Rather than requiring users to derive solver-specific mathematical formulations, OpenSCvx provides a symbolic modeling interface that automatically constructs and solves trajectory optimization problems from modular descriptions of objectives, dynamics, and constraints. Beyond simplifying problem formulation, OpenSCvx supports (i) continuous-time constraint modeling, (ii) temporal and logical specifications, (iii) automatic vectorization for scalable and batched optimization, and (iv) a modular architecture that enables new algorithms, models, and solver backends to be incorporated with minimal effort. These capabilities allow researchers and practitioners to rapidly prototype, solve, and extend state-of-the-art trajectory optimization methods.

SUPPLEMENTRY MATERIAL

OPENSCVX addresses the difficulty of integrating trajectory-planning software layers by combining symbolic problem specification with modular continuous-time successive convexification and accelerated computation. It supports extensible formulation, algorithm development, and scalable optimization across diverse planning settings.

  • I. INTRODUCTION: OPENSCVX combines symbolic modeling, modular CT-SCvx optimization, and a high-performance computational backend in one framework.Users can define nonlinear dynamics, objectives, and constraints while independently modifying transcription, convexification, update rules, and numerical backends.
  • I. INTRODUCTION: JAX provides automatic differentiation, vectorized execution, compilation, and GPU acceleration for scalable trajectory optimization, including batched problems.The backend also supports integration with learned or simulation-based dynamics models.
  • I. INTRODUCTION: The framework automatically constructs computational representations from composable mathematical expressions for dynamics, objectives, and constraints.This reduces implementation effort when developing new trajectory-optimization problems and algorithms.
  • I. INTRODUCTION: OPENSCVX supports interchangeable transcription methods, convexification strategies, and algorithmic update schemes for developing and evaluating SCvx variants.The modular CT-SCvx architecture is designed for systematic experimentation across trajectory-optimization problems.
  • I. INTRODUCTION: A parameterized optimization architecture separates problem structure from numerical parameters, enabling repeated optimization with updated data without rebuilding the full model.This supports efficient updates when problem data changes.
  • B. Direct trajectory optimization frameworks: Direct transcription typically enforces state and path constraints only at discretization nodes, while continuous mission specifications may require problem-specific reformulations.This motivates support for continuous-time constraints and temporal or logical specifications.

C. Functional gradient, stochastic, and probabilistic trajectory optimization

Trajectory optimization includes functional-gradient, stochastic, probabilistic, and sequential-convex approaches, but these methods occupy different points in the trade-off between generality, structure exploitation, and continuous-time constraint handling. OPENSCVX addresses software support for CT-SCvx by combining symbolic modeling with modular optimization components.

  • C. Functional gradient, stochastic, and probabilistic trajectory optimization: Functional-gradient, stochastic, and probabilistic methods refine trajectories through gradients, sampled perturbations, or probabilistic inference rather than general nonlinear programs or convex subproblem sequences.CHOMP promotes smoothness and obstacle avoidance, STOMP supports nondifferentiable objectives and constraints, and GPMP methods use Gaussian-process trajectory representations.
  • C. Functional gradient, stochastic, and probabilistic trajectory optimization: These motion-planning methods are effective in high-dimensional configuration spaces but are primarily tailored to motion planning rather than general nonlinear optimal control.They are presented as complementary to direct transcription and successive-convexification approaches.
  • D. Sequential convex programming: Sequential convex programming repeatedly replaces nonlinear dynamics and constraints with convex local subproblems, while specialized variants differ in convexification, constraint handling, globalization, and convergence mechanisms.Examples include TrajOpt, SCvx*, AutoSCvx, and CT-SCvx; prox-linear frameworks provide related theoretical foundations.
  • D. Sequential convex programming: Structure-exploiting methods can struggle with between-node continuous-time feasibility, preservation of existing convex structure, free-final-time problems, nonsmooth formulations, and complex path constraints.Their performance also relies on assumptions about problem structure and local approximations.
  • OPENSCVX: Existing SCvx software remains comparatively immature because users often must manually construct transcriptions, provide derivatives, or formulate convex subproblems directly.This motivates integrating symbolic modeling, automatic differentiation, numerical backends, and execution strategies in a reusable framework.
  • OPENSCVX: OPENSCVX combines a high-level symbolic interface with modular CT-SCvx components and JAX computation to separate problem specification from transcription, convexification, updates, and numerical backends.Its supported formulation allows generic nonlinearities and continuous-time spatial, logical, physical, and temporal constraints.

A. Symbolic Expression Layer

OPENSCVX represents optimal-control models as symbolic expression DAGs rather than eagerly evaluated expressions. The same graph is transformed and lowered into JAX and CVXPY code, allowing shared modeling syntax, automatic derivatives, and modular backend integration.

  • A. Symbolic Expression Layer: The Python symbolic DSL stores variables, constants, and operators as an expression graph, allowing expressions involving optimization variables to be constructed without eager evaluation.Leaf nodes represent variables and constants, while operators form composite expressions.
  • A. Symbolic Expression Layer: Because subexpressions can be reused by multiple parents, the expression structure is a directed acyclic graph rather than a tree.The DAG is the central data structure used throughout problem construction and numerical solution.
  • 1) Symbolic Lowering and Backend Compilation: OPENSCVX successively inspects, transforms, augments, canonicalizes, and lowers the DAG, reusing the same graph for JAX and CVXPY backends.Lowering preserves graph structure and shared subexpressions through backend-specific operator translation rules.
  • 1) Symbolic Lowering and Backend Compilation: JAX handles dynamics, costs, and nonconvex constraints, supplying automatic differentiation, numerical integration, vectorization, compilation, and accelerator execution.The resulting Jacobians and discretized linearized dynamics feed the convex subproblem.
  • 1) Symbolic Lowering and Backend Compilation: CVXPY assembles each SCvx convex subproblem from JAX-produced local approximations and expressions that are already convex.JAX outputs enter as parameters whose numerical values are updated at each iteration.
  • A. Symbolic Expression Layer: The graph-only interface keeps modeling, algorithms, and backends independent, so new operators or backends can be added through localized extensions.This modularity enables backend interchange without changing the user-facing problem definition.

3) Assembly and Solution:

OPENSCVX assembles a trajectory-optimization problem from symbolic leaves, expressions, constraints, and modular algorithm choices. Initialization compiles and caches the pipeline, while later solves execute the SCvx loop and support richer temporal, cost, dynamics, and derivative constructs.

  • 3) Assembly and Solution:: initialize() canonicalizes, augments, lowers, compiles, and caches the convex-subproblem canonicalization, while solve() runs the SCvx loop and returns the optimized trajectory.This supports repeated solves after a single initialization.
  • 3) Assembly and Solution:: Algorithmic components are selected through assembly arguments with sensible defaults, and discretizers, autotuners, subproblem solvers, and SCvx algorithms are swappable modules.Custom implementations can be supplied without changing the problem definition.
  • 3) Assembly and Solution:: Nodal constraints apply at decision nodes by default, can target selected nodes with .at(), and can bypass linearization through .convex() when they are DCP-compliant.Convex expressions are then enforced directly in the convex subproblem.
  • 3) Assembly and Solution:: Continuous-time constraints can cover the full horizon or a sub-interval, with independently monitored violation integrators and configurable symbolic or built-in penalties.The .over() and penalty mechanisms support localized enforcement and differentiated violation measures.
  • 3) Assembly and Solution:: Signal Temporal Logic expresses interval-wide and pointwise mission requirements, including always, eventually, and conditional specifications over trajectory evolution.OPENSCVX supports both .over() and .at() forms for STL expressions.
  • 3) Assembly and Solution:: Running costs are converted to Mayer form by augmenting the system with a cost state whose final value is minimized.The same boundary-condition markers handle minimum-time, terminal-cost, and running-cost objectives.
  • 3) Assembly and Solution:: The modeling layer also supports symbolic or callable initial guesses, discrete state transitions with impulsive controls, user-supplied Jacobians, and external JAX-based dynamics adapters.URDF and MuJoCo adapters return ordinary state and control objects that compose with the remaining modeling vocabulary.

D. Working with Solutions

OPENSCVX preserves the symbolic vocabulary of the problem in its solution outputs and supports multiple propagation views, runtime parameter updates, and batched solves. Its modular CT-SCvx architecture separates problem modeling from interchangeable parsing and iterative solution components.

  • Working with Solutions: OptimizationResults retrieves states and controls by their declared symbolic names, alongside time and other trajectory outputs.The solution includes optimizer nodes, segment-by-segment nonlinear propagation, and full-horizon nonlinear propagation.
  • Working with Solutions: A robot model can be adapted into OPENSCVX states, controls, and dynamics without changing the solution interface.The framework exposes ordinary State and Control objects through a dynamics adapter.
  • Working with Solutions: Runtime parameter assignment enables repeated solves with new data while reusing the compiled problem.This compile-once, solve-many workflow supports applications such as MPC, moving obstacles, and model retuning.
  • Working with Solutions: Batched solving adds a leading batch dimension to inputs and exposes the SCvx loop through JAX transformations such as jit and vmap.The trade-off is reduced interactive diagnostics compared with solve().
  • CT-SCvx: CT-SCvx parses the problem, then iteratively linearizes, discretizes, solves convex subproblems, and updates algorithmic parameters.Figure 5 distinguishes parsing steps from iterative steps.
  • Modularity: Problem specification is separated from algorithmic solution, allowing different successive-convexification strategies without modifying the modeling layer.Parsing and iterative components are selected within the framework’s modular architecture.

1) Path Constraint Reformulation and CTCS:

OPENSCVX reformulates continuous-time path constraints as integrated violation states so feasibility is evaluated across trajectory segments rather than only at decision nodes. Its normalized-time, parameterized multiple-shooting formulation supports continuous controls, discrete transitions, linearized dynamics, and defect reduction.

  • Path Constraint Reformulation and CTCS: Nodal feasibility can miss intersample obstacle violations, so OPENSCVX enforces path constraints continuously across trajectory segments.The motivating example has all decision nodes outside an obstacle while the connecting trajectory cuts through it.
  • Path Constraint Reformulation and CTCS: Continuous path constraints are represented by integrated violation states whose components can be assigned to specific constraints for independent tuning and error tracking.Constraint windows can be restricted to sub-intervals, each with its own violation integrator.
  • Path Constraint Reformulation and CTCS: OPENSCVX uses differentiable exterior penalties whose zero sets correspond to inequality and equality feasibility.The squared ReLU is a canonical inequality penalty, while equality penalties use squared residuals.
  • Path Constraint Reformulation and CTCS: The ε-relaxation bounds maximum integrated constraint violation by ε · N across the shooting segments.Strictly enforcing zero integrated violation can cause LICQ violations, motivating the relaxation.
  • Time and Dynamics: Free-final-time problems use normalized time with a positive bounded dilation factor included as an additional control decision variable.The physical state, violation states, and time state form an augmented state, while physical controls and dilation form an augmented control.
  • Transcription: ZOH holds controls constant between nodes, whereas FOH linearly interpolates endpoint values to represent smoothly varying inputs.OPENSCVX supports both parameterizations, with FOH used by default for controls.
  • Transcription: Multiple shooting treats knot states as variables and drives integration defects toward zero within the successive-convexification process.Two differentiation and integration orderings yield equivalent discrete-time Jacobians, and linearized dynamics use slack for discretization and linearization error.

6) Hyperparameter Update:

OPENSCVX updates penalties and trust-region parameters to manage the quality and feasibility of successive-convexification candidates. It supports constant, adaptive, and augmented-Lagrangian-inspired autotuning strategies based on nonlinear rollout metrics and constraint violations.

  • Hyperparameter Update: OPENSCVX penalizes slacks and deviations, making weight selection important while allowing weight-update policies to adjust them during optimization.Users may select a built-in policy or provide their own at problem assembly.
  • Hyperparameter Update: Adaptive proximal weighting evaluates candidate trajectories using terminal cost, dynamics mismatch, and nonlinear constraint violations.The mismatch compares decision states with forward-integrated states, while violations use weighted inequality and equality residuals.
  • Hyperparameter Update: Natively convex constraints remain hard constraints because they require neither linearization-error buffers nor nonlinear penalty terms.The convex subproblem enforces these constraints directly.
  • Hyperparameter Update: Candidate acceptance depends on the step ratio: poor ratios reject the trajectory and increase the proximal weight, while better ratios accept it with conditional updates.The policy uses thresholds η0, η1, and η2 to determine rejection, acceptance, and proximal-weight changes.
  • Hyperparameter Update: The augmented-Lagrangian-inspired strategy updates virtual-control and virtual-buffer weights dynamically after accepted iterates.Weights increase inversely with the current proximal parameter and are capped at λmax.

7) Convergence Criterion:

OPENSCVX declares convergence when trust-region steps, virtual-control defects, and virtual-buffer violations are all sufficiently reduced, or stops at a maximum iteration count. Its modular implementation and benchmark suite support both algorithm development and numerical validation.

  • Convergence Criterion: Convergence requires a small trust-region step, reduced virtual-control defects, and reduced virtual-buffer violations.The three conditions respectively indicate negligible solution changes, dynamic feasibility, and satisfaction of non-convex path constraints.
  • Convergence Criterion: The successive-convexification procedure terminates when the maximum number of SCP iterations Nmax is reached if convergence has not occurred.The overall loop initializes a reference trajectory, linearizes and discretizes, solves a convex subproblem, and updates parameters.
  • Modularity: Discretizers, convex solvers, SCP algorithms, and autotuners are interchangeable modules selected without altering the problem formulation.Custom components implement fixed lifecycle interfaces and can transfer across problems.
  • Validation: OPENSCVX evaluates correctness against analytical optima for the Brachistochrone and Hohmann transfer and includes both in automated tests and continuous integration.The comparisons use relative final-time error for the Brachistochrone and relative total impulse error for the Hohmann transfer.
  • Validation: The workflow reports wall-clock time separately for initialization, solving, and post-processing.These are identified as the three major stages of an OPENSCVX workflow.

2) Brachistochrone:

OPENSCVX is evaluated on canonical optimal-control benchmarks and solver comparisons spanning nonlinear dynamics, continuous-time constraints, orbital transfers, and computational trade-offs.

  • Brachistochrone: The brachistochrone benchmark tests free-final-time optimization, nonlinear continuous dynamics, and continuous-time constraints against its analytical cycloid solution.The problem seeks minimum travel time between two fixed points under gravity.
  • Verification: OPENSCVX reproduces analytical optima for both verification benchmarks with relative objective errors below 10^-5%.The tests cover substantially different capabilities, including free-final-time optimization, continuous-time constraints, nonlinear dynamics, and impulsive controls.
  • Verification: Initialization dominates runtime because constructing and compiling the problem is a one-time cost that can be amortized across repeated parameterized solves.The timing breakdown reports that solving each optimization problem requires only a small fraction of total execution time.
  • Framework comparison: OPENSCVX ranks behind GPOPS-II on the hypersensitive problem but outperforms MAPTOR, ICLOCS2, and PSOPT.All compared NLP solvers use IPOPT as backend in this comparison.
  • Framework comparison: Fixed-node discretization lowers OPENSCVX’s computational and objective performance relative to solvers that add nodes between iterations.The fixed-node design trades simplicity and convergence guarantees for performance.
  • Framework comparison: OPENSCVX’s continuous path-constraint reformulation keeps violations essentially absent independently of node count.The hypersensitive solution is the only plotted solution avoiding the forbidden region.

1) Ease of use:

OPENSCVX combines modular solver architecture with applications that exercise symbolic modeling, parameter updates, continuous constraints, temporal logic, and hardware execution.

  • Ease of use: OPENSCVX uses first-order Jacobians and supports CVXPY-installed or custom convex backends through its SCP architecture.Its JAX backend provides machine-precision automatic differentiation, while other compared packages use more general NLP approaches.
  • Applications: Hardware demonstrations span robotic manipulation, quadrotor racing, and powered descent, sharing the same modeling and solve pipeline.The case studies exercise symbolic rigid-body kinematics, parameterized nodal constraints, and compound state-triggered constraints.
  • Applications: The UR5e experiment uses symbolic rigid-body dynamics, Product-of-Exponentials kinematics, and continuous contact constraints to trace an SVG path.The pen tip is kept on the writing plane throughout the stroke rather than only at discretization nodes.
  • Applications: The quadrotor racing problem enforces continuous state and control limits while allowing gate-layout replanning through parameter updates and re-solving.Gate passage uses nodal containment constraints and symbolic gate poses.
  • Applications: Compound state-triggered constraints encode nested implications, conjunctions, and disjunctions directly from engineering specifications.The powered-descent demonstration includes continuous-time intersample satisfaction and qualitative execution on a NASA SENSS tendon robot.
  • Conclusion: OPENSCVX is presented as a common platform for developing and deploying successive-convexification methods, but the framework remains a foundation rather than a finished ecosystem.Future work targets broader capabilities, scalability, real-time performance, and integrations.

APPENDIX A OPENSCVX REFERENCE PROBLEMS

The reference problems cover continuous-time constraints, free-final-time and hybrid dynamics, temporal logic, parameterization, vectorization, and robotics or aerospace applications.

  • Optimal-control examples: Unstable and hypersensitive optimal-control examples exercise continuous-time constraints, while impulsive examples combine continuous and impulsive inputs.The reference list includes long-horizon hypersensitive and mixed-input problems.
  • Temporal and logical specifications: The library includes STL integer variables, disjunctions, conditional constraints, temporal operators, and moving safe zones.Examples cover state-dependent speed limits, STL Or, and Eventually waypoint specifications.
  • Optimal-control examples: The reference set includes free-final-time aircraft and brachistochrone problems, including batched solves and a Qpax backend.Examples also include minimum-time climb and batched initial conditions.
  • Scalable modeling: Parameterized and vectorized examples support disjoint waypoint visiting, moving constraints, parallel obstacle constraints, and batched drone gate layouts.The collection includes vmap obstacle constraints and batched solves over gate layouts.
  • Drone examples: Drone references cover continuous and nodal viewpoint constraints, line-of-sight occlusion, terrain following, path tracing, and sequential gate racing.Several examples use ellipsoidal or polytope-based viewcones and obstacle constraints.

Frax Robot Dynamics

The reference problems extend from FRAX and MJX rigid-body dynamics to manipulation, viewpoint planning, gate racing, and real-time model-predictive control.

  • Frax Robot Dynamics: FRAX examples integrate rigid-body dynamics with collision avoidance, wrist-camera viewcones, and parameterized waypoints.The listed problems include Panda FRAX dynamics and waypoint planning.
  • Frax Robot Dynamics: MJX examples cover cartpole, quadrotor gate racing, three-dimensional triple cartpole, and an interactive balancing game.These examples use MJX dynamics adapters and include both single and double cartpole variants.
  • Frax Robot Dynamics: MPC references include discrete double-integrator viewpoint control, path following, gate racing, circle tracking, and receding-horizon loops.Several examples support real-time parameter updates and MPCC.
  • Frax Robot Dynamics: Additional MPC examples combine real-time parameter updates with MPCC for quadrotor viewpoint planning.The reference list also includes discrete circle tracking and analytical-reference variants.

Multi-agent

The examples demonstrate OpenSCvx across multi-agent coordination, vehicle racing, real-time replanning, rocket guidance, and terrain-aware landing. They combine specialized trajectory models with collision avoidance, batching, parameters, continuous-time constraints, and state-triggered constraints.

  • Multi-agent: Multi-agent examples cover iLQGames, soft collision costs, circle swapping, and continuous-time collision avoidance with vectorization.These examples include multi-agent differential games and batched collision-avoidance formulations.
  • Race cars: Race-car examples implement minimum-lap-time optimization, MPCC, Qpax, batching, ICE ablations, and receding-horizon MPC.Additional examples provide multi-agent MPCC tracking and trajectory visualization.
  • Rockets: Rocket examples include free-final-time powered descent, batched solves over initial conditions, compound state-triggered constraints, multiphase ascent, and reusable-vehicle entry and landing.The collection also includes iLQR-style rocket landing and impulsive staging.
  • Terrain-aware landing: SENSS examples combine DEM terrain with static or real-time landing, cSTC constraints, gimbal triggers, and hopping scenarios.These examples extend terrain-aware landing with visualization and parameterized replanning.

Spacecraft

The spacecraft examples cover relative motion, rendezvous, inspection, orbit transfer, and loitering, while the operator and integration passages describe the modeling vocabulary and external dynamics interfaces. Together they show support for specialized spatial, logical, and dynamics representations, with contact dynamics currently constrained in MuJoCo XLA.

  • Spacecraft applications: Spacecraft examples include CW dual-deputy inspection, dual-quaternion SE(3) rendezvous, Hohmann transfer, low-energy CR3BP transfer, and relative loitering.The examples use line-of-sight, field-of-view, glide-slope, impulsive, and continuous-time-constraint formulations.
  • Operator vocabulary: OpenSCvx provides composable arithmetic, comparisons, linear algebra, array operations, trigonometric functions, logic, and spatial operators for expressing dynamics, costs, and constraints.The operator tables distinguish JAX and CVXPY translation rules, while specialized spatial operations use quaternion and Lie-group representations.
  • Logic and temporal specifications: STL operators encode sequencing, state-dependent behavior, deadlines, and conditional obligations directly into continuous optimal-control problems.The text states that these specifications are enforced smoothly and exactly through GMSR.
  • Extensibility: The operator vocabulary is representative rather than exhaustive and is designed to grow through additional nodes and translation rules.The expression DAG assembles user-defined problem descriptions from these extensible primitives.
  • External dynamics integrations: OpenSCvx interfaces with MuJoCo MJX through MjxDynamics and with URDF-based frax models through FraxDynamics.MuJoCo XML models can be parsed directly, while frax supplies JAX-based rigid-body kinematics and dynamics.
  • External dynamics integrations: MuJoCo XLA contact dynamics do not support forward differentiation, so contact must be disabled during optimization.The example explicitly disables the MuJoCo contact solver before converting the model to MJX.
Loading 2608.21631v1…