UniversalRobots
Using scaled trajectory controller with tool contact triggers "velocity exceeds" message
Affected ROS2 Driver version(s)
3.0.2
Used ROS distribution.
Other
Which combination of platform is the ROS driver running on.
Docker
How is the UR ROS2 Driver installed.
Build both the ROS driver and UR Client Library from source
Which robot platform is the driver connected to.
Real robot, UR E-series robot
Robot SW / URSim version(s)
5.20
How is the ROS driver used.
Through the robot teach pendant using External Control URCap
Issue details
Summary
When tool contact triggers on something soft while using the scaled joint trajectory controller for trajectory execution, the teach pendant reports this error:
Issue details
Suspected cause is that the robot has stopped motion and even moved a little in the opposite direction from what the controller is planning, and the controller does a couple of update cycles after the robot has stopped motion, and therefore commands it to move very fast to catch up, triggering the message.
Steps to Reproduce
build the driver with this PR checked out. Use the trajectory_until_node (Available from PR) to execute a trajectory with the scaled joint trajectory controller. While it is executing trigger the tool contact by having it drive into something soft, so the robot pulls back some distance. The error message should now be shown on the teach pendant. This can take a few tries, but the faster the robot moves, the easier it is to trigger.
Expected Behavior
The teach pendant should not report an error message when encountering tool contact with the scaled joint trajectory controller running.
Actual Behavior
The teach pendant reports the error shown above.
Relevant log output
Accept Public visibility
- [x] I agree to make this context public
This could also be an error in the way that tool contact and JTC is combined. But thank you for recording this for now.
@urfeex We're encountering this same issue when simply using the (scaled) JTC and the robot collides with something, i.e. when PROTECTIVE_STOP gets activated. The related problem also arises: https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/issues/1252
The issue doesn't appear when using the passthrough trajectory controller.
A fix or a workaround would be highly appreciated as this is blocking us from delivering a project to the customer.
@okvik Thank you for that additional information.
One source of this that I can imagine is that the controller progresses in the trajectory before speed scaling is set to 0 by the robot but the robot already stopped. Thus, the next setpoint would be too far away for the limit check. If the limit check wasn't there, the robot would probably have a jerk when restarting after protective stop has been released.
A fix isn't that easy conceptually, as the limit check in this case does exactly what is supposed to do: avoid sudden motions. However, the SJTC seems to have compatibility issues with that that need to be further investigated / mitigated.
As a workaround you could increase the limit check's tolerance by modifying it here. If you're not building from source, you would have to save the modified urscript file somewhere else (e.g. your own bringup package) and have your own set of launchfiles bringing up the robot, as the urscript is passed here.
I hope that helps quickly getting around this.
@okvik Thank you for that additional information.
One source of this that I can imagine is that the controller progresses in the trajectory before speed scaling is set to 0 by the robot but the robot already stopped. Thus, the next setpoint would be too far away for the limit check. If the limit check wasn't there, the robot would probably have a jerk when restarting after protective stop has been released.
A fix isn't that easy conceptually, as the limit check in this case does exactly what is supposed to do: avoid sudden motions. However, the SJTC seems to have compatibility issues with that that need to be further investigated / mitigated.
As a workaround you could increase the limit check's tolerance by modifying it here. If you're not building from source, you would have to save the modified urscript file somewhere else (e.g. your own bringup package) and have your own set of launchfiles bringing up the robot, as the urscript is passed here.
I hope that helps quickly getting around this.
Thank you so much for the tips.
I tried increasing the joint limit but this is a no go since the resulting resumed motion is insanely violent. The reason we're having this problem to start with is that we're driving the robot with pretty much maximum velocity / acceleration so any time it gets stopped due to protective stop it ends up quite off the trajectory. Everything worked fine in testing before we started to crank up the settings to achieve some insane cycle times.
Another path forward is to forego resuming trajectories that are stopped because of protective stop. Due to the nature of the work performed by the robot it is almost straightforward to back up and restart the sequence at some previous point. Or even to re-plan and re-exec the motion from the new starting point. This, however, was blocked because of https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/issues/1252 but with shortening a message in the urscript it seems we can proceed with this solution!