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

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.