Where does the cartesian space planning speed up come from using OMPL

[scrice]

This tutorial: ompl interface tutorial hints that cartesian planning is much faster because IK can be used as a generative sampler, whereas if joint space planning is enforced, rejection sampling is used. I was hoping someone could elucidate where this speed up comes from.

It seems to me that collision detection (the bottleneck for speed) has to be done the same way. Furthermore, looking into the code itself (pose_model_state_space.cpp), nothing looks too fundamentally different in the pose based state space. Sampling still actually happens in joint space.

Any help provided would be much appreciated!

[mmoll]

There is a major rewrite underway of how the OMPL interface performs Cartesian planning. It uses IK methods to project random joint states onto ones that satisfy (end effector) constraints. Unlike the current pose model state space, it preserves completeness. Please check it out here: https://github.com/ros-planning/moveit/pull/2273

[scrice]

Thank you for taking the time to respond! Looks like a nice new functionality. It appears that even there the state validity checking is done in the same way. Are trajectories found with the current pose model state space not smooth in joint space then? If joint space configurations are not considered how can one be sure that intermediate points between samples are not in collision? I think I still don’t understand where the supposed speed up comes from in using pose model state space.

[mmoll]

With the pose model state space, the trajectories are not guaranteed to be smooth in joint space. Moreover, the planning with pose model state space is not complete: a solution is not always found even if one exists. The new rewrite addresses both these issues.

Collision checking is still performed whether planning in joint space or in pose space. The documentation just means that rejection sampling of configurations tends to be much slower than using IK to find valid configurations.

[JeroenDM]

@scrice

don’t understand where the supposed speed up comes from in using pose model state space.

Rejection sampling will try random samples in configuration space and check if they satisfy the path constraints. If the path constraints are only a very small part of the configurations space, the probability of getting a sample that satisfies the path constraints is low, so it can take a while to find enough valid samples. (Collision checking is only performed after the path constraints are checked.)

The pose_model_state_space directly samples the path constraints and calculates the corresponding joint values using an IK solver, which turns out to be faster for path constraints with a small volume in configurations space. (But it comes with the problems mentioned earlier in this conversation).

Maybe this illustration of path constraints in configuration space (== joint space in the figure) can clarify my explanation a bit. Green points are valid, red points are outside the path constraints.

[scrice]

Thank you both for the responses! That makes more sense, so the performance increase scales with the size/complexity of the path constraints. It is just the sampling that is much less expensive when you have a description of the set valid path constraints in joint space to sample from.