26 lines
1.2 KiB
Markdown
26 lines
1.2 KiB
Markdown
# MovementTest OSQP Iteration Limit Design
|
|
|
|
## Goal
|
|
|
|
Allow the trajectory-observation MovementTest to configure the OSQP iteration cap separately from the solver time budget, with a default that can be reached within the existing 0.50-second test budget.
|
|
|
|
## Decision
|
|
|
|
Add an integer `MaximumOsqpIterations` setting with a default of `12000`.
|
|
|
|
The current target machine completes 4000 iterations in about 153ms. The 12000-iteration default is therefore expected to fit approximately within the existing 0.50-second `SolverTimeoutSeconds` budget. A 20000-iteration default would likely be cut short by the time budget first.
|
|
|
|
## Scope
|
|
|
|
- Add, snapshot, and validate `MaximumOsqpIterations` in `TrajectoryObservationSettings`.
|
|
- Expose it as a public MovementTest parameter with default `12000`.
|
|
- Copy it to `EmPlannerConfiguration.Solver.MaximumOsqpIterations` for an observation session.
|
|
- Prove that a custom value is present on the emitted EM planning request.
|
|
|
|
## Non-goals
|
|
|
|
- Do not modify `SolverTimeoutSeconds` from its current 0.50-second test default.
|
|
- Do not relax `AbsoluteTolerance`, `RelativeTolerance`, or `StrictResidualTolerance` from `1e-5`.
|
|
- Do not change the production EM defaults, vehicle constraints, map, or observe-only command policy.
|
|
|