On Sat, Nov 22, 2008 at 9:37 AM, Stephen Wille Padnos <[EMAIL PROTECTED]> wrote: > Stuart Stevenson wrote: > >>Gentlemen, >> I have been thinking. :) >> >> 1: Since the forward and inverse calculations must match is there >>any reason to calculate both for all modes of operation? Depending on >>the mode shouldn't you be able to skip the unneeded calculation? This >>would allow twice the calculation time and not lose any speed. A mode >>change could change the calculation path through the kins. >> >> > A mode change of what type?
a mode change from MDI to manual or manual to MDI causes a jump if the forward and inverse kins do not agree. that implies to me the calculations are done on both at the same time and the result of both are used by EMC if MDI uses one (ex. forward) and manual uses the other (ex. inverse) then the starting point of the forward kins is the result of the inverse kins removing the need to calculate the inverse kins for that mode. Then on a mode change from MDI to manual the inverse kins would be calculated and the forward would not need to be calculated as the values feed to the inverse function are what is need to satisfy the forward kins > >> or >> >> 2: A matrix stack would allow both calculations at the same time. >>The kins would calculate a matrix for the forward kins and do an >>inverse calculation of the resulting matrix for the inverse kins (or >>vice versa). The kins would not have to recalculate the whole stack >>for both forward kins and inverse kins. >> >> > Each time the servo thread runs, EMC needs to do both sets of > calculations once, but it does the calculations on different poses. > > First, feedback is fed through the kinematics function to tell EMC where > the machine is. EMC can then do following error checks, and can create > a new pose to send out as the next position command. Since that pose is > in cartesian coordinates, but it needs to be sent to the actual machine > joints, that has to be run through inverse kinematics to make a valid > machine pose. > > A matrix solution would be good, but since the transforms are done on > different poses each cycle, they can't be done at the same time. > looking at the matrices needed I see that the tool length and tool tip and tool orientation are the only changes during the operation of the machine. the rest of the machine description could be static (not need to be recalculated for every kins pass? > Note 1: I may have screwed up which is "kinematics" and which is > "inverse kinematics". if so, please swap where appropriate :) > Note 2: I didn't look at the code before writing this, nor did I have > any coffee. YMMV. > at this point it is not possible to screw up as no motion is being done and no chips are being made :) > - Steve > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > > thanks Stuart ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
