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.
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
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.
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.
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.
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.
I read the code in pose_model_state_space.cpp but I can’t seem to find nor understand how you do sampling in the cartesian space. Is it possible to get a clarification ? an intuitive example or some lead ?
