target_current, and target_moment (= target torque) sent apply to last command that was already sent to joint. actual_xxx are values measured by joint on the beginning of current control cycle.
Just to clarify, regarding the timing of values logged to Log Viewer CSV, if one were to compare for example actual_q_# and target_q_#, should actual_q be compared to target_q of previous timestep or same timestep?
All safety checks are applied by that time, and target_current is the one that was actually sent to joints.
actual_current is measured by current sensors in joints. Safety system ensures that current is within calculated current window (that is probably not available on public interfaces), and torques donât exceed limits before they are sent to SCB. SCB ensures that actual values reported by joints donât exceed safety limits.
I am a bit confused about the phrasing âsent to jointsâ and âsent to SCBâ, do they refer to the same thing in this case, or two separate steps? i.e. is the explanation âSafety system ensures that current is within calculated current windowâ just an expansion of this: âAll safety checks are applied by that timeâ, or something completely different that happens at âjoint levelâ after target_current is sent?
I donât really understand âmax allowed joint torque per timestepâ. Configuration file defines absolute physical joint limits, and torque target is taking that value (among many others) as input to calculations in each control cycle.
By max allowed joint torque per timestep I was referring to the allowed torque range that the safety functions continuously calculate each cycle/timestep. Referring to page 82 of the manual:
"The Force Limit is the force exerted by the robot at the TCP (tool center point) and âelbowâ. The safety function continuously calculates the torques allowed for each joint to stay within the defined force limit for both the TCP & the elbow. The joints control their torque output to stay within the allowed torque range."
I ultimately would like to be able to read/derive the continuously updated âallowed torque rangeâ. Is this range related to previously mentioned current window? If so, then I hope to be able to use the value actual_current_window_# together with actual_current_#, target_current_#, and target_moment_# to:
compute the current windowâs min/max values (as shown in UR Log Viewer graphs)
then convert the min/max current to min/max torque
Not sure of the correct formula though. Do you have an explanation of how to do this?
ps. Quoted only one safety function above, but I am interested in the final range from all safety functions etc. combined
Timing is a bit complicated, and a lot of control details are UR protected IP, but generally target values are applied by motors in next control cycle.
Control commands with target values eventually end up being processed by joints.
It seems that you got other values right. Current to torque constants can be derived from target values for each joint.
Keep in mind that not all corrections, and safety system values are exposed on public interfaces.
Iâm from the technical department of Polish distributor, Iâve been working and study for some time on the impact of real values on the arm, its operation, maintaining parameters as well as optimal operation. I would like to use ai for some interesting things with UR :). Let me reactivate this topic a bit, since my question is directly related to it.
Like others, I am looking for a formula that will allow me to derive actual torque values for each joint via RTDE. The main question, is there a formula available to developers with which I can acquire this value? Maybe some method/function/libraries?
Admittedly, it is possible to acquire joint moments in the script using functions and compose this accordingly in the script being created, while testing this solution, the data collection time in the thread is a bit too small.
A lot of parameters are available in RTDE, using current, target position, currents, etc. I tried to use neural networks and linear regression to determine the correlation of these parameters with get_joint_torque() readings, although the result may not be satisfactory for me.
A simple correlation of target current and target torque - determining the motor constant based on this, and then comparing it to the current does not give satisfactory results.
I will be grateful if there are any tips for my project.
To get the force I used the function get_tcp_force() and to get the joint torques I used the function get_joint_torques, all the data I sent by Profinet communication.
However, when I plot, the joint torques calculated with the equation do not match the joint torques.
a,b,c,d,e,f are the joints 1,2,3,4,5,6 respectively.
The blue line is the torques obtained by the equation in the base frame.
The pink line is the torques obtained by the equation in the end -efector frame.
The black line is the torques obtained by the differential equations in the base frame
The green line is the torques obtained by the function get_joint_torques.
Why the joint calculated by the jacobian and the joint obtained from the function get_joint_torques do not match?
Is necessary to obtain the joint torques using the current and the torque constant?
Hello henry_esp218
I want know something about the us of (get_joint_torques).
Now I want to get the actual torque of each joint in real. Does the function included in some library? If I want to use this function, which library should be imported.It seems that the image you show is in a document. How can i get this document.
Any help you can provide would be greatly appreciated.
hello @Shuqing you can find more information in the manual reference of your robot model. however, the commands are common between the different models and the Poliscope version.
To get and store these values you can use an external program (for example python) to write the values into a TCP socket
or you can use other interfaces to write those variables like profinet, modbus, internet IP
I assume that the unit in the y-axis should be Nm for the last 6 plots?
There is two different topics that might contribute to the difference.
First get_tcp_force() is returning the flange wrench and not the tcp wrench.
Secondly the get_tcp_force() is affected by the zeroing that is triggered by either zero_ftsensor() or the different functions for setting the payload. The get_joint_torques() is also affected by both the payload that is set but also the actual physical payload that is attached.
I donât think you should record the currents since they will also include the torque for holding the robot itself.
Dear henry_esp218
Thank you for your answer.
I have connected with UR robot. But when I use get_joint_torques to get torques, the system can find the function named âget_joint_torquesâ.It reminds me that the function is not defined. Like the followed image. The code is in python with urx package
There will be some package I forgot to install ?
Hello,
This function is defined in the URScript language. This means you can use it directly in the program of the robot. For example in the program of the teach pendant in a new subtask, and then write these values using a specific type of communication socket TCP, Profinet, InternetIP, or Modbus.
If you are using an external API, read the information about it, and check if this function is available in the API.
In general, the external APIs do not have all the URScript commands.
. To get the Jacobian I am using this package 
