The parameters to tune the optimization problem.
The number of parameters to tune is relatively small (~10), however, they do have a large impact on speed and convergence of the optimizer. Below we give some insights into how different values affect the solution and what should be taken into consideration when tuning these. For more background knowledge, refer to the corresponding paper.
Towr problem formulation
A factor that strongly impacts the solution time is how often the DynamicConstraint and the RangeOfMotionConstraint are enforced along the trajectory (given by the values of dt_constraint_dynamic_ and dt_constraint_range_of_motion_). Increasing the discretization interval of e.g. dt_constraint_range_of_motion_ to 1.5s greatly speeds up the process. However, if the discretization is too coarse, the motion of e.g. the endeffector can move way outside the bounding boxes, as long it comes back inside this box at the few times the constraint is actually enforced. This is a valid solution to the optimization problem, but of course physically infeasible. Therefore, when the solution shows the feet shooting quickly through 3D space, dt_constraint_range_of_motion_ should probably be decreased. The same logic holds for too large dt_constraint_dynamic_: This can produce motion that violate the dynamics at most times, except exactly where they are enforced. This leads to unphysical motions that will be impossible to track on a real system. The more finely the constraint discretization is set, the more sure one can be that the dynamic model is being respected.
Number of optimization variables
In order to shorten the solution time, another way is to use less polynomials, but each of longer duration. This can be achieved by increasing the duration_base_polynomial_. However, the longer this duration becomes, the less parameters (freedom), the solver has to find a solution that fullfills all the constraints, so it becomes more likely that no solution is found. This variable is related to dt_constraint_dynamic_ – if the dynamic constraint should be enforced at very short intervals, it is often also required that the base motion has enough freedom (short durations) to enable this.
One of the main reasons that the solver fails to find a solution, is when there are are not enough steps available to reach a goal position that is either too far away, or the terrain too complex. The number of steps per leg and their initial durations are set by ee_phase_durations_. On the other hand, too many steps per leg are hardly an issue and the solver simply generates more short steps, but finds a solution nonetheless. Therefore:
- push back more phases for each foot into this vector to give the optimizer more freedom in finding a solution.
Jittering (and cost terms)
Sometimes the solution to the optimization problem looks jerky, with the forces and base motion quickly jittering back and forth. This is because by default, we don't include any costs_ in the formulation. The solver has too many optimization variables (degrees of freedom) to modify and only few constraints that restrict the motion, so these extra and unnecessary values can be set to extreme values. The cleanest way to counter this is to add a cost term that e.g. penalizes base and endeffector accelerations. See Costs for some inspiration. We try to avoid cost terms if possible, as they require tuning different weighing parameters w.r.t. each other and make the problem slower. Other ways to remove the jittering are as follows:
- Increase duration_base_polynomial_ to remove some DoF.
- Decrease the overall time-horizon of the optimization problem. This is determined by the sum of all elements in ee_phase_durations_. A shorter time horizon means less base polynomials, therefore less extra degrees of freedom for the optimizer to set to extreme values.
- Decrease force_polynomials_per_stance_phase_ to have less jittering force profiles and therefore also less jittering base-motions.
Optimizing the gait
The solver is able to modify the gait to best achieve a given task. This can be turned on by calling OptimizePhaseDurations(). This can help the solver find a solution to terrains which cannot be crossed with the initialized gait. However, this optimization over the phase durations, which affect the entire motion of that endeffector, reduce the sparsity of the formulation. This increases the chances of getting stuck in local minima, as well as increases the computation time. Therefore, this option should be treated with caution. An alternative to turning on this option is initializing with different gaits and/or changing the parameters described above.
Definition at line 133 of file parameters.h.