Revision history [back]

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.

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

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

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

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 */