ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Specifying TCP velocity using ur_modern_driver

asked 2018-03-12 02:59:51 -0500

prajval10 gravatar image

The trajectory planner of the ur_modern_driver states: "This method does cubic interpolation between two points, given the absolute time between the, the time at which the position should be found, and the velocity at the two points. Note that this function does not adhere to any constraints and, as it is a cubic interpolator, is not jerk continuous"

How can we limit the TCP velocity to 250 mm/s as specified by safety standards for collaborative robots?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-03-12 04:20:11 -0500

gvdhoorn gravatar image

updated 2018-03-12 04:48:53 -0500

How can we limit the TCP velocity to 250 mm/s as specified by safety standards for collaborative robots?

You'll have to do that outside of the driver, as the driver does not have any concept of Cartesian velocity, nor does it concern itself with the safety aspects that you refer to.

The ur_modern_driver only exposes a FollowJointTrajectory action server. As the name implies, that server accepts goals containing a JointTrajectory. There is no support for Cartesian trajectories at this point (there is no support at the ROS API level, they could be sent to the controller using the /urscript topic).


Edit: I'm also slightly confused by your question. Every UR robot comes with a built-in safety system that monitors robot safety and will stop the robot if it violates any of the built-in restrictions. Layering safety is always a good idea, but at the very least, the built-in safety of the robot should prevent it from violating the relevant standards.

ur_modern_driver does not subvert, circumvent or disable any of these checks in the controller, so you can still rely on the robot controller to take care of safety (on the robot level only, of course. System-level safety is not the controller's responsibility).

edit flag offensive delete link more

Comments

Okay, I understand. However, if I look at the rostopic /tool_velocity, I'm assuming the linear velocity values to be in (m/s) units and sometimes they go beyond 0.25 m/s limit. Is there any data on what is the limiting tool velocity imposed by UR controller?

prajval10 gravatar image prajval10  ( 2018-03-12 04:37:22 -0500 )edit

Note also that limiting the TCP velocity to 250mm/s is not always required, if I interpret the relevant standards correctly.

gvdhoorn gravatar image gvdhoorn  ( 2018-03-12 04:38:09 -0500 )edit

That data is coming directly from the controller, the driver does not do any processing or control anything there.

Is there any data on what is the limiting tool velocity imposed by UR controller?

I would recommend to consult the relevant documentation that UR provides about your controller. ..

gvdhoorn gravatar image gvdhoorn  ( 2018-03-12 04:39:09 -0500 )edit

.. All safety aspects are documented, as well as the safety system and how to configure it. Assuming you have a CB3 controller, there are extensive documentation and configuration options available.

gvdhoorn gravatar image gvdhoorn  ( 2018-03-12 04:39:59 -0500 )edit

I checked the CB3 documentation and it's possible to set hard on the TCP max speed (default 1500 mm/s) to 250 mm/s. However is this recommended? Also you say, limiting the TCP velocity to 250mm/s is not always required. This is ambiguous?

prajval10 gravatar image prajval10  ( 2018-03-12 04:58:17 -0500 )edit

re: is this recommended: I wouldn't know.

re: not always required: iirc, there are various 'zones' around a collaborative robot and the position of the co-worker(s) relative to those zones is what determines what the robot can and can't do. I'd recommend to review the literature about this.

gvdhoorn gravatar image gvdhoorn  ( 2018-03-12 05:03:29 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2018-03-12 02:59:51 -0500

Seen: 342 times

Last updated: Mar 12 '18