Re: Minitetra kinematics, following error

[Fred Proctor <frederick.proctor-at-nist.gov>]

Till Franitza wrote about homing a Stewart Platform machine and going
from manual to MDI/auto modes:

> But isnt it practically necessary to go into MDI or Auto mode at any time? The
> solution to achieve this is, i think, that a forward trnsformation is done
> in the moment, the user switches. Then the Platform position that fits to
> the actual cable length is computed and used as the new cartesian position.
> The inverse cinematics result in the actual cable lengths and no following
> error is present. A necessary condition for this should nevertheless be,
> that a homing is done once. In order to assure that the axes really are
> where the emc assumes them to be.
> Dont you think this can be inserted in the code easily?

Yes, you're absolutely right. If you look in emc/src/emcmot/emcmot.c,
you'll see where the call to the forward kinematics happens. You'll also
see that this is if'ed out with the EMCMOT_NO_FORWARD_KINEMATICS, by
default 0 but overridden in the .run script for the minitetra. The
reason this is overridden is that we don't have the forward kinematics
for the Stewart Platform, only the inverses. The forwards aren't closed
form, and we had an iterative solution that was sort of working but not
quite.

Till, do you have forward kinematics for the type of Stewart Platform we
have, that consists of two equilateral triangles with the corners cut
off, as per the 4 parameters in the genhexkins.h file? Our iterative
solution called the inverse kinematics for several iterations to close
in on a stable solution. Brian Register at U Florida did this but we
never got it working completely.

--Fred