4
$\begingroup$

The issue is regarding simulation of Kuka robot KR16L6-2 in MATLAB using Robotics toolkit by Peter Corke. I wish to simulate the kinematic before passing a command to real robot for motion.

I have attached the DH-Parameters. Apart from this I have also tried many other combination of orientations but to no useful effect.

DH parameters and code

The problems is that the robot base rotates counter-clockwise by default for positive increases in Joint1, while the original robot moves in the opposite direction. Similarly for the wrist roll, i.e. Joint 4, the direction of simulation is reversed.

In order to confirm that it's not my mistake only, I searched for similar ready made simulation software. Although it did not include the same KUKA robot, a similar variant (KUKA_KR_5_sixx_R650) was available. Hence, KUKA_KR_5_sixx_R650 had one set of motions for base and wrist in RoKiSim v1.7 for positive increases in joint angle and reverse motion in roboanalyzerv7 .

Screenshots of Robot Simulation of KUKA_KR_5_sixx_R650

NOTE: Only the rotation of J1 (base) and J4 (Wrist Roll) are reversed and I want to recreate the results of RoKiSim v1.7 in Matlab where rotations are similar to the real world robot spec provided by KUKA.

Improve this question
$\endgroup$
1
  • $\begingroup$ If you get your coordinate axes to agree with those printed on the robot, as 50k4 suggested, and this causes the motion to work correctly but your inverse kinematics to be wrong, then I'd say there's something wrong with your inverse kinematics. Can you post that code? $\endgroup$ – Chuck May 23 '16 at 17:48
2
$\begingroup$

Kuka robots have the axis positive and negative side clearly marked on them. Use these to define the orientations of the Z-axes assigned to the joints. With other words, try to reverse engineer the DH parameters used by Kuka. Only this way can you corelate your DH table with the kuka axis orientations. If the axis moves in the wrong direction it means that your coordonate system is upside down. Flip it and change the sign of the other parameters.

Also keep in mind that there are multiple variants of teh DH parametrization (proximal and distal or modified DH). It can be that kuka uses a different one then the Robotics toolbox.

Other simulation software is not necesarily corelated with the real robot.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Yes I have tried doing that, Motion coincides with the original but then the inverse kinematics is not correct. Thanks anyway :) $\endgroup$ – ihti Apr 26 '16 at 16:37
1
$\begingroup$

This is a limitation of DH notation. Axis rotation follows the right-convention about the z-axis. For the first joint you are stuck with rotation about the world z-axis, hence your problem.

For the Robotics Toolbox joint rotation all follow the right-hand convention. You could multiply your joint angle vector by a vector of rotation directions

dir = [-1 1 1 -1 1 1];

kuka.fkine(q .* dir)
Improve this answer
$\endgroup$
0
$\begingroup$

I'd recommend putting a layer between your internal DH-model and the manufacturers axis conventions. (The differ for different manufacturers, so your IK will not be reusable otherwise. Zero positions varies as well.) KUKA likely does something similar given that you find stuff like this in $machine.dat:

$AXIS_DIR[1]=-1 $AXIS_DIR[2]=1 $AXIS_DIR[3]=1 $AXIS_DIR[4]=-1 $AXIS_DIR[5]=-1 $AXIS_DIR[6]=-1

Regarding the "reverse engineering" mentioned in the other answer: The file mentioned above contains lots of kinematic parameters as well.

Edit: Just noticed the post date. Why did this show up in my sidebar?

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.