Hierarchical quadratic programming

Strict priorities between optimisation tasks#

A quadratic program can choose joint velocities, accelerations, torques, or contact forces subject to linear equalities and inequalities. Hierarchical quadratic programming groups such objectives into priority levels. Each level is solved without allowing later levels to worsen the optimum already achieved by an earlier level.

This differs from putting every objective into one weighted sum. Weights trade errors against each other, and a sufficiently large low-priority error can influence a nominally important task. A strict hierarchy preserves lexicographic priority, subject to the formulation and numerical tolerance.

Whole-body motion under constraints#

A humanoid hierarchy might place rigid-contact consistency, actuator limits, and balance constraints above hand tracking, then use posture as a final preference. Equality tasks can request a desired end-effector acceleration. Inequalities can impose joint, torque, friction, or collision bounds.

Escande, Mansard and Wieber developed a solver for ordered least-squares problems with equality and inequality constraints and applied it to constrained humanoid motion generation. Herzog and colleagues report real torque-controlled humanoid experiments using cascaded quadratic programs for hierarchical inverse dynamics and momentum control. Those results support that implementation and test platform, not every HQP controller.

HQP is a method that can implement whole-body control; it is not the whole-body control objective itself. Null-space projection can also preserve priorities for some equality tasks. HQP provides a direct way to include inequalities and changing active constraints.

Feasibility, models, and transitions#

A hierarchy cannot make an impossible top-level constraint feasible. Designers need suitable slack variables, constraint relaxation, or a controlled failure mode when contacts, limits, and task demands conflict. Poor scaling or nearly dependent constraints can also make the numerical problem ill-conditioned.

The solution is only as accurate as the robot model, state estimate, contact assumptions, and task Jacobians. Adding, removing, or reprioritising a task can produce a discontinuous command unless the controller manages transitions. Real-time use also depends on problem size, solver behaviour as constraints activate, and a reliable fallback when an iteration exceeds its deadline.