The parameters to tune the optimization problem. More...

#include <parameters.h>

Public Types
enum	ConstraintName { Dynamic, EndeffectorRom, TotalTime, Terrain, Force, Swing, BaseRom, BaseAcc }
	Identifiers to be used to add certain constraints to the optimization problem. More...
enum	CostName { ForcesCostID, EEMotionCostID }
	Indentifiers to be used to add certain costs to the optimization problem. More...
Public Member Functions
VecTimes	GetBasePolyDurations () const
	The durations of each base polynomial in the spline (lin+ang).
int	GetEECount () const
	The number of endeffectors.
int	GetPhaseCount (EEID ee) const
	The number of phases allowed for endeffector ee.
double	GetTotalTime () const
	Total duration [s] of the motion.
bool	IsOptimizeTimings () const
	True if the phase durations should be optimized over.
void	OptimizePhaseDurations ()
	Specifies that timings of all feet, so the gait, should be optimized.
	Parameters ()
	Default parameters to get started.
virtual	~Parameters ()
Public Attributes
std::pair< double, double >	bound_phase_duration_
std::vector< int >	bounds_final_ang_pos_
std::vector< int >	bounds_final_ang_vel_
std::vector< int >	bounds_final_lin_pos_
	which dimensions (x,y,z) of the final base state should be bounded
std::vector< int >	bounds_final_lin_vel_
UsedConstraints	constraints_
	Which constraints should be used in the optimization problem.
CostWeights	costs_
	Which costs should be used in the optimiation problem.
double	dt_constraint_base_motion_
	Interval at which the base motion constraint is enforced.
double	dt_constraint_dynamic_
	Interval at which the dynamic constraint is enforced.
double	dt_constraint_range_of_motion_
	Interval at which the range of motion constraint is enforced.
double	duration_base_polynomial_
	Fixed duration of each cubic polynomial describing the base motion.
std::vector< bool >	ee_in_contact_at_start_
	True if the foot is initially in contact with the terrain.
std::vector< VecTimes >	ee_phase_durations_
	Number and initial duration of each foot's swing and stance phases.
int	ee_polynomials_per_swing_phase_
	Number of polynomials to parameterize foot movement during swing phases.
double	force_limit_in_normal_direction_
	The maximum allowable force [N] in normal direction.
int	force_polynomials_per_stance_phase_
	Number of polynomials to parameterize each contact force during stance phase.

Detailed Description

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](https://doi.org/10.1109/LRA.2018.2798285).

#### Towr problem formulation

### Constraint discretization ### 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.

### Available steps ### 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.

Member Enumeration Documentation

enum towr::Parameters::ConstraintName

Identifiers to be used to add certain constraints to the optimization problem.

Enumerator:

Dynamic	sets DynamicConstraint
EndeffectorRom	sets RangeOfMotionConstraint
TotalTime	sets TotalDurationConstraint
Terrain	sets TerrainConstraint
Force	sets ForceConstraint
Swing	sets SwingConstraint
BaseRom	sets BaseMotionConstraint
BaseAcc	sets SplineAccConstraint

Definition at line 139 of file parameters.h.

enum towr::Parameters::CostName

Indentifiers to be used to add certain costs to the optimization problem.

Enumerator:

ForcesCostID	sets NodeCost on force nodes
EEMotionCostID	sets NodeCost on endeffector velocity

Definition at line 152 of file parameters.h.

Constructor & Destructor Documentation

towr::Parameters::Parameters ( )

Default parameters to get started.

Definition at line 40 of file parameters.cc.

virtual towr::Parameters::~Parameters ( ) [virtual]

Member Function Documentation

Parameters::VecTimes towr::Parameters::GetBasePolyDurations ( ) const

The durations of each base polynomial in the spline (lin+ang).

Definition at line 83 of file parameters.cc.

int towr::Parameters::GetEECount ( ) const

The number of endeffectors.

Definition at line 107 of file parameters.cc.

int towr::Parameters::GetPhaseCount ( EEID ee ) const

The number of phases allowed for endeffector ee.

Definition at line 101 of file parameters.cc.

double towr::Parameters::GetTotalTime ( ) const

Total duration [s] of the motion.

Definition at line 113 of file parameters.cc.

bool towr::Parameters::IsOptimizeTimings ( ) const

True if the phase durations should be optimized over.

Definition at line 129 of file parameters.cc.

void towr::Parameters::OptimizePhaseDurations ( )

Specifies that timings of all feet, so the gait, should be optimized.

Definition at line 77 of file parameters.cc.

Member Data Documentation

std::pair<double,double> towr::Parameters::bound_phase_duration_

Minimum and maximum time [s] for each phase (swing,stance).

Only used when optimizing over phase durations. Make sure max time is less than total duration of trajectory, or segfault. limiting this range can help convergence when optimizing gait.

Definition at line 212 of file parameters.h.

std::vector<int> towr::Parameters::bounds_final_ang_pos_

Definition at line 201 of file parameters.h.

std::vector<int> towr::Parameters::bounds_final_ang_vel_

Definition at line 201 of file parameters.h.

std::vector<int> towr::Parameters::bounds_final_lin_pos_

which dimensions (x,y,z) of the final base state should be bounded

Definition at line 201 of file parameters.h.

std::vector<int> towr::Parameters::bounds_final_lin_vel_

Definition at line 201 of file parameters.h.

UsedConstraints towr::Parameters::constraints_

Which constraints should be used in the optimization problem.