yijiangh
commented
6 years ago Figured out finally! In 1fc628d, the planning connecting reset and goal_state is actually not computed by moveit. Instead, because of the previous issue on the "time gap" between transition and plan, the system automatically interpolate the joint, and the trajectory is really similar to moveit's result, which leads to the illusion of "oh moveit plan for reset and goal state in one-shot".
In 1fc628d, the time result is: [ INFO] [1509046745.008879028]: process #15_sp transition [ INFO] [1509046745.008902889]: time stamp: 1509046946.081960516, first time from st:0.000000000, last time from st: 9.248269201 [ INFO] [1509046745.008953191]: [PP] process #15, subprocess - jt array size: 5
[ INFO] [1509046745.009033179]: process #15_sp process [ INFO] [1509046745.009061230]: time stamp: 1509046955.330229717, first time from st:19.651169742, last time from st: 20.369503540
And the last point in the trajectory is:
points[17]: positions[] positions[0]: 0.08 positions[1]: -1.57 positions[2]: 1.74 positions[3]: 0.08 positions[4]: 0.17 positions[5]: -0.08 velocities[] velocities[0]: 0 velocities[1]: 0 velocities[2]: 0 velocities[3]: 0 velocities[4]: 0 velocities[5]: 0 accelerations[] accelerations[0]: -0.0161765 accelerations[1]: 0.461066 accelerations[2]: -0.0895979 accelerations[3]: -0.977756 accelerations[4]: -0.744877 accelerations[5]: 0.223947 effort[] time_from_start: 4.624134601
This is the reset pose, not the goal state!
Thus, a second moveit planning, connecting reset and start pose, is needed. And then we need to stitch these two trajectories (last_pose -> reset pose, reset_pose -> goal state).
still happens in process transition that requires resetting pose. (everything else is working perfectly.)