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):
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)
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.
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).
Hi, I have just updated my post accordingly. Thanks.
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.
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.
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?
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.