Feature status and limitations

Scope: the source revision containing this document. “Covered” means specific committed tests exercise a capability; it is not a guarantee for every problem, hardware configuration or combination of features. CUDA modules build locally from either a wheel or a checkout. This remains research software, not a certified robot controller.

Capability	Evidence / supported scope	Boundary
Batched fixed-base SQP, PCG/BDSV, explicit warm starts	Indy7 and iiwa14 receipt modules at every paper horizon, FR3, Gen3 and UR5e at N64; numerical goldens and dynamics fingerprints on all five arms; KKT and solve tests; the direct solve’s harness built for compute_87 as well as the local GPU (0.1.7)	The three new arms have an N64 frozen holdout in constraints. Other horizons and tuning need their own validation
Python solver/controller/policy APIs	Shape, controller, hypothesis and policy tests; introductory examples; the controller’s device path (CUDA torch / JAX inputs, resident warm start) gated bit-identical to the host path over a closed loop	Raw solves retain dual/rho state but do not implicitly retain the trajectory; a hypothesis batch scores on the host
URDF code generation and native builds	Codegen freshness and custom-robot build test	NVIDIA CUDA required; native modules are not shipped in a universal wheel
Boxes, EE rows, linear/conic control rows, collision and contact-position rows	Finite-difference, residual, mask and mechanism gates; closed-loop ADMM velocity-box gate on the simulated plant (test_limits_closed_loop.py, example 09)	Finite-budget AL/ADMM solves need not be feasible; inspect violations. Enforcement needs a horizon that can brake (N ≥ 32 on the figure-8)
Contact-force (fc), exact-Hessian (eh) and RK4 (rk4) variants	Named N16 variants in the receipt (the arms; rk4 on the iiwa14 and the Go2); the RK4 step and its linearization against Pinocchio and finite differences; the end-effector position curvature switch against Pinocchio’s frame Jacobian	Separate variants, not combined configurations; exact Hessian and cost curvature are workload-dependent and their task-level effect is unmeasured; four dynamics evaluations per knot under rk4
Go2 floating-base dynamics, contact-force standing and the centre-of-mass term	N16 default/fc/rk4 modules, manifold/derivative tests, MuJoCo standing gates, the CoM term against Pinocchio’s centre of mass	Longer horizons are not supported by the receipt; standing is not walking; the CoM term is a cost, not a balance condition
Gait schedule, foot masks and swing targets	Solver-level foot-lift and programmer-plumbing tests	Schedule is supplied, not discovered; closed-loop S2 weight shift / S3 lift remain in development
Runtime and task performance	Figure refresh: seed A/B, Fig-3 (iiwa14 and Indy7), Fig-4, Fig-5, Fig-7 at their recorded revisions	Those ratios are not the paper’s speedups or measurements of the latest controller defaults; Fig-7 is reported on two task settings

Variants and features

The receipt attests four module variants: default, fc (contact-force controls), eh (the exact Hessian) and rk4 (the fourth-order step). A feature a module does not carry is refused with the message in the last column; test/test_refusals.py holds each refusal.

Feature	default	fc	eh	rk4	Refusal where unsupported
Floating base (Go2)	yes	yes	no	yes	gato.build(..., exact_hessian=True, floating_base=True) raises ValueError before compiling
Two variants in one module					gato.build raises ValueError (“separate module variants”); fc with rk4 or eh with rk4 are also compile-time errors
Cost menu	yes	yes	yes	yes	set_cost_menu raises ValueError on a module without the emitted menu (none of the shipped ones)
Cost-menu gravity target	fixed base	fixed base	fixed base	fixed base	ValueError on a floating base
Second cost frame (frame_pos_2)	plants built with cost_frames (the Go2)	same	same	same	ValueError (“needs a second baked cost frame”)
Centre-of-mass term	plants built with com=True (the Go2)	same	same	same	set_com_cost raises RuntimeError (“does not bake the centroidal families”)
Contact-force slots (fc_slots, set_fc_ref, add_fc_box)	no	yes	no	no	RuntimeError (“needs a GATO_CONTACT_FORCES build”)
Contact-position rows	plants built with contact frames (all shipped)	same	same	same	RuntimeError (“bakes no contact frames”)
Collision rows	yes	yes	yes	yes	ValueError at code generation when a link has no sphere cover
Exact Hessian (set_exact_hessian, set_cost_curvature)	no	no	yes	no	RuntimeError (“compiled without USE_EXACT_HESSIAN”)
get_lambda, debug_setup_kkt, row telemetry	yes	yes	yes	yes

The exact Hessian of the eh variant is the dynamics’ second derivative contracted with the lagged multipliers (the qq, qv, vv and uq blocks of the stage Hessian, from GRiD’s fdsva_so) plus, under set_cost_curvature, the end-effector position term’s residual-weighted curvature, followed by the stage-block PSD projection. It runs the fixed-base single-stage step with the external wrench held at zero in the second-order term; it does not carry the cost menu’s cross blocks between state and control, nor a floating-base or multi-stage second derivative.

Important operating limits

• Go2 locomotion: the next design work is base position/orientation/velocity tracking and a support-polygon plan before liftoff, then S2 and S3 gates. Re-anchoring stance targets to measured feet prevents stale prediction targets; independent world-frame drift/slip measurements are still necessary.

• Floating vector weights: effort weights have length n_actuated (Go2: 12), excluding base pose and contact-wrench slots. Posture targets/weights remain stored-q indexed (nq, Go2: 19); these are different contracts.

• Pick-place results: pools before the September 27 simulator fix (unit-quaternion-pendulum-v2) are not comparable with current runs or the paper. Current numbers are in the figure refresh. Its October 4 holdout confirms strong batched arrival rates but zero episodes satisfying all measured joint limits, including with applied-torque clamping.

• Actuation: optimized contact wrenches explain model contact forces; they are not actuator commands. Apply StepResult.u or SolveResult.u0() only. The raw solver installs no limit rows. The fixed-base controller installs ADMM boxes by default when its solver has no row groups, but this is not a torque clamp or a hardware-side safety layer. The October 23 enforcement set compares a command projection (u_clip, opt-in), a larger ADMM budget and a tighter torque penalty; the default is unchanged. The November 4 holdout closes the rho_u = 1e-4 candidate on a fresh draw: lower peak torque, worse velocity tails, the default kept. An experiment-only clipping comparison preserved goal completion under brief FR3 and UR5e saturation; Gen3 did not saturate in that development sample. Clipping is not enabled by default. A persistent Gen3 derating study reaches goals at half nominal torque but includes a fourfold velocity excursion; stronger derating triggers numerical escape guards.

• Constraints: the controller installs the URDF limit boxes under ADMM by default on fixed-base arms (MPCController(limits=...); the raw solver installs nothing); follow row-group ordering and check feasibility telemetry (StepResult.row_viol). A report-only row is not an enforced bound, and a finite-budget ADMM plan can still violate bounds. Inspect the returned row violations and residuals. The October 16 Indy7/iiwa14 and October 18 FR3/Gen3/UR5e holdouts in constraints show lower velocity peaks than unconstrained control, not universal feasibility. At N64 the new-arm default reaches every pick-and-place goal, but FR3 commanded torque peaks at 1.31 times its limit and Gen3 sampled velocity at 1.42 times its limit. Position and velocity are sampled at control ticks; these aggregates do not bound violations between samples or their duration. Substep diagnostics identify both finite-solve dynamics inconsistency and planner/simulator integration mismatch. Small box-row violations do not bound either error.

• Integration: default-stream execution is the supported path; do not assume concurrent solves on a shared solver instance are supported. JAX input producers are awaited before native pointer access. PyTorch inputs produced on a non-default stream need caller-side synchronization.

• Timing: internal solve time and MPCController.step wall time have different boundaries. Neither includes the entire robot cycle; small median durations do not establish deadline compliance. step(..., budget_s=...) bounds the solver’s SQP iterations to the budget (to within one iteration, measured on the host); it is not a real-time guarantee for the loop around it. The dated October 6 results describe their recorded source and dependency revisions, not the current dependency pin, default constraints or device-resident controller path. The October 19 matrix measures current-default native solve time on Indy7/iiwa14 N32/N64. Separate N64 call-budget measurements show that iteration-boundary budgets can still overrun. The October 20 replay measures all five arms at N64, batches 1/8 and limits off/default ADMM: NumPy calls are faster than PyTorch/JAX in this protocol. Host latency spikes remain visible; neither residency nor small medians guarantee deadlines.

• Dependencies: MuJoCo remains pinned below 3.14 pending verification of a version fixing the observed URDF-compilation crash. Do not bypass that pin based solely on a newer version number.

What the receipt proves

The committed gpu-proof.json attests the full suite on the receipt module set at the commit it names. The full test inventory is tracked in test/expected_tests.txt; the numerical contract includes 48 bitwise goldens. CHANGELOG.md records major changes. Sanitizer evidence is bounded: memcheck on the effort-vector and masked-contact gates and racecheck on a one-iteration masked-contact gate passed with zero errors, which covers the exercised kernels, not every solver execution. This is correctness and install evidence, not a performance result.

See the receipt contract and paper-reproduction policy before making broader correctness, performance or reproduction claims.