This is the theoretical explanation on general robot manipulators and how to use it for the advanced applications with UR robots.
Attached the URScript sample is written for the purpose of better understanding.
However, it has not been tested so that it is possible to have errors.
Looking forward to your awesome development with this!
Great info! Wish other mfc’ters were this open…
But why use the Jacobian to control the robot? Why not use the IK model? It’s analytical, precise and way faster…
This is actually not about the secret of UR control software. Rather, the document just explain about the general robot theory and how to utilize the theory for advanced applications with UR robots. Even if this document is written by a UR employee, only public documents are referred to.
With respect to the inverse kinematics, the Jacobian is introduced as it is a general method. Even if it is introduced in this document, it does not mean that this method is used in UR robots. We do not know how to calculate inverse kinematics internally in the UR control software as it is regarded as confidential.
Analytical methods were used many times in the past mainly because of the calculation load. However, the analytical method depends on the mechanical design of manipulators and tends to have a bias. In general, Jacobian methods are also fast and precise enough thanks to the improved CPU these days.
Ok, well, thanks for the information, it’s much appreciated and I welcome more information like this for the future.
I’ve since implemented the rotation matrix calculations so my code matches the UR teach pendant display. Much of the stuff in the document checks out nicely, however, for a certain set of motor angles I get a sign ambiguity in the calculated rx,ry & rz (exaclty inverted). Seems that UR uses an adittional “correction factor”? does anybody know about this?
The set of motor angles that works fine: -96.43, -77.15,-109.89,-60.72,100.10, 12.95 using a tool TCP of 3.7,5.5, 343.4
Correct values, but opposite rx,ry & rz sign: -90.12,-90.27,-90.05,-90.11,90.07,-0.25
The robot is an UR10, CB3, Software version 3.7
My code and the code in the document produce exact same values and matches “wikipedia”, but the signs are occasional diffrent from the UR teach pendant…
In PolyScope we scale the rotation vector so that it looks more stable and doesn’t flicker so much.
Below is the sample code regarding the scaling.
from math import *
v_init=[-0.0012, 3.1162, 0.03889]
v=[-0.06, 0.13, -0.04]
norm=[v/l, v/l, v/l]
if ( (abs(x) >= 0.001 and x < 0.0) or (abs(x) < 0.001 and abs(y) >= 0.001 and y < 0.0) or (abs(x) < 0.001 and abs(y) < 0.001 and z < 0.0) ):
scale = 1 - 2pi / length([x,y,z])
ret = [scalex, scaley, scalez]
print "PolyScope SCALED value: ", ret
ret = [x,y,z]
print "PolyScope value: ", ret
return _polyscope(v, v, v)
Thank you. I’ve implemented the smoothing and it works fine now. It solved a real headache
There were errors in the previous version.
I apologize for the late fix.
the reason is that the Universal Robot has no central hand, meaning that the axis of the last three axis meet in one point.
Without central hand, you cannot split the inverse kinematic problem into two sub problems (achieving orientation with axis 4, 5 and 6 as well as the position with axis 1, 2 and 3) and solve it analytically.
No, it’s not. There’s a perfectly fine analytical IK solution for the UR family of robots. I think the reason has to do with the way they calibrate the robots. Look at the calibration values in the robot. Those make it near impossible for the IK to be used, yet, are trivial to process in a Jacobian solution…
This topic was automatically closed after 60 minutes. New replies are no longer allowed.