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

UR5/UR10 typical use cases

asked 2015-02-25 03:48:06 -0500

arennuit gravatar image

updated 2015-02-25 18:58:06 -0500

Hi all,

We are currently reviewing the UR5 arm specifications to make sure it can cope with all our requirements and later invest and buy one arm. One criterion on which we focus is the possibility for the arm to follow a trajectory planned on an external PC. Here is our desired setup:

  • We have a ROS external PC

    • This external PC generates trajectories for the arm
  • The planned trajectory is sampled on the ROS PC

    • Each sample is individually sent to the UR controller (via Ethernet): we want no interpolation between samples

As far as I know the communication between the ROS PC and the UR controller is rather limited in terms of frequency (50Hz for UR script and 120Hz for the C-API). This limits the complexity and speed of the trajectory the ROS PC can specify to the UR controller - as you can only send 50 samples per second (complex and quick trajectories may require more samples than this).

In order to get a better understanding of the applications and use cases possible, I have a few questions:

  • Are there people around here who have the same setup?

  • What kind of application and use case do you use this setup for?

  • Are you somehow limited in what you do, by the communication frequency?

  • Do you use UR script (ur_bringup) or the C-API (ur_c_api_bringup)?

  • Do you have the UR controller interpolate between the trajectory samples you provide?

--- EDIT ---

What is meant by "we want no interpolation between samples" relates to the 2 control modes usually possible when streaming desired configuration samples to a robot controller periodically (a sample = position + velocity + acceleration):

  1. Either the controller interpolates between the samples, so these samples are seen as the 2 extremities of a new (sub)trajectory

    • This mode allows to specify consecutive samples which are rather far away (as they are interpolated)

    • But the mode is not compatible with all applications as the samples may themselves come from a higher level planned trajectory (and you do not really want a "black box" interpolation in this case)

  2. Or the UR controller uses an incoming sample "as is" and straightforwardly as a new set point directly provided to the low-level control of the arm. The low-level joint PID (or whatever type of low-level control is used) makes sure the set point is reached as fast as possible

    • This requires the contiguous samples to be close in space

    • This mode allows an external industrial PC to generate its own trajectory and have it executed by the UR5 arm. This is the mode I am interested in

Now "we want no interpolation between samples" means we do not want behavior 1: what we look for is behavior 2.

Kind regards,


edit retag flag offensive close merge delete


Just a quick comment: "we want no interpolation between samples": perhaps you should clarify this a bit, interpolation where? The UR controller will obviously interpolate at some level (unless you can generate trajectories at the ctrlrs interpolation step perhaps).

gvdhoorn gravatar image gvdhoorn  ( 2015-02-25 05:44:37 -0500 )edit

Hi, I have just updated my post accordingly. Thanks.

arennuit gravatar image arennuit  ( 2015-02-25 18:59:28 -0500 )edit

Even your option 2 will result in the controller interpolating your TrajPts if you don't sync with the controller interpolation step (and use some supported method of submitting points to the ctrlrs motion controller). Only the c-api driver does that right now, afaik.

gvdhoorn gravatar image gvdhoorn  ( 2015-02-26 01:16:11 -0500 )edit

As to "120Hz for the C-API": that is a fundamental limit of the UR controller: its internal control frequency is 125Hz. The network comm between ROS & the C-API driver running on the ctrlr does not impose that limit.

gvdhoorn gravatar image gvdhoorn  ( 2015-02-26 01:17:47 -0500 )edit
  1. You mean the low-level joint control (the PID or so) runs at 125Hz? That does not sound like much...
  2. For the interpolation, do you mean that if samples are not synched, the UR box modifies the samples' value to match it with the value it "should have" at the time the sample is accounted for?
arennuit gravatar image arennuit  ( 2015-02-26 06:46:19 -0500 )edit

Hello gvdhoorn, I am curious on how you got to know that the C-API synchronizes the provided samples with the samples consumed by the controller. Also, do you know more about how this mechanism is achieved?

arennuit gravatar image arennuit  ( 2015-03-12 13:33:47 -0500 )edit

That statement was based on experience with other (industrial) robot control system internals. As to the C-API and 'syncing': I haven't heard that from UR themselves, if that's what you mean to ask. Comments in the C-API headers lead me to conclude that. There is always interp., even in c-api.

gvdhoorn gravatar image gvdhoorn  ( 2015-03-12 15:10:47 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2015-02-26 07:13:51 -0500

gvdhoorn gravatar image

updated 2015-02-26 07:22:25 -0500

1 . You mean the low-level joint control (the PID or so) runs at 125Hz? That does not sound like much...

From section 1.7.2 - Thread scheduling, in chapter 1 - The URScript Programming Language in the script_manual_en.pdf (version 1.8, page 4):

The robot must be controlled a frequency of 125 Hz, or in other words, it must be told what to do every 0.008 second (each 0.008 second period is called a frame). To achieve this, each thread is given a “physical” (or robot) time slice of 0.008 seconds to use, and all threads in a runnable state is then scheduled in a round robin1 fashion.

This obviously does not mean that the joints themselves are controlled at 125Hz (they each have a local (micro) controller), but I do believe this text states that the URControl daemon itself generates joint setpoints at that rate (or at least: the URScript environment seems to use that time granularity when it comes to motion commands).

2 . For the interpolation, do you mean that if samples are not synched, the UR box modifies the samples' value to match it with the value it "should have" at the time the sample is accounted for?

Most (industrial) robots have something called an interpolation time, it is often the time between two successive iterations of the high(er) level motion control loop. For a UR, this is apparently run at 125 Hz. IIUC you'll get 1-on-1 execution of your TrajPts if you supply the controller with new points (in time and space) at every iteration (spaced out for the 8 ms period).

Edit: the C-API headers document the 125 Hz frequency as well:


Edit2: you might also like to read Real-Time Robot Trajectory Generation with Python by Morten Lind, Lars Tingelstad, and Johannes Schrimpf. It contains some more information on the lower level systems in the UR controller.

edit flag offensive delete link more


This gives me a lot to chew on, thanks!

arennuit gravatar image arennuit  ( 2015-02-26 07:47:11 -0500 )edit

Well, it's not really an answer to your question, more of a comment (that didn't fit in the comment box). I hope you get some responses to your other points.

gvdhoorn gravatar image gvdhoorn  ( 2015-02-26 07:58:43 -0500 )edit

This is indeed not the final answer but it gives food for thoughts ...waiting for the actual answer ;)

arennuit gravatar image arennuit  ( 2015-02-26 08:38:32 -0500 )edit

Question Tools



Asked: 2015-02-25 03:48:06 -0500

Seen: 1,828 times

Last updated: Feb 26 '15