get_actual_tcp_pose() with regards to a taught plane other than Base

Tony_NL

Dear DOF community,

I am using the UR10e's force sensor to detect (measure), two different heights. Thus creating a delta Z.
Firstly positioning the TCP above point 1, using a MoveL perpendicular to the plane I taught untill a certain force is detected, and the same for point 2.
The scipt code get_actual_tcp_pose() is used when a force is detected.

URscript manual:
get_actual_tcp_pose() Returns the current measured tool pose Returns the 6d pose representing the tool position and orientation specified in the base frame. The calculation of this pose is based on the actual robot encoder readings. Return Value The current actual TCP vector [X, Y, Z, Rx, Ry, Rz] 

If I understand correctly, the function always orientates itself from the "Base" plane.
Is there a way to use this function with regards to a newly taught plane?
    One which is under a slope with regards to the "Base" plane.

Unfortunately I don't have acces to the Force Copilot, which already might have this functionality.

Thanks in advance for your thouhts/awnsers.
Kind regards,
Teun van Kerckhoven

Mechatronics graduation student.

matthewd92

What are you trying to accomplish? Are you trying to measure the distance from the start to the end?  If so, you can use either the pose_dist or point_dist commands.  They will give you the distance between two poses.  The first returns the distance including rotation, the second only returns the distance between the x, y, z of the two points.

I don't know of a way to get a pose in relation to another feature other than doing a pose_sub from the actual tcp position and the pose of the feature plane.

Tony_NL

Dear Matt,

Thank you for your time/awnser.
I am trying to measure the height of an object, in this case an "eindmaat" (in Dutch), used in production to ensure correct width of a CNC part for example.
This way the result of the measurement should read 15,000mm.
I have tried this measurement on three different points, 300mm, 600mm and 1100mm from the UR10e's Base.

The three reading all differ from the expected 15,000mm, say 15,1-14,8 and 14,9mm.

I expect this to be linked with the Cobots base coordinate system and the working surface (aluminium plate) I use to measure on.
Thus am I correct in asuming the point_dist command would make no difference here?

I have included 3 pictures to make my test setup more clear, The 3d printed part does not exert force on the "eindmaat", simply to hold them in place. The blue print is my probe if you will. I am trying to replicate a CMM (in the Z axis).

matthewd92

When we do measurements like that we will touch off on a datum and then measure the part and then subtract the difference between those two points. The other thing is to move slow when doing the measurements. This gives the FT sensor time to react. Also, zero it out before each measurement. We have been able to statistically hold 0.05mm on measurement repeatability. 

Tony_NL

The speed variables I am testing with for the moveL are; 0,5 1 2 and 3mm/s to figure out how much these influence results.
The best results with regards to measurement repeatibility are around ±0,008mm (8Um).
(With a dataset of 32 measurements, each set consists of two points)

Yet the value, expected to be 15,000mm appears to differ around 0,08mm. This is what I believe has to do with the base feature/cobot mounting.

Currently I'm finding the sensor Force of 2,5N (UR10e) and indeed the 0,5mm/s to be the best settings. No analysis has been done yet of the data with regards to the distance of the base.

One conclusion I have been able to make is that 2N force detection should not be used, as this gives faulty measurements. (2N is the resolution of the UR10e sensor)

If you are interested I can email you the data/results/conclusions.

matthewd92

I’d be interested to see the results. When we are doing fine measurement we actually use the ATI Axia 80 FT sensor as it has a much finer resolution than the built-in sensor and so we can stop more reliably. We are seeing those kind of results using a CB3 which is not as precise as the e-series. 

J_Spittlehouse

Bit late to the party on this one, but you could possibly use:

PoseInRelationToFrame = pose_trans(pose_inv(frame), pose)

in this case pose being get_actual_tcp_pose().

If I understand the function correctly, this gives you the pose in relation to the Frame (which could actually be another point)

nadim_k

@Tony_nl
there is info about how to express a pose w.r.t. to a feature/taugh plane on UR forum
https://www.universal-robots.com/how-tos-and-faqs/how-to/ur-how-tos/urscript-move-with-respect-to-a-custom-featureframe-20115/

c)      Express a point w.r.t a feature. If you need to express a pose (or a point) in base-frame, as a point w.r.t feature frame:

This is how you would proceed:

Point x w.r.t base-frame has pose      : P_x_b 
Feature f w.r.t base-frame has pose   : P_f_b 
Point x as a pose w.r.t f-frame           : P_x_f 
Mathematically;        

P_x_f = (P_f_b)^(-1) * P_x_b 

P_b_f = (P_f_b)^(-1)

As script-code: 
       global P_b_f = pose_inv(P_f_b) 

       global P_x_f = pose_trans(P_b_f, P_x_b) , This is a good way to calculate the normal distance of a point from a any given plane(The z-index of the resulting pose will always be the normal distance in metres)