for more information, see https://pre-commit.ci

  Instead of writing in the terminal.
  Also test that there are constraints before writing them.

for more information, see https://pre-commit.ci

for more information, see https://pre-commit.ci

for more information, see https://pre-commit.ci

The default timeout for innerPlanner is a positive value. However, if
the user specifically sets it to be 0, the timeout will not be set and
hence timeout will not be used to stop innerPlanner (default timeout in
PathPlanner is infinity).

buildOptProblem should allow the case when there is no waypoint to be
computed (only 1 loop transition from init config to the goal).

PathPlanner::tryConnectInitAndGoals() should be called when the goal
configuration is given.

The configSolved() method is redundant. Checks are added for the case
where the final configuration computed has been reached but the goal is
deemed not reached by the path planner.

Some other small redundancies are also removed.

Note that we need to set it **after** the problem's path projector has
been initialized.

for more information, see https://pre-commit.ci

  Path projectors are defined in core::ProblemSolver and overloaded in
  manipulation::ProblemSolver. Formerly, the overloaded method checked that
  the steering method was of type manipulation::SteeringMethod and created
  the path projector with the inner steering of the latter.

  This commit modifies this behavior since calling idl method
  hpp::corbaserver::Problem::createPathPlanner with a core_idl::Problem
  instance as input fails when the problem solver is of type
  manipulation::ProblemSolver.

Declaring a vector without explicitly initializing the values to 0 seems
to (sometimes) have strange behavior. This has been fixed.

Some comments are added to explain buildOptimizationProblem.

Previously, when the inStatePlanner fails to compute path between two
configurations on the same leaf, the roadmap generated is not added to
the main roadmap of StatesPathFinder. Now it is added so that the
roadmap gets expanded whenever inStatePlanner is used. The good side
effect is fairer comparison between different algorithms when comparing by the number
of nodes in the roadmap.

Clearer logic flows for SolveOptimizationProblem. Also, save the longest
sequence when we need to reset solution due to exceeding the maximum
fails.

Previously, we handled this case when goal is defined as a goal
configuration. However, this case may still occur when goal is defined
as a set of constraints. Moreover, the previous method does not store
the loop transition to the list of solutions, making it difficult to
re-try later on.

  "Graph-SteeringMethodStraight" and "Graph-Straight" refer to the same
  steering method.

  when robot contact surfaces are not on a freeflying object.

The graph has loop edge for every state (node), which can be used to
connect init and goal config directly if they are both in the same
state.

These errors are shown when compiled in debug mode.

Information about all the nodes in the constraint graph would be useful
for debugging, eg when checking if the constraint graph is properly
constructed.

Previously, there are multiple versions of the same function, to cater
for two cases: when goal is defined as a configuration, and when when
goal is defined as a set of constraints. This duplication is not
desirable, as we need to make changes in multiple places if we want to
make a small change in a function. This commit removes the duplication
by merging the functions together and adding checks within the new
functions to cater for the two cases.

Some modifications are needed for analyseOptimizationProblem when goal
is given as a configuration. So far we have made a few, but there may be
more.

BUG: if a certain transition list succeeds to give a configuration list for
the first time, and fails for the second time, a new transition list
will be considered, but skipColAnalysis is NOT reset. This is now fixed
by using the direct comparison with nTryConfigList_ instead of using an
additional data member.

Even though bad solve statuses are usual because sometimes it is hard to
solve for the waypoint, there could be cases where it is impossible to
solve for a waypoint for a certain transition list (although we try to
ensure that the solver should have a positive probability of solving
it, by analysing the optimization problem in an earlier step). Adding a
threshold to it would ensure that the solving step does not take an
exponential time to decide that a transition list is not suitable.