Problem with getUserDefinedRobotPosition / joint positions

Technical Questions
1

Problem: the shown 'Set Waypoint’is different form ‘Edit pose’ and both different from ‘shown picture’.
Set Waypoint shows:
image
Edit pose shows:

editpose
editpose800×617 42.6 KB

‘summary’ picture shows:
spicture

Example show above is of EllipsPos4. However, all saved waypoints do have similar mismatch problem .

Reproduce, use URCAP Ellipse Swing. Problem occurs if TCP is not 0,0,0,0 .
Set tcp to:
tcp
Note that the difference between ‘Set waypoint’ and ‘Edit pose’ is exactly the values of the TCP !. The shown ‘summary picture’ seems to have the correct TCP but having another, not correct pose.

When going tho ‘Set Waypoint’ of one of the mismatched waypoints, and click OK, now all 3 data views are in sync with what is shown in ‘Set Waypoint’

Using version 3.7.0

2

Thank God i’m not the only one facing this odd Bug.
related to Calling Pose from URCap generated Waypoint misses TCP Offset

i’m also having issues with URCap generated Waypoint that have a wrong inverse kinematic.
This is still present on the latest UR10e-Series!

@jbm please fix this

1 Like
3

Is the issue only related to the graphics?
Or is the wrong (further away) joint position also used when running the program or using “Move here”?

4

Yes, it is also the wrong joint position when running or using ‘Move here’. So, not only in graphics shown.

5

Is there any progress perhaps on this issue ? We are struggling now in our URCAP development. Thanks .

6

We are investigating the issue.

1 Like
7

Thank you @m.birkholz for pointing out this post for me. I am facing the same problem.

Note: I was able to separate another bug that at first seemed to be part of the same. It is covered in Capturing pose with a button, questions and troubles.

I’m working in the URCap for a control disc with 2 buttons that goes in between the wrist and the tool.
• One button is for freedrive.
• The other is for recording waypoints.

I’m having trouble creating the right pose for this waypoints.

  • I receive well the pose and joint positions via RT (30003 port). This data includes the TPC .

  • But, when I use createFixedPositionConfig I’ve come to the conclusion this method is expecting the pose without tool , just at the wrist.

    WaypointNodeConfig newWaypointNodeConfig = waypointNodeConfigFactory.createFixedPositionConfig(pose[0], jointPositions[0], blendParameters, motionParameters);

How I found out? Similarly to other entries in this post, I see this method is working fine with TCP = 0, 0, 0, 0, 0, 0.

But with any different TCP is not.

I’ve calculated ‘error’ XYZ distance and it matches to decimals with the TPC XYZ distance from the wrist.
The orientation angles I didn’t check it mathematically, but seem to me to be matching the TCP orientation.

Two ways to see it:

  1. It is a bug: @jbm Then, please UR team, fix it asap :grimacing:
    The createFixedPositionConfig method should use the TPC for calculations.
    Probably adding optional parameters to the method would do. Should include:

    • Manually defined TCP (0, 0, 0, 0, 0, 0 if not passed)
    • Option for ‘currently active TPC’
    • Maybe option for the ones defined in the installation? Not so sure of that

  2. It is intended to be like this, not taking the TPC into consideration: Then, we need to have pose_trans and pose_inv methods in Java asap. Can you help @jbm :grimacing:
    This would allow us (non matrix mathematisian experts in general, at least not me) to add a given TPC to have the rigth pose.
    There’s a post on this too: Pose_trans and pose_inv functions in URCap - #5 by dmartin

Thanks a lot folks!!

8

The issue comes up when the tcp rotation is other than x,y,z,0,0,0. the api generated waypoints do have the tcp offset tho. See Here. This was implemented a year ago and should work. To prevent it from calculating the false inverse kinematics we calculated the rotation manually (rx = -0.58,ry=0,rz=0). After that the bug no longer occurs tho it is not possible to move the robot in the tool space correctly😉