Universal Robots Forum

Getting JointAngles from Waypoints

Hello,

i would like to request the following feature:

Getting JointAngles from Waypoints (not only poses) for CB-Series.

The Waypoints are stored as Jointangles and Pose but the user has only the ability to access the Waypoints as poses.
I would like a function like get_waypoint_joint_positions(Wapoint_1) that returns the “qnear” that is implicitely saved with the Waypoint.

Why is it needed?

Describe which problem this will resolve for the customer. What issues are the customer facing today, that cannot be met by our current products? And how will implementing this feature request make their problem resolved?
Moving to waypoints with movel and moveJ is no problem, but if you want to move to a position in steps. For example move Joint 1 at first until it reaches the correct position, than start joint 2 … You have no ability to get the joint positions of the waypoint.

Thank you.
Best Regards,
Alexander Apostolidis

7 Likes

There is the function “get_inverse_kin” in urscript.

Is there what you hope the other for getting joint angles?

Hello,

thank you for the answer.
I know this function but for a pose there are more possible results in joint-space so this is not a safe solution.
As the system internally knows the correct values there is no need to “guess” or calculate the joint angles.

Regards

If you are moving to a Waypoint with moveJ the compiler adds the qnear info without you seeing it, but it is internally saved:

movej(get_inverse_kin(p[.421822130402, -.176491186898, .624648104564, 1.388170442533, 2.786614753244, .002110296279], qnear=[-0.023263279591695607, -1.2242539564715784, -1.4449499289142054, -2.0169995466815394, 1.5543670654296875, -3.0225823561297815]), a=0.6981317007977318, v=1.0471975511965976)

I would like a function that returns the qnear without calling the MoveJ function, so i can work with the JointAngles.

Hi,

that is exactly what we need for several use cases in our projects, so thumbs up for this feature👍🏻

Agree, this would be a nice feature to have. :+1:

Lack of this feature has caused some anomalies for us in the past, so its a +1 from me

I am sorry I didn’t understand what you said.
I finally understand.

The inverse kinematics has a maximum of 8 solutions.
I also think that the feature to obtain qear is important.

By the way, if the poses are defined as patterns of numbers, I hope the argument of pattern may be able to be added into moveJ as the alternative.

Ex. movej(p[0.2, 0.3, 0.04, 0, 3.14, 0], pattern = 3)

I verified 8 patterns of pose of robot on my CAD as the figure below.

I always would like to select pattern 3 or 6 when I design the machine with UR.

3 Likes

Agree, It would solve some problems, for wich we have to add extra waypiont to avoid.

I have seen commands like this in other brands and works nicely. would be good to have it here.

hey,

As a workaround, you can use your own custom waypoint that mimics the funcktionallity of the Waypoint, and then save the JointPositions from this. We have implemented this, although you can’t use the funktion that request the user to auto/manually move the robot to the first waypoint when start is pressed.

Hi.

It is possible that you decide the direction of first move as alternative.
Please try to use this sample.

It seems that there is a need for some kind of solution.

What do you think of the following solutions:

  • Solution like the e-Series, where it is awailble in the script
  • Added getJointPositions method to the FixedPositionDefinedWaypointNodeConfig interface

0 voters

You are also welcome to make other suggestions!

2 Likes

Hi Ebbe,

why not both?
Actually, we are using e-Series only and having an Interface for getting the JointPositions would be a big thing for us because it is then possible to re-configure MoveJ Waypoint Nodes, e.g. changing the Blend Parameters.

@m.birkholz

That would also be my choice! But it will take some resources, for either of the solutions. So it is nice to gain an impression where the biggest need is.

Hi, @Ebbe

I also expect that.
Thank you.

Good information thanks for sharing
vmware