Adapted from Jira OCEANWATER-1099 originally reported by @AstroStucky
What happens
Trajectories planned via set_joint_value_target or set_pose_target from the moveit_commander module may vary greatly even for the same provided start and end pose/joint configuration.
This problem behaves slightly differently depending on which method is used. In the case of using set_joint_value_target, the joint trajectories to get to the final joint configuration will vary greatly from different plan calls when provided the same parameters. In the case of set_pose_target both the joint trajectories and the final joint configuration may vary greatly between calls. Different lander arm actions use one or both of these methods to move the arm, so different lander arm actions are affected differently by this problem, but as a result of this issue, all arm actions are likely to have some degree of uncertainty when they are executed in either their path taken or their final configuration.
To put it another way, an Unstow (which commands a configuration of joint positions) from a given position, will not always follow the same path. Similarly, an ArmMoveCartesian (which commands an end-effector pose) from a given position, will not always follow the same path and will not always arrive at the same final joint configuration.
Context
Under the hood, MoveIt uses OMPL for planning of arm movements. The planning algorithms offered are all stochastic in nature, which means no matter what there will be some amount of uncertainty with the plan results, and the best we can do is tweak planning parameters to minimize that amount of uncertainty. The hope of this Issue is to find the right OMPL algorithm and right set of parameters that reduces the level of uncertainty in arm path and final joint configuration; however, arm planning will always remain stochastic to some extent.
What should happen
Arm trajectories from state A to state B should result in the same path being taken and the same joint configuration being arrived at more regularly than it does now.
Adapted from Jira OCEANWATER-1099 originally reported by @AstroStucky
What happens
Trajectories planned via
set_joint_value_targetorset_pose_targetfrom the moveit_commander module may vary greatly even for the same provided start and end pose/joint configuration.This problem behaves slightly differently depending on which method is used. In the case of using
set_joint_value_target, the joint trajectories to get to the final joint configuration will vary greatly from different plan calls when provided the same parameters. In the case ofset_pose_targetboth the joint trajectories and the final joint configuration may vary greatly between calls. Different lander arm actions use one or both of these methods to move the arm, so different lander arm actions are affected differently by this problem, but as a result of this issue, all arm actions are likely to have some degree of uncertainty when they are executed in either their path taken or their final configuration.To put it another way, an Unstow (which commands a configuration of joint positions) from a given position, will not always follow the same path. Similarly, an ArmMoveCartesian (which commands an end-effector pose) from a given position, will not always follow the same path and will not always arrive at the same final joint configuration.
Context
Under the hood, MoveIt uses OMPL for planning of arm movements. The planning algorithms offered are all stochastic in nature, which means no matter what there will be some amount of uncertainty with the plan results, and the best we can do is tweak planning parameters to minimize that amount of uncertainty. The hope of this Issue is to find the right OMPL algorithm and right set of parameters that reduces the level of uncertainty in arm path and final joint configuration; however, arm planning will always remain stochastic to some extent.
What should happen
Arm trajectories from state A to state B should result in the same path being taken and the same joint configuration being arrived at more regularly than it does now.