-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ur_modern_driver sometimes keeps executing one trajectory list behind #95
Comments
This may be related to my PR #101 which addresses some race conditions present in the trajectory action goal/cancel callbacks. Maybe you can check if you can still reproduce the problem with #101? I also noticed that the error string is never reset, so subsequent action calls after a failure will always return the old error string. |
Interesting. I do noticed that this problems seems to happen more often with more stop trajectory in the middle of execution, although it usually happened randomly. That might be in fact related to the issue you addressed on your PR. I will try #101 and get back to you. It might take few days to ascertain whether it fixes this problem or not, given the randomity behavior of this bug. |
I haven't seen the retained trajectory bug on #101, but the server appears to be deadlocking after running for a period of time. Output from the follow_joint_trajectory/status channel:
Output from node:
Action 96 did not execute anything (maybe the deadlock starts here?), so the client timed out and sent a cancel request. Notice that the debug statements say it's trying to cancel the 96 goal twice. After this point, the node is completely locked, and sending additional goals or cancels has no effect and produces no debug statements. This behavior has been observed multiple times over the past hour or so. |
I am also observing the retained trajectory bug issue. Ours seems to be triggered infrequently by a trajectory cancellation. Has #101 demonstrated an appropriate fix? |
I can't guarantee correctness, but we were having the same problem, and #101 has fixed it, or at least made it much more infrequent. I can also confirm we also experience very occasional deadlock with that pull request, but that is a MUCH more preferable mode of failure. This is a dangerous bug! I'm surprised that pull request has been sitting for a year. Our UR5 would freak out every once in a while when we cancelled and then gave a new trajectory. |
I am also facing the same issue. If I lower the velocity slider bar in the UR teach pendant and run the trajectory, the robot goes into an abrupt protective stop. After which, I enable the robot from the pendant and cancel the goals and send a new trajectory. This time the robot goes into various jerky random motions before going to desired pose. This must be due to the retained trajectory. Has anyone found a proper fix to the problem? I will check #101. |
I'm closing this as we've officially deprecated this package. Refer to the announcement on ROS Discourse. |
|
Hi,
My research group at university has been using ur_modern_driver for awhile, and sometimes we noticed a strange bug where ur_modern_driver never finishes executing a trajectory (it just stopped halfway). Whenever this happened, after we cancel the goal, if we input a new trajectory list, it will be executing 1 trajectory list behind.
here is the log we have when it happened. Note: sec 24 in
follow_joint_trajectory/result
and sec 26 in/follow_joint_trajectory/goal
is the last published msg/response we got before cancelling the goal.Afterward, the
follow_joint_trajectory/result
always says error code: 0 and error_string: Goal canceled by client. The published joint state reflects the actual robot joint position.Restarting the ur_modern_driver will temporarily fix this problem, until it resurfaces for unknown reason.
Any helps would be appreciated,
Felix
rostopic echo /follow_joint_trajectory/goal
rostopic echo /follow_joint_trajectory/goal
The last
/joint_states
when the robot never finishes/execute the trajectory we sent.The text was updated successfully, but these errors were encountered: