I am trying to get sequences of multiple moves working with the za6. After getting the individual moves working well, I have switched to using the exact same constraints and planners but with the sequence_move_group action instead of move_group. I am hoping to speed up my overall process, so I want the arm to pass through or close to my waypoints quickly without coming to a full stop if possible. I am using the pilz PTP planner. As mentioned on the moveit website, if I understand correctly, the blend radius parameter is supposed to allow me to set a radius that blends the two sequences together. However, if I set the blend radius to anything other than 0, then the arm moves correctly to the first waypoint, but then encounters some error and moves very slowly, sometimes jerking violently to get to the end position. Occasionally, the move executes correctly, but most times, the abrupt moves happen after reaching the first waypoint.
Is anyone else having issues with this? I am unsure whether this is an issue specifically related to tormach’s custom version of moveit, my configuration, or moveit in general. I am still analyzing the trajectory and the output messages from the nodes
The ZA6 unfortunately does not currently have an option to run a series of joint/linear moves continuously, however I wanted to let you know that I have added this idea to the feature request list.
Thanks so much for replying and adding that to the request list. However, could you please clarify your statement a bit?
Do you just mean that your pathpilot program does not have the option to run a series of joint moves continuously? I should have said that since I already have a rather large code base available of custom ROS code, I am using moveit and the move_group node directly instead. I am not using pathpilot except as a development and convenience tool.
The standard pilz planner has blending available and I think it is trying to blend by the plan it produces, but it is just a very poor blending plan. The blend time is much greater than the total time of the two moves I am blending and it does not accelerate properly because of the blend, leading to jerking. It may have something to do with the time optimization plugin, but I didn’t want to chase that as a solution if tormach’s moveit branch specifically changed something with blending. So I will clarify my question as this:
Does tormach’s custom version of moveit remove or explicitly change the blending code in the pilz planner?
Going back to your posted problem, I will do my best to help to narrow down the issue, although personally, I have not worked with this feature of Pilz before.
Could you post the final multi-segment trajectory produced by Pilz PTP planner? Could you plot it across the timestamp time domain [single joint is enough] ? You can capture the trajectory simply by listening to the topic that produces the trajectory and send it to one of the topics of joint_trajectory_controller. Or if you make calls to API in your code and then forward the plan to
to ros_controller, you might just save this trajectory to .csv and place it here.
Some more questions:
Do you witness the same problem when you run the same blended sequence in simulation only?
Could you post some more details on the planning results you are getting for this multi segment PTP move?
What happens exactly when the blending radius is zero? Is it all good? Can you see gradual move quality deterioration once you gradually change the blending radius?
Is the behavior of this jerky motion deterministic when you run the same program several times?
Is this jerk also abrupt when the segments are short? (Small angular moves)
Is the jerk present throughout all the segments that are executed and come after the 1st segment?
Is the jerk bigger when the same planned move sequence is planned with slower velocity scale?
Is the jerk present at the presumed blending part between the segments, or everywhere after the 1st segment?