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

Configurations missing when using UR robot controller kinematics

#1
When using a UR5 robot model in RoboDK with default DH parameters, I am able to select from other robot configurations using the "More options" button from within the UR5 panel. This shows a large number (16) different configurations.

However, when I use controller kinematics (from a URP file as per instructions), no alternative joint configurations are listed. Is this expected behavior?
#2
Yes, this behavior is expected because the inverse kinematics solution is iterative when you use the controller kinematics.

If you use the nominal model instead, the inverse kinematics solution is analytical and you can obtain all possible configurations.
#3
Is it possible to adjust the parameters used in the iterative solution when using controller kinematics, in the same way that the GUI allows when using nominal kinematics? Students are now encountering issues where move commands that previously worked on the physical robot using the nominal model now complain that positions are unreachable when using controller kinematics. We have also seen several other strange errors, including one that complained that a joint was moving through 180 degrees - again, an error that did not occur on the physical robot when using the nominal model.
#4
When jogging the robot manually within RoboDK, the configuration can jump from one type to another type if a joint is close to the joint limits.

I recommend you to use the nominal model instead to prevent these issues. If you generate your robot movements using Cartesian targets the robot will apply its own kinematics which is very close to the one used by RoboDK for the same robot model.

You may find unique cases which highly depend on one robot and they may not be reproducable in other robots.
#5
Hi Albert.

One of the issues we are facing is target reach errors. That is, movements that work with nominal kinematics do NOT work with UR5 controller kinematics. My work colleague identified a fix, but the cause of what is clearly a bug remains unknown. It might be due to the presence (or absence) of non-printable characters in the HT matrix.

I have attached Python and RDK files that may be used to reproduce the issue.


Attached Files
.py   transformProblems.py (Size: 2.33 KB / Downloads: 7)
.py   tools.py (Size: 25.71 KB / Downloads: 6)
.rdk   Robot_1_2025.rdk (Size: 42.31 MB / Downloads: 6)
  




Users browsing this thread:
1 Guest(s)