Viesturs, Just in case, and without trying to dig deep into the problem:
Euler angles can be singular at certain positions. That is they are unable to give a rotation or base change matrix when at such positions. If you experience estrange problems only when the angles are close to 0 or to 90 degrees it is possible that our problem is related to this. Also -just in case- from my, almost forgotten, course on robotics: serial manipulator use to have trivial direct models; but inverse kinematics can be much less trivial (at least in explicit form), and frequently can have more than one solution or none at all (for example if you are out of the work space). This can be problematic too. Hope this helps, Javier On Sun, May 22, 2011 at 10:19 PM, Viesturs Lācis <viesturs.la...@gmail.com>wrote: > 2011/5/22 Viesturs Lācis <viesturs.la...@gmail.com>: > > > > Now I will try to get it little more sophisticated. > > I have spent 6 or 7 months trying to get kinematics for a puma-style > robot arm that moves on a linear joint. Here is what I tried so far > and what are the results: > > 1) genserkins does not work properly - alligning coordinate frame of > the arm with base frame is impossible. Z is correct, but X and Y are > turned by 90 degrees - X points , where Y should be. All the > coordinate frames of joints seem to be alligned properly - running the > sample g-code produced a nice drawing of EMC 2.4/ AXIS > I have been drawing sketches on paper over and over again to find out, > where do I have a mistake and what values _should_ DH parameters have > to describe the arm and all the time get the same existing result. > > 2) adjusting pumakins also failed - substituting value of "original > joint[0]" with 90 degrees in forward kins and expanding and adjusting > world->tran = worldPose.tran > to be > world->tran.x = joint[0]; > world->tran.y = worldPose.tran.y; > world->tran.z = worldPose.tran.z; > > and in inverse kins > joint[0] = world->tran.x > also does not work > > But I do not see a way to understand those definitions of elements of > rotation matrix; > > 3) writing kinematics from scratch also failed, > I tried the "simple" way with use of trigonometric functions, where > every promising solution, which shows correct calculations in both > directions, somehow ends up with finding a situation, where they fail > without me being able to understand why; > > 4) the "smart" way with Euler's angles seems to be bad concept as a whole: > the idea was like this: > a) technically those should be Xyx angles, but Zyz should do the same, > if there are adjustments after they are converted to rpy: > rpy.r = world->c, not world->a, > rpy.p = world->b and rpy.y = A, not C > rpy.y = world->a, not world->c > > b) Euler's angles were assigned like this: > zyz.z is a slope of lower arm = joint[1] + joint[2] > zyz.y is angle of joint[3] > zyz.zp is angle of joint[4] > > c) in inverse kins: > joint[3] = zyz.y > joint[4] = zyz.zp > zyz.z is not used > > It turned out that it does not work, arm just flips over, when > reaching outwards. The tilt angle of tool also seem not to be > maintained as the slope of lower arm changes, so something is missing > there. > I have a feeling that it might be connected with the fact that zyz.z > value is not used in inverse kins, but I do not see a way to use it. > At least not in this concept, where slope of the lower arm cannot be > adjusted. I thought that some kind of "recalculation" might work, > where initial Zyz values after conversion are stored and then > recalculated for a given zyz.z value (slope of the lower arm) to match > the same tool orientation. > > I have 3 questions: > 1) How can I find out, if EMC just hates me? > 2) Is there any more options I haven't tried to define kinematics for > a puma arm that moves along linear joint? > 3) Are there any suggestions, where to look for solution in any of > above-mentioned approaches? > > Viesturs > > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
