scarakins flip motion

playing with a scara type motion but the kins force the arm to rotate the axis_0 180deg on the crossing of the X 0 line(or Y 0). normally not a problem because your arm would hit something before this happened. so i know i need to edit the scarakins.c file then recompile, but im not sure how to change the math to let the axis_1 continue to rotate in sync with the axis_0. i have attached a pic of the arm


And a diagram of the motion



but not sure what i need to edit in the scarakins file to make that happen

I guess you are passing through a singularity.

It probably comes down to an inverse trigonometric function that chooses one root rather than the other.

Perhaps the scarakins code needs to reject solutions that result in a large deviation from the current position.

github.com/LinuxCNC/linuxcnc/blob/master...ics/scarakins.c#L153

It's probably something like

I had to deal with singularity on a KUKA KR150, it turned out that is quite normal for things with a lot of axis at times when the same move can be made by more than 1 axis.

if (abs(q0 - joint[0]) > 90){
q0 - atan2(-yt, xt);}

so been playing around with that, nothing promising yet. looks like it is only a problem when an axis is close to zero and the speed makes the affected radius larger. A workaround maybe to slow the feed as it gets close to X 0 or Y 0. Don't really like this idea. think it is a problem with quadrant math, still hard to get my head around.

Deckerjwd wrote:

if (abs(q0 - joint[0]) > 90){
q0 - atan2(-yt, xt);}

so been playing around with that, nothing promising yet.

Possibly because the units of q0 are radians at that point, but joint[0] is degrees.

You do realise that you need to recompile the kins after each change?

o well that makes the weird movement make sense

Jon

so joint[0] now moves correctly, but looks like i need to switch directions on joint[1], code changes so far are as follows line 117
and originally line 154

ok starting to think the if statement is in the wrong place or maybe the condition is incorrect.
think something like if moving to negative from positive then invert rotation. try moving the if statement but i get some feedback (cool patterns) and loose control of the arm. going to keep at it any feed back is welcome

You could try looking at the encoder feedback and moving the robot by hand, and pretend you are running the code, see how it works out?