Quote"The best thing I can think of would be to allow the axis movement component to contain empty information, that is then filled from the previous movement. So if you don't set A1-A5 it takes it from the previous motion.
Of course ! But doesn't that imply to run inverse kinematics, just to retrieve the A1-A5 from the previous movement ?
That's the whole problem.
If I could "convert" my LIN movements in corresponding axis values, I wouldn'tt be afraid to use that data to spot the places where my A4 and A6 play the reverse merry-go-round and automatically insert the proper AXIS movement to correct it.
In the attached case, KUKA's kinematic math falls in Euler's rotation trap and deals with the singularity in the most stupid way.
I won't wait for KUKA to figure out the existence of quaternions, but I sure can prevent this from happening if I can see it coming.
Would I be possible to have two KUKA|prc components in my definition : the second one using the analysis data of the first to add corrective and/or smarter commands ?
Only the second one would be used for generating the .src file, and no Grasshopper time travel would be required...