# UR5/UR10 typical use cases

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,

Antoine.​

edit retag 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).

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

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

( 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.

( 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.

( 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?
( 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?

( 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.

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

Sort by » oldest newest most voted

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:

#define ROBOT_CONTROLLER_FREQUENCY 125 /* Hz */

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.

more

This gives me a lot to chew on, thanks!

( 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.

( 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 ;)

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