Skip to main content

RRTParams Struct

Configuration parameters for the RRT planner. More...

Declaration​

struct pro_rrt::RRTParams { ... }

Included Headers​

#include <pro_rrt.hpp>

Public Member Attributes Index​

unsigned intmax_iterations = 10000
doubleconfiguration_space_step = 0.1
doubletimeout_s = 0.0
intseed = 0
unsigned intseed_attempts = 1
unsigned intoptimization_iterations = 0
std::optional< Eigen::VectorXd >joint_costs = std::nullopt
boolpad_self_collisions = true
doubleworkspace_step = 0.0
boolsanity_collision_check = false
unsigned intsanity_check_max_replans = 3

Description​

Configuration parameters for the RRT planner.

Definition at line 31 of file pro_rrt.hpp.

Public Member Attributes​

configuration_space_step​

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). This is the RRT extension step and an upper bound on the spacing of collision-validation samples along tree edges and shortcut candidates. When workspace_step below is enabled (it is off by default), segments are additionally subdivided by that workspace-referred bound. A segment that would need 2^20 or more validation samples at this step fails validation outright, so a units typo shows up as failed planning rather than an unbounded stall.

Definition at line 46 of file pro_rrt.hpp.

joint_costs​

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.

Definition at line 83 of file pro_rrt.hpp.

max_iterations​

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.

Definition at line 37 of file pro_rrt.hpp.

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.

Definition at line 72 of file pro_rrt.hpp.

pad_self_collisions​

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. The post-plan sanity_collision_check is the exception on both counts: it validates against the unpadded geometry by definition and does not consult this flag.

Definition at line 90 of file pro_rrt.hpp.

sanity_check_max_replans​

unsigned int pro_rrt::RRTParams::sanity_check_max_replans = 3

Maximum number of replanning attempts after sanity_collision_check finds a collision, each with a seed decorrelated from every seed earlier attempts used (seed_attempts sweeps included). 0 keeps the check but fails on the first detected collision without replanning. Ignored when sanity_collision_check is false. Appended last so existing aggregate initializers keep their meaning.

Definition at line 141 of file pro_rrt.hpp.

sanity_collision_check​

bool pro_rrt::RRTParams::sanity_collision_check = false

When true, planTrajectoryToJointGoal re-validates the blended, time-parameterized trajectory it is about to return: every output sample is collision-checked. The motion between consecutive samples is additionally subdivided by the search's validation bounds (configuration_space_step, plus the workspace-referred bound when workspace_step is enabled), but at typical sampling rates consecutive samples are already closer than those bounds, so the subdivision is a safety net for low sampling rates rather than continuous coverage. This catches collision tunneling — the blend or an unluckily-spaced validation sample slipping through a thin obstacle — before execution instead of on the robot. On a detected collision the whole planning call is repeated with a decorrelated seed, up to sanity_check_max_replans times; if every attempt fails the check, planning fails with a PlanningError naming the colliding bodies rather than returning the colliding trajectory. A rejection of the check itself (an unsupported multi-DOF group, invalid resolution parameters, a malformed trajectory, or a rejection whose contact re-query recovered nothing) fails planning directly without consuming further replans: only a detected collision justifies spending one. The check validates against the actual, unpadded collision geometry (environment and self collisions alike), whatever padding planning used: a contact that exists only inside the padding margin is not tunneling and does not consume a replan. The corner blends are validated only by this check, so they carry no padding margin: the search's padding applies to the path it validated, and a blended corner gets only this finite-resolution check against the actual geometry. The check's effective resolution is the output sample spacing set by TrajectoryParams::sampling_rate — the subdivision bounds only cap the motion between consecutive samples — so lowering the sampling rate coarsens the check. Off by default: the check costs roughly one collision check per output trajectory sample, and each replan costs a full planning call. Ignored by planPathToJointGoal, which returns an untimed path with no blend to validate.

Definition at line 135 of file pro_rrt.hpp.

seed​

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.

Definition at line 54 of file pro_rrt.hpp.

seed_attempts​

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.

Definition at line 63 of file pro_rrt.hpp.

timeout_s​

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.

Definition at line 50 of file pro_rrt.hpp.

workspace_step​

double pro_rrt::RRTParams::workspace_step = 0.0

Workspace resolution used to subdivide motions for collision validation, in meters. It refines the validation configuration_space_step above governs. Disabled by default (0.0): the workspace-referred subdivision is off and collision validation samples exactly as in previous releases. (Independently of this flag, this release also validates the segment that joins RRT-Connect's two search trees and keeps both junction waypoints, so a fixed seed can produce a slightly different path than before either way.) Set a positive value to enable: every proposed motion segment — tree extensions during the search and candidate shortcuts — is then validated at samples spaced so that no point of the robot (attached bodies included) can sweep more than this distance between consecutive samples. The bound uses conservative per-joint reach weights computed from the robot model once per planning call — each joint's worst-case lever arm over its descendant links and attached bodies — so a base joint whose motion sweeps the arm's full lever arm is sampled proportionally more finely than a wrist joint, instead of both sharing one joint-space resolution. On the collision-tunneling benchmark, 0.1 m roughly halves tunneling through thin obstacles at 2-3x planning time in obstacle-rich scenes; smaller values catch thinner obstacles at more collision checks per segment. Samples are never sparser than configuration_space_step either way, so enabling this is a strict validation refinement. Exactly 0 is the only value that disables; any other value that is not a usable resolution (negative, non-finite, or so small or large that its square leaves the finite positive range) fails planning with a PlanningError, and a value so small that a segment would need 2^20 or more samples fails that segment's validation outright — a units typo fails planning quickly instead of stalling it inside one edge.

Definition at line 113 of file pro_rrt.hpp.


The documentation for this struct was generated from the following file:


Generated via doxygen2docusaurus 2.2.2 by Doxygen 1.9.8.