Is your feature request related to a problem? Please describe.
While attempting to implement hard input inequality constraints (as opposed to soft constraints) and reviewing the implementation in ocs2_sqp/src/HpipmInterface.cpp, I noticed that the current interface seems to enforce equality constraints for all passed constraints.
Specifically, it appears that llg and uug are set to identical values, effectively bypassing HPIPM's native capability to handle general inequality constraints () and box constraints () efficiently.
Describe the solution you'd like
I would like to change the HpipmInterface extended to:
- Support General Inequalities: Allow passing distinct lower and upper bounds to utilize HPIPM's native inequality handling.
- Support Box Constraints: Expose the interface for box constraints directly.
My goal is to use these features for tasks such as collision avoidance and strict actuator limits.
Describe alternatives you've considered
The current alternative is to model these limits as Relaxed Barrier Functions (Soft Constraints) within the cost function. However, this does not guarantee strict constraint satisfaction, and the barrier function alters the cost landscape even when the state is far from the boundaries.
Additional context
I am curious about the design choice behind the current implementation.
Is the exclusion of native inequality/box constraints intentional due to the "Relaxed Barrier" philosophy of OCS2 (keeping the QP sub-problem equality-constrained)?
Are there known issues regarding performance (e.g., Riccati recursion overhead) or convergence stability when introducing hard inequalities into the SQP-HPIPM loop in OCS2?
Is your feature request related to a problem? Please describe.
While attempting to implement hard input inequality constraints (as opposed to soft constraints) and reviewing the implementation in
ocs2_sqp/src/HpipmInterface.cpp, I noticed that the current interface seems to enforce equality constraints for all passed constraints.Specifically, it appears that
llganduugare set to identical values, effectively bypassing HPIPM's native capability to handle general inequality constraints () and box constraints () efficiently.Describe the solution you'd like
I would like to change the
HpipmInterfaceextended to:My goal is to use these features for tasks such as collision avoidance and strict actuator limits.
Describe alternatives you've considered
The current alternative is to model these limits as Relaxed Barrier Functions (Soft Constraints) within the cost function. However, this does not guarantee strict constraint satisfaction, and the barrier function alters the cost landscape even when the state is far from the boundaries.
Additional context
I am curious about the design choice behind the current implementation.
Is the exclusion of native inequality/box constraints intentional due to the "Relaxed Barrier" philosophy of OCS2 (keeping the QP sub-problem equality-constrained)?
Are there known issues regarding performance (e.g., Riccati recursion overhead) or convergence stability when introducing hard inequalities into the SQP-HPIPM loop in OCS2?