PaperlayerView exact revision on arXiv

Source-linked AI summary

Amplify: A Lightweight Library for Reproducible Nonlinear Programming Problems in Robotics

Nelson Rosa Jr

arXiv:2609.28377v1cs.RO

TL;DR

Robotics trajectory-optimization results can be hard to reproduce, and existing modeling languages are not well suited to expressing these problems directly. Amplify makes the NLP model the library, encoding transcription algorithms as constraints; the paper reports substantial presolve reductions and faster RK4 Spot evaluation than CasADi in that comparison, while noting scaling and user-workflow limitations.

  • Problem

    Robotics trajectory-optimization results remain difficult to reproduce, and general modeling languages are not well suited to expressing robotics problems directly as NLPs.

    Source: A. Previous Work · pp. 1–2

  • Method

    Amplify uses a declarative NLP model as the library, encoding dynamics, integration, and reference trajectories as constraints.

    Source: §XI · p. 18

  • Results

    Amplify's presolver often reduces problem size by over 90%, while RK4 Spot NLP evaluation is an order of magnitude faster with CasADi's expression graph than AMPL's.

    Source: C. Comparison of 18-DOF Quadruped Demo… · p. 15, 1) Use Presolvers for Performant Code · p. 17

  • Takeaways & Limitations

    The authors present Amplify's model-centered design as generic enough for other libraries to adopt, with a lightweight, reproducible framework built around it.

    Source: §XI · p. 18

    Amplify shifts work to users to generate data and script files, and the authors say a frontend should simplify and automate parts of NLP generation.

    Source: C. Limitations · p. 17

Abstract

from arXiv · show

Optimization problems (OPs) are key to solving many challenging research problems in robotics. However, reproducibility still remains a major issue. In this paper, we present Amplify, a lightweight nonlinear programming library aimed at reproducible results of robotic-related trajectory optimization problems. The minimalistic requirements for the 537-line library (80 characters per line) are an Internet connection, familiarity with the AMPL modeling language, and a text editor. Our primary contribution is the formulation of a library where trajectory optimization algorithms are represented directly within the optimization model. Specifically, we implement the algorithms used to compute the dynamics, trajectories, and reference motions as constraints of the OP in a declarative programming paradigm. We outline how our formulation of objectives, decisions variables, and constraints can be implemented in other transcription libraries that want to be lightweight and reproducible. We also compare the Amplify framework with 3 other libraries across examples of benchmark optimization problems across several fields, including bipedal locomotion and grasp planning.

I. INTRODUCTION

Robotics trajectory optimization remains difficult to reproduce because solver access, software toolchains, and heavyweight APIs can impede users. Amplify instead embeds transcription algorithms in a reusable NLP model, presenting a declarative, lightweight approach and its intended audiences.

I. INTRODUCTION

  • Users may struggle to reproduce robotics optimization results because solver access and software toolchains are barriers, while heavyweight APIs complicate customization.Reproducing a result may require the formulation, library, general-purpose language, and dependencies.Source: §I · p. 1, A. Previous Work · p. 2
  • Amplify is designed as a self-contained, reproducible, accessible library for hybrid trajectory optimization, demonstrated using AMPL and NEOS.Its design requires no external libraries; the solver service is available to users with an Internet connection.Source: §I · p. 1
  • Amplify encodes system dynamics, ODE solvers, and polynomial reference trajectories as NLP constraints, keeping the model separate from instance data.The resulting self-contained model file need not be regenerated whenever one of those three transcription tasks changes.Source: §I · p. 1

A. Previous Work

  • Robotics-focused libraries automate NLP transcription tasks that general modeling languages handle poorly, but surveyed libraries generally use general-purpose languages rather than modeling languages.Robotics problems can require expressing robot dynamics, trajectories, and integration schemes as constraints.Source: A. Previous Work · p. 2

B. Statement of Contributions

  • Amplify models hybrid dynamics with physical and virtual constraints, user-defined Runge-Kutta methods, Bézier trajectories, and extensible objectives, variables, and constraints.The authors present the approach as a generic paradigm other optimization frameworks could implement.Source: B. Statement of Contributions · pp. 2–3
  • The stated contributions include expressing efficient rigid-body dynamics algorithms, generic Runge-Kutta methods, and Bézier curves as optimization constraints.The authors also describe using these algorithms and data structures for optimal trajectories of constrained hybrid dynamical systems.Source: B. Statement of Contributions · pp. 2–3

C. Paper Outline

  • The paper addresses modeling-language developers, robotics transcription-library developers, and users seeking reproducible optimization problems they can run and extend.It proceeds from hybrid dynamics and implementation modules to benchmark comparisons, discussion, and conclusions.Source: C. Paper Outline · p. 3

II. MODELING ROBOT TRAJECTORIES

This section models hybrid robot motion with phase-wise constrained dynamics and impulsive transitions, then poses trajectory optimization as an NLP. It also presents a unified treatment of physical and virtual constraints.

II. MODELING ROBOT TRAJECTORIES

  • Each phase follows constrained mechanical dynamics, while impulse-momentum equations relate pre- and post-impact velocities across phases.The model assumes hybrid trajectories exist, are sufficiently smooth, and may be discontinuous at switching times.Source: §II · pp. 3–4

A. Problem Statement

  • The NLP embeds the system dynamics, ODE solver, and polynomial reference trajectories as model constraints, making the optimization model itself the library.The problem statement includes grid-point trajectory variables and user-defined objectives and constraints.Source: A. Problem Statement · pp. 4–5

A. A Unified Approach to Modeling Physical and Virtual Constraints

  • Physical and virtual constraints can be formulated together through Jacobians and transmission matrices, subject to maximal-rank conditions and enough control inputs for independent virtual constraints.The arm example distinguishes grasp contact, modeled as a physical constraint, from virtual-constraint tracking of the object’s path.Source: A. A Unified Approach to Modeling… · p. 5, Figure 2 · p. 5

B. A Unified Approach to Constraint Stabilization

The section addresses accumulated constraint-output error by incorporating stabilization into the unified dynamics formulation. It applies Baumgarte stabilization to physical constraints and an input-output linearizing control law to virtual constraints.

B. A Unified Approach to Constraint Stabilization

  • The stabilization law drives small errors in both constraint outputs and their time derivatives to zero with appropriately chosen gain matrices.The formulation assumes constraints of the form y(q, t) = 0.Source: B. A Unified Approach to Constraint… · p. 5
  • For physical constraints, the control term uses Baumgarte stabilization; for virtual constraints, it uses an input-output linearizing control law.For biped robots, the virtual-constraint law drives a solution onto the zero manifold in the hybrid zero dynamics framework.Source: B. A Unified Approach to Constraint… · p. 5
  • Substituting the unified constraint formulation and stabilization law into the dynamics yields phase-wise equations with physical forces and virtual feedback terms.The physical-force vector and virtual input-output linearizing feedback terms enter the generalized-force formulation.Source: B. A Unified Approach to Constraint… · p. 5

IV. DESCRIBING CONSTRAINED MECHANICAL SYSTEMS WITH SPATIAL VECTORS

The section uses spatial-vector algebra to describe rigid-body motion and constraints, and implements standard dynamics algorithms through that representation. It also specifies spatial transforms and notes a trade-off in the chosen orientation representation.

IV. DESCRIBING CONSTRAINED MECHANICAL SYSTEMS WITH SPATIAL VECTORS

  • Amplify computes b(q, ˙q) with RNEA, M(q) with CRBA, and constraint Jacobians and stabilization terms with an extended TJA.The algorithms are implemented using spatial-vector algebra and formulated as constraints in a later section.Source: §IV · p. 6

A. Spatial Velocities, Forces, and Frames

  • Spatial-vector algebra represents motion and force quantities as six-dimensional vectors, including spatial velocity, acceleration, force, impulse, and momentum.The spatial inertia is a 6 × 6 matrix; coordinate-vector subscripts identify links and superscripts identify reference frames.Source: A. Spatial Velocities, Forces, and… · p. 6

B. Spatial Transforms and Cross Products

  • Spatial transforms map motion vectors between frame coordinates, and the paper extracts relative orientation and position from a transform.The transform uses axis-angle notation; its rotation E and position p are defined as a rotation matrix and a vector pointing between frames.Source: B. Spatial Transforms and Cross Products · pp. 6–7
  • The chosen Euler-angle representation is straightforward to implement in a modeling language but has singularities as the y-axis angle approaches ±π.The rotation convention is chosen to match.Source: B. Spatial Transforms and Cross Products · pp. 6–7

C. Spatial Inertias

This section describes link inertias, constraint Jacobians, and the grid organization used to express hybrid trajectories. Phases and subphases group grid points by shared dynamics and additional constraints, while impulse-momentum equations connect events across subphases.

C. Spatial Inertias

  • A link’s spatial inertia is defined about its center of mass from its mass and moment-of-inertia tensor, and is transformed between frames using spatial transforms.Source: C. Spatial Inertias · p. 7

D. Spatial Jacobians

  • The spatial Jacobian maps generalized velocities to the constrained point’s spatial velocity, with nonzero columns determined by joints along the path to the tree root.Amplify computes constraints in both body-fixed and world-aligned frames; the latter represents the constraint at the same point with world-aligned axes.Source: D. Spatial Jacobians · p. 7

V. THE GRID LAYOUT

  • Grid points are constraint locations rather than time evolution; phases group points under common dynamics, while subphases add interval-specific constraints.A phase is a union of subphases with the same physical and virtual constraints, and a subphase is a consecutive set of grid points.Source: §V · pp. 7–8
  • Impulse-momentum equations connect states across subphases, such as mapping the pre-landing velocity to the initial velocity during foot-on-ground dynamics.Pre- and post-impact constraints can occupy distinct grid points whose switching-time constraint makes their absolute times equal.Source: §V · pp. 7–8

A. Modularity

Amplify uses modular NLP code blocks to express robotic algorithms as constraints, with modules designed to be replaceable and composable. Its rigid-body dynamics implementation represents kinematic-tree connectivity with ordered sets and expresses the Composite Rigid Body Algorithm as constraints.

A. Modularity

  • Modules define constraints, private and shared variables, and grid points; explicitly listing solver variables and constraints documents the NLP being solved.Variables at integer grid points belong to shared workspace and are included in the final trajectory; non-integer points can support intermediate computations.Source: A. Modularity · pp. 8–9
  • Amplify’s design permits modules with matching input/output structures to be swapped or combined into complete NLPs.The authors envision modular NLP code blocks in a repository and package manager, in contrast to monolithic libraries.Source: A. Modularity · p. 9

VI. RIGID-BODY DYNAMICS ALGORITHMS AS CONSTRAINTS

  • Rigid-body algorithms, including CRBA, RNEA, and TJA, can be expressed as constraints when the modeling language supports conditionals and recursive definitions.The algorithms’ data structures, such as a kinematic tree, are represented within the model.Source: §VI · p. 9

A. Representing the Connectivity of the Kinematic Tree

  • Amplify represents kinematic-tree connectivity as indexed ordered sets derived from a URDF-like parent mapping.Ordered sets support traversal order and recursive definitions; for example, mass-matrix elements are computed from leaves toward the root.Source: A. Representing the Connectivity of… · p. 9, Table III · p. 9

B. The Composite Rigid Body Algorithm (CRBA)

  • The CRBA constraint module computes the robot’s inertia tensor M(q), while the rest of the model depends only on M(q), allowing alternative implementations.Module-local variables can be removed or replaced without affecting the model, provided M(q) remains available.Source: B. The Composite Rigid Body Algorithm… · pp. 9–10

C. The Recursive Newton-Euler Algorithm (RNEA)

The RNEA is expressed as constraints for computing generalized forces, while the TJA extensions compute constraint-related quantities and support constraints between links. The TJA’s summed quantities require user-defined constraint frames aligned with the root frame’s axes.

C. The Recursive Newton-Euler Algorithm (RNEA)

  • The RNEA computes generalized forces through two tree passes: velocities and accelerations from root to leaves, then forces from leaves to the base.The second pass maps spatial forces back to generalized forces; the paper expresses these relationships as constraints rather than loops.Source: C. The Recursive Newton-Euler… · p. 10

D. The Task Jacobian Algorithm (TJA)

  • TJA extensions compute position, velocity, transmission matrix, bias acceleration, and constraint Jacobian, enabling constraints between links.The algorithm is designed to skip zero entries arising from the kinematic tree’s branch-induced sparsity.Source: D. The Task Jacobian Algorithm (TJA) · p. 10
  • Meaningful sums in the TJA require constraint frames aligned with the root frame’s x-y-z axes.Users specify whether a final frame is expressed with axes aligned to the world or body frame; summed constraints must fit the problem.Source: D. The Task Jacobian Algorithm (TJA) · p. 10

VII. SPECIFYING CONSTRAINTS FOR A CLASS OF FIXED-STEP RUNGE-KUTTA METHODS

Amplify encodes fixed-step Runge-Kutta integration as constraints parameterized by a Butcher tableau. The formulation supports stage reduction and allows integration schemes to vary across trajectory grid points.

VII. SPECIFYING CONSTRAINTS FOR A CLASS OF FIXED-STEP RUNGE-KUTTA METHODS

  • Runge-Kutta constraints represent each next state as the current state plus a weighted average of stage derivatives, with the weights supplied by a Butcher tableau.The tableau input avoids specifying a particular integration scheme in the model; duplicate constraints in some FSAL schemes can cause numerical issues or unnecessary variables and constraints.Source: §VII · p. 11

A. Reducing the Variable Count

  • The implementation can reduce grid points by at most two when the first or last integration stage duplicates constraints at an adjacent grid point.The stated elimination conditions are a0 = 0 for the first stage and aK = 0 for the last; both hold for FSAL schemes including Dormand-Prince and Lobatto IIIA methods.Source: A. Reducing the Variable Count · p. 11

B. Expressivity and Flexibility in the NLP Integration Scheme

  • Users can make step sizes decision variables and change the integration scheme at each grid point by assigning multiple Butcher tableaus.This flexibility supports hybrid phases or cascade approaches, allowing coarser schemes where less accuracy is needed and finer schemes where more is expected.Source: B. Expressivity and Flexibility in the… · pp. 11–12

VIII. SPECIFYING CONSTRAINTS FOR DESIRED TRAJECTORIES USING B´EZIER CURVES

The paper formulates desired trajectories with a matrix representation of Bézier curves and evaluates Amplify on robotic optimization demos. Across the reported comparisons, outcomes vary by task and implementation, with some matched objective values and one mapped trajectory comparison favoring Amplify + Ipopt.

VIII. SPECIFYING CONSTRAINTS FOR DESIRED TRAJECTORIES USING B´EZIER CURVES

  • The matrix form b(τ) = τ^T BP collects most constants into B, allowing greater computational reuse as τ and control points vary.The polynomial trajectory module is intended as a replacement library for hybrid zero dynamics research.Source: §VIII · p. 12

IX. EXAMPLES

  • Seven robot systems were tested, including five demos reimplemented from OptimTraj, TROPIC, and Horizon; reported performance averages 10 runs per demo.The authors caution that solver and release differences mean the comparisons are not always apples-to-apples.Source: §IX · p. 12

A. Comparison of Select Demos from OptimTraj’s Library

  • J ≈260.43 N2m2 for Amplify + Ipopt versus J ≈420.13 N2m2 for OptimTraj after mapping its trajectory into Amplify’s coordinate system.The paper reports that the OptimTraj result is consistent with its published result.Source: Table V · p. 13, A. Comparison of Select Demos from… · p. 13
  • Cart-pole objective values were effectively the same (J ≈229.29 N2 for minimal force; 1.15 s for minimal time), as were moving-block values (J ≈12.06 N2).OptimTraj + fmincon performed better on the acrobot problem; these demos used trapezoidal integration.Source: A. Comparison of Select Demos from… · p. 13
  • The floating-base RABBIT model had the highest cost of the three implementations (J ≈443.14 N2m2); adding two holonomic constraints increased size by 60 decision variables and 88 constraints.Despite the larger problem size, its performance metrics were comparable to the Amplify 5-DOF model.Source: A. Comparison of Select Demos from… · p. 13

B. Comparison of 7-DOF Biped Demo from TROPIC’s Library

The comparisons show that performance depends on solver settings and formulation details: Amplify converges on all three tested Spot integration methods, while Horizon converges only on RK4. The biped results also vary substantially with TROPIC and Ipopt options.

B. Comparison of 7-DOF Biped Demo from TROPIC’s Library

C. Comparison of 18-DOF Quadruped Demo from Horizon’s Library

B. Comparison of 7-DOF Biped Demo from TROPIC’s Library

  • Changing TROPIC’s ϵ affected convergence speed from the same seed, and TROPIC represents equality constraints as bounded inequalities that can cause numerical and convergence issues.The authors note that this formulation increases problem size and may not satisfy equality constraints to solver tolerances.Source: B. Comparison of 7-DOF Biped Demo from… · p. 14
  • With TROPIC equality constraints set by ϵ = 0, Ipopt found a 6.09 N2m2 trajectory in 18.97 s; with default Ipopt options, it found a 5.92 N2m2 trajectory in 207.48 s.The authors report that performance depended strongly on tuned TROPIC- and Ipopt-specific options.Source: B. Comparison of 7-DOF Biped Demo from… · p. 14

C. Comparison of 18-DOF Quadruped Demo from Horizon’s Library

  • For the 18-DOF Spot jump, Amplify was tested with COL3, RK1, and RK4; Horizon’s implementation uses compressed RK4 constraints that reduce problem size by nearly a factor of four, but other tested ODE solvers did not converge.The comparison used a Spot model with 12 internal degrees of freedom attached to a floating base.Source: C. Comparison of 18-DOF Quadruped Demo… · pp. 14–15
  • CasADi evaluated the RK4 Spot objective and constraints an order of magnitude faster than AMPL in this case, which the authors attribute to better optimization of its expression graph for that example.The authors identify this as a particular-case evaluation-time comparison.Source: C. Comparison of 18-DOF Quadruped Demo… · p. 15
  • The Spot NLPs were not exact duplicates, Amplify was less optimized than Horizon, Pinocchio, and CasADi, and the authors leave the speed difference and possible scaling issue for future work; AMPL is closed-source.The authors also document issues reproducing the results in.Source: C. Comparison of 18-DOF Quadruped Demo… · p. 15

D. Time-Optimal Motion of a Kinematic Car

The examples test Amplify on time-optimal car motion and a minimum-finger grasp, while the discussion describes a declarative NLP design intended to be reusable and reproducible. The code can be run or extended without the authors’ toolchain.

D. Time-Optimal Motion of a Kinematic Car

  • The car task bounds each wheel’s angular velocity at ±1 rad/s, and its time-optimal solutions involve discrete control switches that make derivatives nonsmooth for gradient-based solvers.The task moves from a start configuration to the origin in minimum time.Source: D. Time-Optimal Motion of a Kinematic… · p. 15
  • Four of nine solvers converged on the time-optimal car problem, each attaining an objective of 1.96 across 10 trials.Their average wall times were 0.35 ± 0.03 s for conopt, 3.85 ± 0.09 s for Gurobi, 0.94 ± 0.06 s for Ipopt, and 0.30 ± 0.18 s for LOQO; the NLP had 391 decision variables and 341 equality constraints.Source: D. Time-Optimal Motion of a Kinematic… · p. 15, Figure 5 · p. 15

E. Four-Fingered Grasp of a Block

  • The minimum form-closure grasp uses four frictionless point-contact fingers, one on each side of the block; among 58,905 four-finger placements, 2,592 satisfy form closure.The optimal number of fingers is four.Source: E. Four-Fingered Grasp of a Block · p. 15, Figure 6 · p. 16
  • The grasp NLP discretizes contact locations with physical holonomic constraints and uses binary decision variables to mark active contacts, with the form-closure condition expressed through the grasp map.The model couples this condition with q = q̇ = q̈ = 0 and nonnegative contact forces.Source: E. Four-Fingered Grasp of a Block · pp. 15–16

X. DISCUSSION

  • Amplify’s design separates formulation from instance values, uses a presolver, organizes NLP code in self-contained blocks, and aims for reusable, extendable formulations; D1–D3 come from AMPL, while D4–D5 are Amplify rules.The discussion presents these as design choices others can mix and adopt.Source: §X · p. 16

A. Let the NLP be Its Own Programming Langauge

  • Building on an algebraic modeling language lets users edit the NLP directly in a declarative style; Amplify’s core file contains 537 lines of source code capped at 80 characters per line.The file defines the NLP grid, hybrid robot dynamics, Runge–Kutta method, and Bézier curves.Source: A. Let the NLP be Its Own Programming… · p. 16
  • Amplify models may serve as an intermediate format that other transcription libraries translate into NLPs optimized for their own uses.The authors describe this as a longer-term possibility.Source: A. Let the NLP be Its Own Programming… · p. 16
  • An Internet connection suffices to reproduce an optimal trajectory, and a text editor suffices to extend the emitted AMPL code without the authors’ toolchain.The library itself is split across three files.Source: A. Let the NLP be Its Own Programming… · p. 17

B. Separate the NLP Model from Its Data

Amplify separates a reusable NLP model from its data to support reproducibility, while the section describes presolving and online services alongside design limitations and future tooling directions.

B. Separate the NLP Model from Its Data

  • Separating model from data makes Amplify’s NLP formulation generic and reusable, unlike emitted NLPs that hardcode instance data and remain coupled to the generating library.The authors identify this coupling as a reproducibility hindrance because changes must go through the library API and its toolchain.Source: B. Separate the NLP Model from Its Data · p. 17

C. Limitations

  • Amplify shifts data- and script-generation work to users, while AMPL’s closed-source status, versioning limits, and backend performance constrain reproducibility and execution.The authors also identify documentation and a more accessible frontend as needs; AMPL and solver versions cannot be specified in an NLP setup, and the backend compiler is a performance limitation.Source: C. Limitations · p. 17

1) Use Presolvers for Performant Code:

  • Over 90% of the original decision variables and constraints are often removed by AMPL presolving, which adds no significant elapsed time in the examples.The presolver removes trivially solved variables and constraints and tightens remaining bounds; it completed in under a few milliseconds for the example problems.Source: 1) Use Presolvers for Performant Code · p. 17

2) Design an Algebraic Modeling Environment for Robotics:

  • A robotics-oriented algebraic modeling environment could add NLP introspection, interactive editing, and interfaces to robotics libraries, presolvers, and solvers.The proposed environment could also support workflows involving edge hardware, data-driven processes, and learning-based architectures.Source: 2) Design an Algebraic Modeling… · p. 18

3) Build Online Services:

  • NEOS offers online prototyping, but its current speed is insufficient for many robotics applications; shared hardware and solver access could support more comparable benchmarks.The authors envision comparing solvers on common hardware and ranking them by metrics of interest.Source: 3) Build Online Services · p. 18

XI. CONCLUSION

  • The conclusion presents Amplify as an accessible, reproducible framework whose central design principle—the NLP model is the library—can be adopted by other libraries.Its features include rigid-body dynamics, arbitrary Runge–Kutta methods, Bézier trajectories, and AMPL presolving expressed in the model.Source: §XI · p. 18

APPENDIX

The appendix reviews OptimTraj and TROPIC, noting that both libraries have demos that were straightforward to reproduce, while depending on Matlab. OptimTraj provides several collocation schemes but leaves key problem components to the user.

APPENDIX

  • Both OptimTraj and TROPIC have demos described as straightforward to reproduce, but both depend on Matlab.The appendix notes that OptimTraj requires Matlab and its Optimization Toolbox through fmincon.Source: APPENDIX · p. 20, A. OptimTraj · p. 20

A. OptimTraj

  • OptimTraj provides trapezoidal, Hermite-Simpson, and fourth-order Runge-Kutta integration schemes, with users supplying dynamics, objectives, constraints, and derivatives.It wraps user inputs for fmincon, its sole underlying solver; some demos also require the Symbolic Toolbox.Source: A. OptimTraj · p. 20
  • OptimTraj emphasizes teaching and does not claim to be performative or to provide a fully featured API.It is presented as companion software to a tutorial on implementing direct-collocation transcription libraries.Source: A. OptimTraj · p. 20

B. TROPIC

TROPIC targets optimal-trajectory synthesis for hybrid dynamical systems, particularly biped robots, and offers modeling, integration, and Bézier features. Its dynamics constraints are generated for a particular robot, while its implementation uses CasADi for analytic gradients and IPOPT as its solver.

B. TROPIC

  • TROPIC targets optimal trajectories for hybrid dynamical systems with physical and virtual holonomic constraints, especially biped robots seeking provably stabilizing feedback laws.Its API covers modeling, integration, and Bézier functions.Source: B. TROPIC · p. 20
  • TROPIC generates equations-of-motion constraints using RNEA, CRBA, and TJA, with robot-specific physical data baked into the equations.CasADi symbolic variables represent state and control inputs, and CasADi computes analytic gradients of objectives and constraints.Source: B. TROPIC · p. 20
  • TROPIC supports trapezoidal and Hermite-Simpson integration, uses IPOPT only, and hard-codes first- and second-order Bézier derivatives.The Bézier polynomials use Equation 19.Source: B. TROPIC · p. 20
  • The mixed-integer example minimizes the number of fingers while selecting binary object-contact variables, and assumes zero gravity.Its listed constraints include contact-force and wrench conditions, friction, object statics, and form closure.Source: B. TROPIC · p. 21
Loading 2609.28377v1…