2011/1/5 andy pugh <bodge...@gmail.com>: > > Adding a single translational joint that is parallel to an axis is > very simple. Generalising Serialkins to allow prismatic joints in any > orientation is significantly less so.
Yes, generalising something makes everything pretty difficult, because it has to be able to deal _all_ the potential cases, not just the one case of particular machine. That is why I remember one pretty nice phrase: One can program such an application that even idiot can use it, but then only idiot will want to use it. > Currently I think that serialkins uses Denavit Hartenberg parameters > to solve the kinematics. The d, r and <alpha> values of each joint are > fixed parameters, and the <theta> value is a pin corresponding to > joint position. Yes, that is how I understand it, too. With one exception. In genserkins.c: 79 genser->links[t].u.dh.theta = 0; Please correct me here, but it looks to me that theta is 0 and this is the only line in whole file, where theta is mentioned. So I have to admit that I do not yet understand, how exactly it all works. I feel like theta _should_ be the actual joint position, but I have no idea, where to find out, if it is true or not. > Generalising to prismatic joints might be as simple as making the d > parameter into a pin, and then choosing whether to link the <theta> or > d pin to the joint position in HAL. However, I suspect it might be a > lot more difficult than this. I have no idea, if it can work this way. If I understand correctly, that means changing D value dynamically as robot arm moves. > For your purposes you can probably just add the joint position to the > X value, and subtract in the inverse kins. Yes, I have been thinking about it. But there is one "small" problem: I am used to play with kinematics, where pos->tran.x is somehow related to joint.0 and vice versa. For example, from the 5 axis module I wrote by myself: pos->tran.x = joints[0] - (200 * sin(joints[5])); It compensates for the head offset, when rotary joint.5 is moved. Now in genserkins I do not see this type of equations. I do not see joints[0] to be mentioned at all. The same for joints[1] and others. It is just damn too difficult for me to understand the whole thing yet. Take a look at genserkins.c from line 100 to line 300 :)) http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/kinematics/genserkins.c;h=87d0eb9008a8aedef54110b776d2ed172a73ba1f;hb=v2.4_branch#l100 I think that the simpliest thing that would work, would be something like this: 1) do not give X commands to robot-arm-maths, so that it moves the arm (calculates joint positions) just for Y, Z, A, B and C commands; 2) calculate the drift - how much the tip of torch (or just the 6th "dummy" joint) has moved along X as a result of all the moves along Y, Z, A, B and C; 3) write something like this: world->tran.x = joints[0] + drift joints[0] = world->tran.x - drift My initial idea was to do it this way: 1) in the code, use U instead of X 2) joints[0] = world->u - drift world->u = joints[0] + drift The problem is that I have no idea, how to acquire the value of drift, because in the kinematics module it uses rotary joint to move along X axis and, since there are no straight equations of joints[n] vs world->tran.n, I do not see, how to acquire the value of joints[0] and thus I do not see a way to get the value of drift in linear units. Viesturs ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
