Trying to use Axis move...

Started by Xylotica, April 17, 2016, 10:15:43 PM

Previous topic - Next topic

Xylotica

...but I haven't found any sample file.
My guess is that it works only with absolute values for axis angles, which makes it not useable if you want to make a relative axis move, right ?
I remember that you suggested to use this to "unwind" and axis, but I can't see how this can work...

Cheers,

Johannes @ Robots in Architecture

Hello,

The component that you are showing in the screenshot is not an axis move component, but it extracts geometric or axis data from a KUKA|prc movement. It will only output an axis values for axis movements.

Axis move is just a fundamental movement type, where you define the position with the axis values, which has got the advantage that it's uniquely defined. Personally I do not really see the need for relative movements when you are working within a CAD environment as you can have absolute values anyway. They are extremely helpful when you are writing code manually, though.
In any case, if you want to unwind the robot, you can either use axis values, or alternatively PTP movements with status and turn defined.

Best,
Johannes

Xylotica

Hi Johannes,

Thanks for your answer.
Wrong attachment indeed, sorry, but I had the right component in mind.
In the example with the milling of a human face, I had the wrist getting wound 1 turn each time it went back and forth.
Wouldn't it be useful, while the tool is making an offset to reach the next pass, to just "unwind" the axis 6 by rotating it the other way ?

Instead, what you are suggesting is to place all the axii in a known position.
But :
-Does this guarantee that while reaching that position, he will not hit an angular limit ?
-Why should I force all the axii to move and make the robot take a specific posture when all I want is to unwind a specific axis ?

I still can't see how this axis move can be used elegantly...
I wish it was possible to set just one axis value (with a choice between absolute and relative), while leaving the others unchanged.

Cheers,

Johannes @ Robots in Architecture

Hello,

If you had the wrist turning you probably went close to a singularity. You can try to place your workpiece differently, so that the axes of the robot don't "overlap", avoiding the problem from the start.
Turning just one axis won't solve your problem, as - unless you turn by exactly 360 degree - you will have to adjust your other axis anyway.
Let's say you are close to the limit at -175 degrees and turn by 360 - now you are at +185, i.e. exactly at the axis limit of the robot at A4.
I would really recommend using PTP with Status and Turn for these things - the KUKA manual describes it in detail. Or you just have an intermediary position described in absolute axis values - works as well.
I stand by my opinion that relative movements are not particularly useful in a CAD environment. That being said, they should not be difficult to implement, so there is a chance they will make their way into KUKA|prc.

Best,
Johannes

Xylotica

Hi Johannes,

I have yet to make the "status" and "turn" produce something satisfactory ; I suppose I don't use them correctly.
Also, using PTP, I often get the robot to halt and an error message stating that I have exceeded some acceleration value.
Hmm... looking at that PTP component, I see tht the velocity is described in "percentage" ; that's probably where I messed up, because the LIN, CIR, and offset components use m/s.
Percentage of what speed, by the way ? The max speed of the robot ?

Regarding singularities, couldn't KUKA implement a smarter inverse kinematics algorithm ?
Something in the lines of : "If two axis are aligned, try to find the position that doesn't end up maxing out an axis" ; you know, like a chess computer looking ahead and eliminating stupid moves.

Cheers,


Johannes @ Robots in Architecture

Hello,

The manual is really helpful there, status and turn basically describe the posture of the robot with a series of 0s and 1s, if an axis is in the positive or negative range, overhead or not. If you program it wrong, you will get "out of reach" errors.
And yes, PTP is in % of the maximum speed.

Singularities are just a mathematical reality and the things you can do on the robot side to avoid them are limited - after all you wouldn't like your robot to leave its path to avoid a singularity. Only with certain applications like milling you can influence them quite easily as the tool is symmetric, i.e. we can rotate the tool axis without any negative impact. E.g. PowerMill has got a nice graph where you can change the orientation, as you would do in KUKA|prc with the Orient Plane component.

It's much easier to consider them in the simulation and move your workpiece or robot - having an extra external axis is extremely helpful as well.
PTP movements do not suffer from singularities, so you can use series of PTP movements as well - of course at the expense of accuracy.

Best,
Johannes