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ļ¼
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.
