# Some doubts about URScript: get_tcp_foce

Hi all:

Recently I have Some doubts about URScript: get_tcp_foce. Is the return value of the function such that the external force acting on the end of the robot ? Or is it used to balance the joint torque of the robot in a static state and then convert the force obtained by the formula(As shown in the picture)? I did some experiments and found that I prefer the latter,i will be very appreciate for your reply. 1 Like

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). 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). 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.

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.