Universal Robots Forum

Some doubts about URScript: get_tcp_foce

Hello

get_tcp_force will give feedback of forces acting on the end point of the TCP.

Thank you,ksi

Is it that mean :TCP_force is the value of the external force acting on the robot TCP? If my robot is no load, this value is zero, but I have done some experiments, even if there is no load, this value is not zero.

So I wonder if the return of TCP_force is not the value of the external force acting on the TCP, but the internal force of the balancing robot.

1 Like

In ideal case when payload is set correctly forces and torques should be zero.

If you’re using CB3 robot without FT sensor, then tcp forces are estimated from joint currents, so you can expect some random error both in forces, and in torques.
If you’re using eSeries, then remember to zero_ftsensor() before reading external forces.

Thank you mmi.

Yes, we are using CB3 robots. Can I understand :the joint torques are estimated from joint currents, and then tcp forces derived from the above formula? Therefore, the error comes from the current estimation joint torque?

But, I have done some experiments.As shown below , Error of two lines is less than 10^3. so if there is a conversion formula between joint torquesand tcp forces . (such as the following formula).


image

Red line is joint torque from teching pedant through socket communication.
Red line is joint torque derived from the above formula(F:tcp forces from teching pedant through socket communication)

You’re completely right, my mistake. On CB3 you have to zero force offset yourself.
There is also description how to convert actual_tcp_force to make it relative to tcp position, instead of base.

thanks again,mmi

as far as I know,Joint torque can only be get from URscript:get_joint_torque,but we cann’t get it from 30001 or 30003 interface. After our discussion above,is it possible that:we can get TCP_force from the 30003 interface and derive joint_torque using the above formula,because we have proved that this conversion relationship is true under we get TCP_force and Joint torque from teching pedant through socket communication(previous message).

You can use joint currents that are directly proportional to torques.
It’s recommended to use RTDE interface instead of realtime, or primary interfaces, as they are for internal UR use primarily.
There are actual_current, target_current, and target_moment fields available.

Thank you, mmi

I know what you mean, We can use joint currents that are directly proportional to torques then to estimate the joint torque. But the question is that we cannot obtain the Proportional constant(We call it as:motor constant) although we have done a lot of research. As shown in the formula below,Kt is the Proportional constant (motor constant).

image

You can get rough estimate by dividing target_moment by target_current for each joint size.

Thanks, mmi

I did some experiments according to your instructions, As far as I know, the three large joints use the same motor, the motor parameters should be the same, the same for small joints. but I found some problems in the process. The motor parameters of the shoulder and elbow of the robot have larger errors compared to other axes. In addition, I did some literature research, do I need to deal with current and torque signals, such as filtering?

Thank you very much, mmi

I got the motor constant based on your guidance,I found a few problems in the process:

  1. target_ current not equal to actual_ current .
  2. target_ current multiplied by motor constant is not equal to target_moment.
  3. Is there a detailed document to introduce the specific meaning of the 30001 port data?

These questions go far beyond details that are documented for customers.

target_xxx is commanded value, and actual_xxx is calculated from robot sensors so they will be different to safety limits extent.

UR is always supportive for research projects aiming to improve our products, and you’re can try contacting local sales office providing research details.

Ok, thank you very much for your answer.

Whats the meaining of TARGET MOMENTS? Thx

Hi, all rtde fields are documented on support page

Hello mmi,

  • Are target_moment and target_current the values BEFORE the safety functions have made their adjustments, such that the final values controlling the motors are hidden?

  • Which value indicates the max allowed joint torque per timestep?

    I first thought target_moment was the max allowed torque, but judging by the logs actual_ current sometimes become greater than target_current, which I guess would mean that actual joint moment is also not limited by target_moment (i.e. target_moment is not max allowed joint torque per timestep)?

max allowed joint torque is calculated by the safety parameters.

Sorry. My question was bad formulated. What I want to know is which value of RTDE interface/LogViewer CSV can be used to read the max allowed joint torque per timestep?

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.

Target moment is calculated, and then depending on control mode (force, freedrive) desired target_current is calculated.

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.

max allowed joint torque is defined in .urcontrol/joint_sizexxx.conf file on the actual robot (torque_max).

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.

Thank you mmi for the detailed answer.

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:

    1. compute the current window’s min/max values (as shown in UR Log Viewer graphs)
    2. 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