# Get\_inverse\_kin "close to qnear"

**URL:** <https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765>\
**Category:** URScript\
**Created:** [July 19, 2019, 8:41am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765 "2019-07-19T08:41:35Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon57454834](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@anon57454834](https://forum.universal-robots.com/u/anon57454834)\
**Post date:** [July 19, 2019, 8:41am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/1 "2019-07-19T08:41:35Z")

</div>

I refer to topic

> [@Get\_inverse\_kin closest solution criteria](https://forum.universal-robots.com/t/get-inverse-kin-closest-solution-criteria/207):
>
> What is the criteria for the closest solution return by get\_inverse\_kin ? Is it the sum of absolute error, the sum of squared error or something else ? Do you plan to add the get\_forward\_kin function in URScript ?

where this question was asked already, but not completely answered:

> In short, it is the sum of squared error. But it is a bit more complicated than that.

I made some tests with an UR10e in a simulation and got that result:

```
=== Compare results for QNear1 and QNear2 ===
Result1 for QNear1: [-108.729756° /-167.715858° /53.28137° /23.502614° /87.616465° /-63.232788°]
Result2 for QNear2: [43.902276° /-87.599227° /83.131068° /-83.608423° /91.688389° /144.144138°]
Pose for Result1: [-399.8mm /-621.7mm /949.8mm /-2.1° /-2° /98°]
Pose for Result2: [-399.8mm /-621.7mm /949.8mm /-2.1° /-2° /98°]
Distance btw. poses: [-0mm /-0mm /-0mm /-0° /-0° /0°]
===both joint lists (Result1 and Result2) are valid results!===
Distance btw. Result1 and QNear1: [0° /-57.715858° /-3.41863° /68.502614° /-2.383535° /0°]
Distance btw. Result2 and QNear1: [0° /22.400773° /26.431068° /-38.608423° /1.688389° /0°]
Shoulder: Result2 is 35.315085° closer
Ellbow: Result1 is 23.012438° closer
Wrist1: Result2 is 29.894191° closer
Wrist2: Result2 is 0.695146° closer
If Result2 is closer to QNear1, why was it not returned to get_inverse_kin( TargetPos, QNear1)?

```

from that script (I omit some functions):

```
def QNearTestShort():
  local TargetPose = p[-0.3998, -0.6217, 0.9498, d2r(-2.1), d2r(-2.0), d2r(98)]
  local QNear1 = [d2r(0), d2r(-110), d2r(56.7), d2r(-45), d2r(90), d2r(0)]
  local QNear2 = [d2r(45), d2r(-110), d2r(56.7), d2r(-45), d2r(90), d2r(0)]

  local Result1 = get_inverse_kin( TargetPose, QNear1 )
  local Result2 = get_inverse_kin( TargetPose, QNear2 )

  local Pose1 = get_forward_kin( Result1 )
  local Pose2 = get_forward_kin( Result2 )

  Debug( "=== Compare results for QNear1 and QNear2 === " )
  Debug( "Result1 for QNear1: " + to_joints_str( Result1 ) )
  Debug( "Result2 for QNear2: " + to_joints_str( Result2 ) )
  Debug( "Pose for Result1: " + to_pose_str( Pose1 ) )
  Debug( "Pose for Result2: " + to_pose_str( Pose2 ) )
  Debug( "Distance btw. poses: " + to_pose_str( SubtractPose(Pose1,Pose2) ) )
  Debug( "===both joint lists (Result1 and Result2) are valid results!===" )

  local Distance1 = SubtractJoint(Result1,QNear1)
  local Distance2 = SubtractJoint(Result2,QNear1)

  # mask the first and last coordinate away (I was told, if QNear[i]==0 this coordinate will not be used)
  Distance1[0] = 0
  Distance2[0] = 0
  Distance1[5] = 0
  Distance2[5] = 0
  # check, if Result1 or Result2 is "nearer" to QNear1:
  Debug( "Distance btw. Result1 and QNear1: " + to_joints_str( Distance1 ) )
  Debug( "Distance btw. Result2 and QNear1: " + to_joints_str( Distance2 ) )
  Judge( "Shoulder: ", Distance1[1], Distance2[1] )
  Judge( "Ellbow: ", Distance1[2], Distance2[2] )
  Judge( "Wrist1: ", Distance1[3], Distance2[3] )
  Judge( "Wrist2: ", Distance1[4], Distance2[4] )
  Debug( "If Result2 is closer to QNear1, why was it not returned to get_inverse_kin( TargetPos, QNear1)?" )
end

```

QNearTestShort()  
halt

After all it seems to me, that QNear in get\_inverse\_kin is only usable in special cases, but not in the general case.  
Can you give me some more explanation about that? Especially how to use it in a general case reliably?

-Ludwig

---

<div class="post-metadata">

**Author:** ![Ebbe](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/ebbe/32/1413_2.png) [@Ebbe](https://forum.universal-robots.com/u/Ebbe)\
**Post date:** [February 24, 2020, 7:57am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/2 "2020-02-24T07:57:34Z")

</div>

Hi Ludvig,

I doubt this functionality:

> [@anon57454834](#):
>
> # mask the first and last coordinate away (I was told, if QNear[i]==0 this coordinate will not be used) Distance1[0] = 0 Distance2[0] = 0 Distance1[5] = 0 Distance2[5] = 0

And I think that is the explanation to your question.

---

<div class="post-metadata">

**Author:** ![anon57454834](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@anon57454834](https://forum.universal-robots.com/u/anon57454834)\
**Post date:** [February 24, 2020, 8:30am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/3 "2020-02-24T08:30:54Z")

</div>

Hello ebof!

Not really. Because after I found out, that this function is not working as they told me, I come back to the original question:

"What is the criteria for the closest solution return by get\_inverse\_kin ? "

How is the result chosen (if there are ambiguities) depending on qnear. Or even more difficult: How do I have to choose my qnear in order to get the desired answers from get\_inverse\_kin?

-Ludwig

---

<div class="post-metadata">

**Author:** ![Ebbe](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/ebbe/32/1413_2.png) [@Ebbe](https://forum.universal-robots.com/u/Ebbe)\
**Post date:** [February 25, 2020, 1:50pm UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/4 "2020-02-25T13:50:06Z")

</div>

As JBM wrote, the LMS is the short explanation to how the solutions is chosen. Do you have an example where you doubt the output?

If you want a short movement time from the robots current position, then I will suggest you to use “get\_actual\_joint\_positions()” as q\_near.

---

<div class="post-metadata">

**Author:** ![anon57454834](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@anon57454834](https://forum.universal-robots.com/u/anon57454834)\
**Post date:** [February 25, 2020, 2:47pm UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/5 "2020-02-25T14:47:00Z")

</div>

I want to be sure to understand, what you mean with LMS. I think, you mean:

The resulting joint\_position j for a pose p and joint positions q:  
j = get\_inverse\_kin( p, q)  
is such that (for e[i] = j[i]-q[i], i=0…5)  
S = e[0]\*e[0] + e[1]\*e[1] + e[2]\*e[2] + e[3]\*e[3] + e[4]\*e[4] + e[5]\*e[5]  
is minimal?

* * *

This is how I have understood the get\_inverse\_kin right from the beginning. I used this function to keep the robot in a certain “arrangement” in the ellbow: (u is the base mounted at the ceiling)

```
   u instead of u_
    \_ \
      ' '

```

But I remember, that I got some solutions, that surprised me.

Sorry, I cannot deliver any examples at the moment, since my project is finished (for now) and I have no time or occasion to work on the robot (for now).

---

<div class="post-metadata">

**Author:** ![Ebbe](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/ebbe/32/1413_2.png) [@Ebbe](https://forum.universal-robots.com/u/Ebbe)\
**Post date:** [February 26, 2020, 10:35am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/6 "2020-02-26T10:35:52Z")

</div>

Yes exactly. Let me know next time you get into troubles!

---

<div class="post-metadata">

**Author:** ![anon77491662](https://avatars.discourse-cdn.com/v4/letter/a/f05b48/32.png) [@anon77491662](https://forum.universal-robots.com/u/anon77491662)\
**Post date:** [July 31, 2020, 12:54pm UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/7 "2020-07-31T12:54:00Z")

</div>

Hello,  
I’m not 100% sure that my issue is related to this topic, but it seems like it to me.

I’m currently struggling to understand how get\_inverse\_kin and qnear work.  
in a script I’ve got this:  
textmsg("Drop\_Pre\_Pt1: ",Drop\_Pre\_Pt1)   
Drop\_Pre\_Pt1J=get\_inverse\_kin(pose\_trans(Uframe,Drop\_Pre\_Pt1))  
textmsg("Drop\_Pre\_Pt1J[0]: ",r2d(Drop\_Pre\_Pt1J[0]))  
textmsg("Drop\_Pre\_Pt1J[1]: ",r2d(Drop\_Pre\_Pt1J[1]))  
textmsg("Drop\_Pre\_Pt1J[2]: ",r2d(Drop\_Pre\_Pt1J[2]))  
textmsg("Drop\_Pre\_Pt1J[3]: ",r2d(Drop\_Pre\_Pt1J[3]))  
textmsg("Drop\_Pre\_Pt1J[4]: ",r2d(Drop\_Pre\_Pt1J[4]))  
textmsg("Drop\_Pre\_Pt1J[5]: ",r2d(Drop\_Pre\_Pt1J[5]))  
textmsg("Drop\_Pre\_Pt1J: ",Drop\_Pre\_Pt1J)  
Drop\_Pre\_Pt1J=get\_inverse\_kin(pose\_trans(Uframe,Drop\_Pre\_Pt1),[d2r(-100),d2r(-80),d2r(-120),d2r(-70),d2r(90),d2r(-90)])  
textmsg("Drop\_Pre\_Pt1J[0]: ",r2d(Drop\_Pre\_Pt1J[0]))  
textmsg("Drop\_Pre\_Pt1J[1]: ",r2d(Drop\_Pre\_Pt1J[1]))  
textmsg("Drop\_Pre\_Pt1J[2]: ",r2d(Drop\_Pre\_Pt1J[2]))  
textmsg("Drop\_Pre\_Pt1J[3]: ",r2d(Drop\_Pre\_Pt1J[3]))  
textmsg("Drop\_Pre\_Pt1J[4]: ",r2d(Drop\_Pre\_Pt1J[4]))  
textmsg("Drop\_Pre\_Pt1J[5]: ",r2d(Drop\_Pre\_Pt1J[5]))  
textmsg("Drop\_Pre\_Pt1J: ",Drop\_Pre\_Pt1J)

Drop\_Pre\_Pt1 is calculated and relative to Uframe.  
I log inverse kinematic because time to time I’ve got some “weird” axes configuration, which led to collision.

On the last collision the log return this:  
Drop\_Pre\_Pt1: p[0.308678,0.0377616,0.3,2.16857,2.273,-9.39359e-05]

#get\_inverse\_kin solution with **no** qnear parameter  
Drop\_Pre\_Pt1J[0]: 25.3461  
Drop\_Pre\_Pt1J[1]: 13.3889  
Drop\_Pre\_Pt1J[2]: -99.7442  
Drop\_Pre\_Pt1J[3]: -184.133  
Drop\_Pre\_Pt1J[4]: 90.5411  
Drop\_Pre\_Pt1J[5]: 23.6616  
Drop\_Pre\_Pt1J: [0.442372,0.233681,-1.74087,-3.21372,1.58024,0.412974]

#get\_inverse\_kin solution with qnear parameter  
Drop\_Pre\_Pt1J[0]: 25.3461  
Drop\_Pre\_Pt1J[1]: 13.3889  
Drop\_Pre\_Pt1J[2]: -99.7442  
Drop\_Pre\_Pt1J[3]: -184.133  
Drop\_Pre\_Pt1J[4]: 90.5411  
Drop\_Pre\_Pt1J[5]: 23.6616  
Drop\_Pre\_Pt1J: [0.442372,0.233681,-1.74087,-3.21372,1.58024,0.412974]

How come get\_inverse\_kin with qnear gives such results?  
Drop\_Pre\_Pt1J[0]: **25.3461** qnear[0]=d2r( **-100** ) -\> more than 90° difference  
Drop\_Pre\_Pt1J[1]: **13.3889** qnear[1]=d2r( **-80** ) -\> more than 90° difference  
Drop\_Pre\_Pt1J[2]: **-99.7442** qnear[2]=d2r( **-120** ) -\> acceptable  
Drop\_Pre\_Pt1J[3]: **-184.133** qnear[3]=d2r( **-70** ) -\> more than 90° difference  
Drop\_Pre\_Pt1J[4]: **90.5411** qnear[4]=d2r( **90** ) -\> fine  
Drop\_Pre\_Pt1J[5]: **23.6616** qnear[5]d2r( **-90** ) -\> more than 90° difference

Especially when a solution exist with the following axes angle really close to qnear.  
Drop\_Pre\_Pt1J[0]: -117.25  
Drop\_Pre\_Pt1J[1]: -75.15  
Drop\_Pre\_Pt1J[2]: -121.52  
Drop\_Pre\_Pt1J[3]: -73.19  
Drop\_Pre\_Pt1J[4]: 89.15  
Drop\_Pre\_Pt1J[5]: -119.1

Something doesn’t seem to work properly or I’m miss something?

---

<div class="post-metadata">

**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\
**Post date:** [August 2, 2020, 9:35pm UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/8 "2020-08-02T21:35:50Z")

</div>

I’m not a 100% sure, but I’m guessing it has something to do with singularities. The UR has 3: tool flange close to the base, arm fully stretched out and wrist joint 2 being close to 0 or 180 degrees. You are either to close to these singularities or the qnear forces the robot to move through one of them (although I’m not sure the robot controller is _that_ intelligent… 🙂 )

It would explain why Joint 0 & 5 are not considered (they do not impact singularities)

---

<div class="post-metadata">

**Author:** ![anon53720910](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@anon53720910](https://forum.universal-robots.com/u/anon53720910)\
**Post date:** [August 3, 2020, 7:40am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/9 "2020-08-03T07:40:26Z")

</div>

I have a related question, I’d like to “predict” what joints the robot will assume after a movel call. For this purpose I call get\_inverse\_kinematics() for the target cartesian position (with qnear as the current joint angles). Usually the predicted and the assumed joint angles are the same, but in some cases they differ. Is there a way to consistently predict the outcome of a movel (Given that it is a valid, reachable position)?

---

<div class="post-metadata">

**Author:** ![anon77491662](https://avatars.discourse-cdn.com/v4/letter/a/f05b48/32.png) [@anon77491662](https://forum.universal-robots.com/u/anon77491662)\
**Post date:** [August 3, 2020, 7:43am UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/10 "2020-08-03T07:43:58Z")

</div>

Hello,  
I don’t think singularity is the problem.  
Tool flange is fairly away from the base at least 350mm, the arm is not stretched at all and wrist joint 2 is around 90°.  
All points are reachable it’s just that 5% of the time the axes configurations change from one point to another which lead to collision.  
And I was surprise that get\_inverse\_kinematics associated with qnear parameter close to the desire axes configuration would give me a result that different from qnear.

---

<div class="post-metadata">

**Author:** ![mvrooij](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/mvrooij/32/2151_2.png) [@mvrooij](https://forum.universal-robots.com/u/mvrooij)\
**Post date:** [August 15, 2020, 7:19pm UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/11 "2020-08-15T19:19:36Z")

</div>

Yes, no direct singularity, but may it has to pass through one in order to get to the desired poont. This passing through may not be physically, but by means of the internal workings of the solver. I don’t know what they use, but the effects are typical for a Jacobian based ik solver…

---

<div class="post-metadata">

**Author:** ![Ebbe](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.universal-robots.com/ebbe/32/1413_2.png) [@Ebbe](https://forum.universal-robots.com/u/Ebbe)\
**Post date:** [August 18, 2020, 3:01pm UTC](https://forum.universal-robots.com/t/get-inverse-kin-close-to-qnear/4765/12 "2020-08-18T15:01:35Z")

</div>

Both script snippets that are shared here is affected by the issue described here:

> [@Get\_inverse\_kin - qnear is not always updated](https://forum.universal-robots.com/t/get-inverse-kin-qnear-is-not-always-updated/8396):
>
> Summary get\_inverse\_kin() is not always updating the qnear if it is called several time with the same x (Tool pose) Versions Affected Robot Software Version(s): 5.8.2 Affected Robot Hardware Version(s): Simulator Robot Serial Number: Simulator UR+ product(s) installed:- URCaps Software version(s): - Impact The returned joint angles will, in some cases, be different than expected Issue details The issue was found during looking into the functionality of qnear. The investigations is made on th…

Please apply the workaround and give us the feedback if you are still having issues!