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

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

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

  Path::operator().

  Copying the steering method from the edge and passing the constraints
  of the steering method to the problem does not seem to work.

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

  in C++.

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.