"Goal" implies a motion to a target configuration.
MoveRelative explicitly does not do that.
"Direction" is usually not used for rotations,
but perfectly valid to describe them.
I merged 544f574166
together with the first version of this rename
that got force-pushed because it was incomplete.
- remove group + timeout properties: they are passed as arguments to plan()
- move max_velocity_scaling_factor, max_acceleration_scaling_factor to PlannerInterface base class
These branches only work together:
- MoveTo / MoveRelative: common handling of "goal" property
- properties: required changes to allow for multiple inheritance
- generalize SimpleGrasp / GenerateGraspPose
- source_id -> source_flags: bits indicating configured paths
- initializers, e.g. fromName(), should throw
- ignore undeclared errors during inheritance
- on undefined error, reset the value to None
- override value only if previously set by lower-priority source
MANUAL > CURRENT > PARENT > INTERFACE
- solutions_, failures_ as SolutionBaseConstPtrs in StagePrivate
- replace processSolutions() / processFailures() by direct const-access to storage containers
- generic sendForward(), sendBackward(), spawn(), connect() methods in StagePrivate
- reuse StagePrivate's sendForward(), sendBackward(), spawn() in containers
- store created InterfaceStates in StagePrivate::states_
- Interface: ordered<InterfaceState*> (only store pointers)
allows for common handling of states of valid and failure solutions
- remove additional state+solution storages
- containers: internal->external state mapping as InterfaceState* -> InterfaceState*
- remove bool return value
- always create a solution trajectory, also in case of failures
- success/failure determined from solution.isFailure()
minor adjustments during cherry-pick