|
MoveIt Pro API
Core Behaviors for MoveIt Pro
|
Configuration parameters for the RRT planner. More...
#include <pro_rrt.hpp>
Public Attributes | |
| unsigned int | max_iterations = 10000 |
| double | configuration_space_step = 0.1 |
| double | timeout_s = 0.0 |
| int | seed = 0 |
| unsigned int | seed_attempts = 1 |
| unsigned int | optimization_iterations = 0 |
| std::optional< Eigen::VectorXd > | joint_costs = std::nullopt |
| bool | pad_self_collisions = true |
Configuration parameters for the RRT planner.
| double pro_rrt::RRTParams::configuration_space_step = 0.1 |
The step size in the configuration space, as an L2 norm over the group's active variables (radians for an all-revolute group; a prismatic joint contributes meters to the same norm).
| std::optional<Eigen::VectorXd> pro_rrt::RRTParams::joint_costs = std::nullopt |
Optional per-active-joint costs that bias which joints the search prefers to move. One entry per active joint of the planning group, in getActiveJointModelNames() order (the same customer-facing surface every other joint-cost consumer takes); each must be finite and at least moveit_pro::joint_costs::kBaselineCost (1.0). A higher entry makes travel on that joint cost more, so the planner spends its motion elsewhere. std::nullopt or a size-zero vector leaves planning unbiased and byte-identical to the cost-free planner. The costs are validated against the group and expanded to per-variable form up front (fails with a PlanningError naming the offending joint if invalid), then bias every stage that ranks by cost — RRT-Connect's nearest neighbor, the multi-seed tie-break, and the Informed RRT* refinement — while step size, segment validation, and shortcutting stay in raw configuration-space units.
| unsigned int pro_rrt::RRTParams::max_iterations = 10000 |
Maximum number of iterations for a single RRT-Connect run. Under multi-seed mode (seed_attempts > 1), this is the cap per attempt; total RRT-Connect work scales as seed_attempts * max_iterations. The Informed RRT* refinement budget is governed separately by optimization_iterations.
| unsigned int pro_rrt::RRTParams::optimization_iterations = 0 |
Number of Informed RRT* refinement iterations to run after RRT-Connect. The planning pipeline is: optimization_iterations == 0: RRT-Connect (maybe multiple seeds) + Shortcut. optimization_iterations > 0: RRT-Connect (maybe multiple seeds) + Informed RRT* + Shortcut. The returned path is guaranteed to be no worse (in configuration-space length) than the unrefined RRT-Connect result. Iteration count rather than wall-clock budget is used for reproducibility: same seed + same scene + same iteration count produces a bit-identical trajectory across machines.
| bool pro_rrt::RRTParams::pad_self_collisions = true |
If true, the link padding set in the planning scene also applies to self-collision checks: robot links against each other, against other robot bodies, and against attached objects. If false, those checks use the unpadded geometry, and planned paths may have zero clearance between those bodies. Robot-environment checks use the padding either way.
| int pro_rrt::RRTParams::seed = 0 |
The seed to use for the random number generator. The same seed will always generate the same deterministic sequence of random numbers.
| unsigned int pro_rrt::RRTParams::seed_attempts = 1 |
Number of RRT-Connect runs to attempt with different seeds before picking the cheapest path. When > 1, the planner runs RRT-Connect multiple times and keeps the result with the shortest configuration-space path. The chosen result is then fed to the optional optimization step. Useful when a single RRT-Connect seed gets stuck in a sub-optimal homotopy class: running multiple seeds explores different initial routes and the optimizer can then refine the best one. Cost is roughly linear in the number of attempts; RRT-Connect itself is cheap relative to optimization, so seed_attempts=10 typically adds only a fraction of the optimization budget.
| double pro_rrt::RRTParams::timeout_s = 0.0 |
The timeout for the planner in seconds. If 0.0, the planner will terminate only when the maximum number of iterations is reached, or a solution is found.