Revision history [back]

First of all RRT is well-known to produce non-optimal paths and especially to randomly produce off-the-wall trajectories in some cases (the second "R" stands for "random" after all). Path simplification often ends up with a very nice trajectory, but it also does not avoid the problem 100% of the time.

Secondly, and I believe this is more likely the issue you observe, you rely on pose targets which might yield multiple IK solutions. If you rely on pose targets and not on specific joint goals, the random exploration is free to prefer other IK solutions. So while you might think you are asking "to move up a little", you are indeed asking to "move to this arbitrary location". If the first IK solution that can be connected is not the closest one (RRT is rapidly-exploring so this is not unlikely to happen), even the shortest trajectory to go there might look awkward.

Gijs already asked about the information on the configuration of your IK solver and solve_type: Distance is the correct choice to reduce the problem. Nonetheless, I would expect you still have problems with this.

kinematics is almost identical to UR robot

It might help to reduce the joint ranges of your robot to match specific use case. If there is only a single IK solution, planning can't succeed to move to an unintuitive solution instead.

Alternatively you might want to prefer Jacobian approaches as implemented in moveit_servo.

First of all RRT is well-known to produce non-optimal paths and especially to randomly produce off-the-wall trajectories in some cases (the second "R" stands for "random" after all). Path simplification often ends up with a very nice trajectory, but it also does not avoid the problem 100% of the time.

Secondly, and I believe this is more likely the issue you observe, you rely on pose targets which might yield multiple IK solutions. If you rely on pose targets and not on specific joint goals, the random exploration is free to prefer other IK solutions. So while you might think you are asking "to move up a little", you are indeed asking to "move to this arbitrary location". If the first IK solution that can be connected is not the closest one (RRT is rapidly-exploring so this is not unlikely to happen), even the shortest trajectory to go there might look awkward.

Gijs already asked about the information on the configuration of your IK solver and solve_type: Distance is the correct choice to reduce the problem. Nonetheless, I would expect you still have problems with this.

kinematics is almost identical to UR robot

It might help to reduce the joint ranges of your robot to match specific use case. If there is only a single IK solution, planning can't succeed to move to an unintuitive solution instead.

Alternatively you might want to prefer Jacobian approaches as implemented in moveit_servo.