UR- MoveJ speed parameter in °rad/s

[robin-gdwl]

Hello,
I am trying to define a robot speed for joint motions in radians/s for the leading axis.
I have noticed that this is not as easy as I would have expected in the Robots Plugin.
When trying to create a speed parameter there is no way of specifying lead axis speed.
Instead there seems to be some calculations "under the hood" that convert the linear speed into an axis speed:

Robots/src/Robots/PostProcessors/URScriptPostProcessor.cs

Lines 163 to 169 in af38665

	if (systemTarget.DeltaTime > 0)
	{
	int leadIndex = programTarget.LeadingJoint;
	double leadAxisSpeed = joints[leadIndex].MaxSpeed;
	double percentage = systemTarget.MinTime / systemTarget.DeltaTime;
	axisSpeed = percentage * leadAxisSpeed;
	}

I am not entirely sure what is happening here.

Is there a way to specify joint rotation speed directly via scripting?
If not, is there a clever way to define the linear speed in such a way that we can control the joint rotation?
My workaround at the moment is to create the moveJ-commands manually and place them into the robot code as a script command. However, this is not ideal and wont result in an accurate simulation.
Thank you for any insights or hints.

[visose]

The Robots plugin uses mm/s for the translation speed of both linear and joint targets in all robots.

For joint targets, some robots, like ABB, allow to define the speed in mm/s. Other robots like UR and KUKA require to supply the joint speed (the former in rad/s and the latter as percentage of the maximum joint speed).

In these cases, the Robots plugin uses the distance (as a straight line) between targets to approximate the joint speed of the leading axis given the supplied speed in mm/s. This won't be the exact speed of the TCP, but is also the same thing ABB does internally, so all robots will behave the same.

I chose to do it this way to unify how to program all robots, is more intuitive to understand, and simpler for the user (only one type of speed units for all motion types).

I don't think I added an override to define directly the joint speed via scripting or similar. For now you could edit the generated program, using the Text Replace and Custom Code components. (This won't result in an accurate simulation as you mention).

[visose]

To reverse engineer the speed, to understand what is happening:

• Move the robot from one target to the next at maximum speed.
• Check the seconds it will take to complete the motion (asuming infinte accel).
• Check which would be the leading joint.
• Calculate the seconds it will take to complete the motion as if it was a linear motion (speed * distance between targets)
• Calculate the ratio between the max speed time and this time.
• Multiply the leading axis joint speed (in rad/s) by this ratio tp get the joint speed used.

[robin-gdwl]

Thank you for the reply and the explanation. I can see that its more predictable for users to keep the inputs the same and not change the way parameters are interpreted. It would be nice if robot manufacturers would agree to use certain conventions. Your reverse-engineering approach makes sense, I will see if I can use it as a workaround.

[robin-gdwl]

Is this still the way the speed is calculated ?
What exactly does the "Rotation" Input on the "create Speed" component do? Which Robot brands use this parameter?
I do believe an option to supply the speed of the leading joint directly would be beneficial.

When working with UR Robots there is quite a lot of things one needs to know about other robot brands in order to make sense of the different inputs and how they are interpreted and converted in the Background (Same with the TCP transformation). There is a lot of benefit in having a system where the same grasshopper script can be used with different robot brands but there should be a way of overriding the general functionality to allow for more control.

[visose]

Hi, Rotation is the maximum speed in rad/sec in which the TCP can rotate. These are really two speeds in one, the rotation around the normal and the tilt of the normal. Like other speed constraints, the fastest of both will be set to this speed.

In UR robots this is used in joint motions, as this rotation value affects the simulation, and the leading axis speed is calculated from the simulation. In linear motions (movel), unfortunately, UR script only has an argument for the translation speed (m/s), so this is ignored. Ideally this should be documented somewhere, since UR users will be confused if they use this for linear motions.

Industrial robots like ABB, KUKA, Staubli, etc. all have more similar features. The UR robots and other cobots is where you find missing things from the industrial ones.