Universal Robots Forum

[SOLVED] Problem with saving JointPositions when using getUserDefinedRobotPosition

EDIT: I should have used getPositions, not getAngle…

Software version: …
Robot generation: …
CB3.1 UR10 and Simulator

Steps to reproduce:

  1. First step

     private JointPositions jointPositionsToSave = null;
     private void requestPosition() {
     	getUserDefinedRobotPosition(new RobotPositionCallback() {
     		public void onOk(Pose pose, JointPositions q) {
     			jointPositionsToSave = q;
     			JointPosition[] temp = q.getAllJointPositions() ; //(Length.Unit.M, Angle.Unit.RAD);
     			double[] joints = {0,0,0,0,0,0};
     			joints[0]= temp[0].getAngle(Angle.Unit.RAD);
     			joints[1]= temp[1].getAngle(Angle.Unit.RAD);
     			joints[2]= temp[2].getAngle(Angle.Unit.RAD);
     			joints[3]= temp[3].getAngle(Angle.Unit.RAD);
     			joints[4]= temp[4].getAngle(Angle.Unit.RAD);
     			joints[5]= temp[5].getAngle(Angle.Unit.RAD);
     			System.out.println("Pose: " + currentPose.toString() + "\t\t Joints: " + 
     		public void onCancel() {
     private void autoMoveJRobotTo(JointPositions jointPositions) {
     	robotMovement.requestUserToMoveRobot(jointPositions, new RobotMovementCallback() {
     		public void onComplete(MovementCompleteEvent event) {
     			System.out.println("Automove complete!");
     		public void onError(MovementErrorEvent error) {
     			JOptionPane.showMessageDialog(null, "An error occured while moving the robot. Check the log.", 
     				"Error on Movement", JOptionPane.ERROR_MESSAGE);
     		public void onCancel(MovementCancelEvent cancel) {
     			System.out.println("Automove cancelled.");
  2. Second step…
    Add this in a URCap Installation and call first the requestPosition() and read the output of the print, then if you want to make it more clear, once that is done, call autoMoveJRobotTo(jointPositionsToSave)

In my example I set it to:
p[0.100,0.150,0.200, 0 ,3.14159256, 0] which is around 95°, -50°, -131°, -89°, 90°, 185°.

Expected behavior:

Should print out exactly the joint positions shown on screen when Operator press OK and getUserDefinedRobotPosition runs onOk.
In my example, it should be:

Pose: p[0.09999999199817852,0.14999999752877413,0.2000000221683304,8.173535719548361E-7,3.1415926277801023,-3.2333374544107616E-7]
Joints: [1.6556288003921509,-0.8674853483783167,-2.2916136423694056,-1.5532901922809046,1.5707963705062866,3.2264256477355957]

Should also not move when calling the requestUserToMoveRobot if operator hasn’t moved it, it should just give the popup that the Robot is already in that position.

Actual behavior:

This is what I set it to:

It then prints out:

Pose: p[0.1000000079147788,0.1499999988822671,0.20000002216833065,8.173535357949963E-7,3.1415925617327454,-3.074675579535917E-7]
Joints: [1.6556288176745633,5.415699900933667,3.9915716089427438,4.729895148111645,1.5707962903693784,3.226425590288836]

p[0.100,0.150,0.200, 0 ,3.14159256, 0] and around 95°, 310°, 229°, 271°, 90°, 185°.

So the Auto movement would need to twist the robot in an unrealistic way:

And here is the Move Joints interface, it wants to move from:


Same pose, completely different joint positions. My assumption is that the function only saves the pose and then makes an inverse kinematics calculations (Even though it should just record the values straight?)
Ofc a workaround for anyone with the same problem is to get the joint positions from the socket interfaces, as we had been doing til now.

1 Like

“My assumption is that the function only saves the pose and then makes an inverse kinematics calculations (Even though it should just record the values straight?”

i totally agree!

I’m having a related problem (only for API generated Waypoints) for more than a year which occurs depending on the TCP Setting where the Robot tries to reach the desired Pose with a different kinematic setting as it always has 2 kinematic solutions (axis 2-4)

Do you also have this issue with TCP p[x,y,z,0,0,0] ?

@sko maybe this points to the same problem as we talked about? :wink:

I haven’t noticed the same problem with TCP, but we only use the getUserDefinedRobotPosition at one place for one specific TCP, so maybe if you use it for more purposes it might get wrong…
Also, the inverse kinematics can get quite screwed up if you dont use qnear, but instead current TCP pose for example :wink:

Looking at it a bit more, it seems like getUserDefinedRobotPosition converts all the negative values to positive values, like it uses qnear=[3.141592,3.141592,3.141592,3.141592,3.141592,3.141592] instead of currentJointValues, or a compromise would be to use [0,0,0,0,0,0] if currentJointValues are unavailable for some strange reason…

Quick update: On further testing, it seems like the problem might be in the
getAllJointPositions() or getAngle() that causes the issue.
I’ll test further.

Also, I just thought maybe one of those functions are not made to work as I thought they should, and ofc that is the case:

getAngle(Angle.Unit)- Method in interface com.ur.urcap.api.domain.value.jointposition.JointPosition
Provides the angle offset in the range [0:2pi[ (RAD) or [0:360[ (DEG)

I haven’t seen the getPosition before, but with that worked like clockwork. Sorry, my mistake!