Premature success using ur_modern_driver and high deacceleration

asked 2019-01-29 03:37:30 -0500

janisa9 gravatar image

Originally I addressed this issue/question at ur_modern_driver issues, but as I didn't get an answer I will try my luck in here. As I am confused what even causes the problem, my someone can help about this

  • ROS Kinetic, Ubuntu 16.04
  • Universal Robots Software 3.5.1.10661
  • UR5

1. Issue

While using ur_modern_driver standard trajectory follower together with MoveIt, I encountered that

moveit::planning_interface::MoveItErrorCode::SUCCESS

from

move_group_ptr->plan(my_plan); success = move_group_ptr->execute(my_plan) == moveit::planning_interface::MoveItErrorCode::SUCCESS;

gives premature success that results in C204A3: Protective Stop: Invalid setpoints: Sudden stop. In result, there is a rapid stop, but if the protective stop isn't triggered after this stop the given trajectory stops really hard and the next one starts as can be seen in this picture ->

Image 1 low_bandwith_false_myapp

although it should look something like this (letting trajectory finish with delay insertion after receiving success from moveit) ->

Image 2 low_bandwith_false

Basically, it should work as follows -> Trajectory execution -> when trajectory ends I get success and start to execute next trajectory. But happens this -> Trajectory execution -> Premature success of this trajectory -> next trajectory execution is started before the previous one is ended that results in sudden/rapid stop. I don't know if it is connected with ur_modern_driver or MoveIt, so I am confused where I should be looking for a solution because lowbandwidth_trajectory_follower doesn't give me premature success what leads me to 2. Issue. It knows it is somehow connected with that MoveIt trajectory execution time is lower than actual trajectory execution time, but I don't where and how it happens. Is it an issue or I am just missing something?

2.Issue

The second issue happens when lowbandwidth_trajectory_follower is used, the same movement code as with standard trajectory follower is used. As can be seen in image 3 there is high deacceleration in final moments of trajectory what results in stop that is not soft as it should be - Image 2.

Image 3 low_bandwith_true_myapp

Again is this issue or I am again just missing something?

If any additional information is needed, please don't hesitate to ask, I would really appreciate any hints and information about this situation.

edit retag flag offensive close merge delete
add a comment