# Movej runs into joint limit

**URL:** <https://forum.universal-robots.com/t/movej-runs-into-joint-limit/2095>\
**Category:** URScript\
**Created:** [June 11, 2018, 1:33pm UTC](https://forum.universal-robots.com/t/movej-runs-into-joint-limit/2095 "2018-06-11T13:33:10Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon30144596](https://avatars.discourse-cdn.com/v4/letter/a/e274bd/32.png) [@anon30144596](https://forum.universal-robots.com/u/anon30144596)\
**Post date:** [June 11, 2018, 1:33pm UTC](https://forum.universal-robots.com/t/movej-runs-into-joint-limit/2095/1 "2018-06-11T13:33:11Z")

</div>

Hi,

For technical reasons I have limited joint range on axis 6 to ±270deg.  
The robot is send to destination pose locations sent via a script from a host system. Now I have the problem that the robot controller chooses a solution for axis 6 which is outside (in my case it is apparently sent to -290deg) instead of +60 deg when axis 6 is positioned at -180deg.  
IMHO the trajectory generator should find a solution that lies within a valid joint range.  
I’d appreciate if someone could shed some light into this.

---

<div class="post-metadata">

**Author:** ![anon42905246](https://avatars.discourse-cdn.com/v4/letter/a/e9a140/32.png) [@anon42905246](https://forum.universal-robots.com/u/anon42905246)\
**Post date:** [June 12, 2018, 4:38am UTC](https://forum.universal-robots.com/t/movej-runs-into-joint-limit/2095/2 "2018-06-12T04:38:10Z")

</div>

Well, you need to take care of that yourself. You can hint the inverse kinematic solver where it should look for solution with `qnear` parameter.

```
get_inverse_kin(x, qnear, maxPositionError=1e-10,
maxOrientationError=1e-10)

```

Inverse kinematics  
Inverse kinematic transformation (tool space -\> joint space). If `qnear` is  
defined, the solution closest to `qnear` is returned. Otherwise, the  
solution closest to the current joint positions is returned.

Parameters  
`x`: tool pose  
`qnear`: list of joint positions (Optional)  
`maxPositionError`: the maximum allowed position  
error (Optional)  
`maxOrientationError`: the maximum allowed orientation  
error (Optional)

---

<div class="post-metadata">

**Author:** ![anon75015020](https://avatars.discourse-cdn.com/v4/letter/a/ebca7d/32.png) [@anon75015020](https://forum.universal-robots.com/u/anon75015020)\
**Post date:** [June 12, 2018, 5:45am UTC](https://forum.universal-robots.com/t/movej-runs-into-joint-limit/2095/3 "2018-06-12T05:45:45Z")

</div>

Look at this topic:

> [@Determined turning direction when moving TCP around 180°](https://forum.universal-robots.com/t/determined-turning-direction-when-moving-tcp-around-180/2071/8):
>
> I did a short test to show the difference between Pose and Joint Positions: Pics attached Calculation of values [poseJointPos] Values [poseJointPos2] Regards, Alexander

regards,  
Alexander

---

<div class="post-metadata">

**Author:** ![anon30144596](https://avatars.discourse-cdn.com/v4/letter/a/e274bd/32.png) [@anon30144596](https://forum.universal-robots.com/u/anon30144596)\
**Post date:** [June 15, 2018, 9:52am UTC](https://forum.universal-robots.com/t/movej-runs-into-joint-limit/2095/4 "2018-06-15T09:52:50Z")

</div>

Hi

thanks for the tip. The thing with qnear ist that if a given value in qnear is anywhere close to a joint limit it may happen that get\_inverse\_kin() returns a position which is outside the valid joint range… is it just me who believes this behaviour is not … well… ideal …? Other robot systems have a similar function but with different behaviour, e.g. the inverse kinematic solver returns a fault if no valid solution could be found or would lie outside a joint limit.  
So no matter what, after a call to get\_inverse\_kin I have to cross check the obtained position with the actual joint limits (unfortunately, those need to be hard coded since reading out joint limits via script is not possible, right?) and correct them by a ±360deg addition in case the solution is outside joint range.