Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

UR5 pose - weird behavior

#1
With the UR5 model, if I set the joint angles to [0, -90, -90, -90, 90, 0], the orientation of the Robot Flange/Tool Frame with respect to the Reference Frame (set as UR5 base) is shown as [0,0,0] (the full pose is shown as [486.080, -109.000, 432.200, 0, 0, 0]), in the "Tool Frame with respect to Reference Frame" panel.

However, the orientation of the Flange/Tool frame is clearly not aligned with the UR5 base frame, as indicated by the [0,0,0] orientation. This can be seen graphically, where the z-axis of the Flange/Tool frame is now pointing in the negative z-direction of the UR5 base frame. From this pose, if I then try to change the position coords by a tiny amount (e.g. x from 486.080 to 486.081), the robot configuration changes drastically and the Flange/Tool frame ends up aligned with the UR5 base frame.

If I copy the pose and paste it as text, the rotation part of the homogeneous matrix is not the identity, but the pose that would be expected. Therefore, I am not sure is this may be a problem with the solution, or just the conversion to angle-axis orientation. I have checked the pose for these joint angles using both URSim and the Matlab Robotics toolbox and the orientation from both these sources for these joint angles is [127.28, -127.28, 0], rather than [0,0,0]. This is also indicated by changing the values of joint 3 by small amounts (+/- 1-deg) and the orientation values are close to the expected.

The robot is not in a kinematic singularity in this pose - the Jacobian is full rank.

I have also tested this with the UR10 model and with a defined tool frame (aligned with robot flange frame), and encounter the same problems.

Could someone please advise whether this is a bug, or if I am just being a muppet and there is an obvious reason for this behavior.

Thanks for your help
#2
This is definitely a bug. Thank you for noticing! This bug is now fixed it and it should work well with thelatest version. See image attached the correct result (which is the result you mentioned).

I'll move this thread to the RoboDK bugs section.





Users browsing this thread:
1 Guest(s)