June 26, 2019, 06:26:45 PM
Robotforum | Industrial Robots Community

 How to avoid Continuous path slow down near singularity points

normal_post Author Topic:  How to avoid Continuous path slow down near singularity points  (Read 8550 times)

0 Members and 1 Guest are viewing this topic.

March 23, 2011, 04:11:38 PM
Read 8550 times

JEROME

Guest
I have a painting robot application with a KR30 L16-2

the trajectory are given by a PC (C# application)
then the robot execute what is receive from the computer

so sometimes it happens (often..) that the robot pass near singularity positions (A5 ~ 0°)
i arrive to avoid the singularity alarms by setting $CP_VEL_TYPE to #VAR_ALL

but in the neighborhood of A5~0° i have a consequent slowdown of the TCP ($vel_act) while A4 A6 axis increase their speed
it's not good for painting results!

so in order to optimise the global performance
I want to know if someone have any solution to
avoid or to reduce this slow down.

i can not understand that is not possible to guarantee a constant speed when the A5 comes near 0°
it's a well-known problem.

..if someone have an idea i buy!

Today at 06:26:45 PM
Reply #1

Advertisement

Guest

March 23, 2011, 04:57:39 PM
Reply #1
Offline

SkyeFire

Global Moderator
The standard way of getting around this problem is simply to never let A5 approach 0deg.  This usually requires changes to the tooling, mounting the spray gun at a different angle on the A6 flange such that A5 is held away from 0deg during all painting motions.

Another way is to break up or re-arrange the paint paths so that singularity doesn't happen during a paint stroke, but that's not always possible. 

A third way is to raise/lower the robot base mounting to achieve the same effect as the first option.

You could also slow down an entire paint stroke to match the TCP speed near singularity, but that probably isn't acceptable. 

If your paint system accepts analog flow control, you can link the TCP speed to an analog output and have the paint flow rate adjust on the fly to match the TCP speed.  But this only works on paint systems that have very good, rapid response to flow-rate change commands.

There are some system options to let the robot pass through singularity with less speed reduction, but this involves letting the TCP orientation "wobble" to make less work for A4 and A6.  I suspect this isn't an option for a painting application.

March 23, 2011, 05:41:53 PM
Reply #2

JEROME

Guest
Hello SkyeFire, thanks for replying

the last solution about system options you said could be eventually an interesting option for me
because i think i can accept a little approximation (few centimeters) ponctually in the TCP path

So i'm interested in such option
could you tell me more about this ????

can i activate this directly in the robot
or by paying something to kuka ???

March 24, 2011, 02:44:22 PM
Reply #3
Offline

SkyeFire

Global Moderator
Well, the "drift" in the TCP would be in orientation, not location.  And you could see quit a bit of orientation change.  Not to mention, just because you're letting the TCP orientation drift to avoid singularity doesn't mean that you won't see a speed change, since you're up against the physical speed limits of A4 and A6.

Keep in mind I've never used this approach myself, so you'll need to experiment carefully.

The $SINGUL_STRATEGY system variable controls whether TCP orientation drift is allowed or not during LIN moves to avoid singularity.  A setting of 0 prevents drift, a setting of 1 allows it.  I would recommend only setting this to 1 for particular moves in particular programs -- leaving it at 1 all the time would be unwise.
$SINGUL_ERR_PRO and $SINGUL_ERR_JOG are FRAME variables whose A, B, and C values control how much orientation drift is allowed around those three axes, in PROgram and JOG modes respectively.

Or, instead of changing the system variable, you could try setting $ORI_TYPE  to #JOINT for the duration of the move.  But the TCP orientation will be entirely uncontrolled and unlimited.

March 24, 2011, 04:07:37 PM
Reply #4

JEROME

Guest
I ask again about my singularity slowdown


i look in the documentation

and i found different things such as

      $SINGUL_STRATEGY: strategy for motion without singularity
      $SINGUL_POS[3] : A4 behavior in case of wrist singularity
      $SINGUL_ERR_PRO : max orientation default for motion without singularity in automatic mode

i try different options this morning with these variables but with no success i have still a slow down near singularity
I suspect this is only for PTP motions but i am not sure

is anybody has ever use these variables??

OPTION 2
$ORI_TYPE = #JOINT

i made a test with this setting but the robot had "Torque default A6"
by adjust $VEL/ACC_AXIS[4]-[6]
i could avoid these default

but the result is not very good, same slow down near singularity pos i have no idea
the hotline kuka have no idea except send me a technician ....




March 24, 2011, 04:37:16 PM
Reply #5

JEROME

Guest
Hello SkyeFire
thanks for your informations

i was just writing my post when you reply arrived

so i was not in a so wrong way!

i will test the both options carefully it seems that is the kind of solution i need


March 25, 2011, 02:00:53 PM
Reply #6
Offline

SkyeFire

Global Moderator
To address some of your other comments:

PTP moves don't have singularity issues.  Only LIN moves (or CIRC) suffer from singularity.

$SINGUL_POS, as I understand it, controls how the robot assumes the axis should be treated in the event of a singularity.  But I've never used it.  Have to add that to my list of Things To Experiment With Someday.

Keep in mind, though, any of these solutions can only help to a certain degree -- as you approach wrist singularity during a LIN move, A4 and A6 have to rotate faster and faster, and if you reach their maximum speed, the robot has to slow down to let them keep up.  $SINGUL_STRATEGY or $ORI_TYPE allow the wrist to move more naturally, helping you to "sneak past" the singularity, but there is a definite cost in accuracy.

This is, in fact, the reason that paint robots used to be made with special wrists that didn't have the singularity issue (although they had other issues instead).  The industry has moved away from that over the years as general-model robot performance has improved, but really, the best way to deal with singularity is to avoid it in the first place.  This is an area where Simulation software has helped -- it makes it possible to test multiple tool mounting designs before any have to be actually built.

Today at 06:26:45 PM
Reply #7

Advertisement

Guest

June 26, 2014, 07:44:00 AM
Reply #7

sunshine_boycn

Guest
How could I set $CP_VEL_TYPE to #VAR_ALL? The kuka system always come along with this variable is written protected.

Even I changed $CP_VEL_TYPE = #VAR_ALL in the file Steu\mada\cumstom.dat

After I reboot the system, the file is changed back to the original value #CONSTANT. Are there any method to solve this problem?


 : A4 behavior in case of wrist singularity
      $SINGUL_ERR_PRO : max orientation default for motion without singularity in automatic mode

i try different options this morning with these variables but with no success i have still a slow down near singularity
I suspect this is only for PTP motions but i am not sure

is anybody has ever use these variables??

OPTION 2
$ORI_TYPE = #JOINT

i made a test with this setting but the robot had "Torque default A6"
by adjust $VEL/ACC_AXIS[4]-[6]
i could avoid these default

but the result is not very good, same slow down near singularity pos i have no idea
the hotline kuka have no idea except send me a technician ....

June 27, 2014, 01:55:18 PM
Reply #8
Offline

wes_mcgee


It shouldn't change back after a reboot, I have mine set to #VAR_ALL (without this you can have a crash in T2 near a singularity). Maybe make sure you deselect the submit interpreter before changing it(maybe that only matters for changing system/config).

As to the original post....you need to change your tool(which potentially just sends the problem somewhere else in the work envelope) or move your part(maybe not possible if you are using a majority of your reach), its that simple. This is where having an external axis really comes in handy.


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter

xx
continuous motion - avoid exact positioning between two motion commands

Started by robotneuling on KUKA LBR IIWA

1 Replies
704 Views
Last post May 30, 2018, 03:57:49 PM
by razzo
xx
problem with continuous path of motion on KUKA robot

Started by hotRoboter on KUKA Robot Forum

10 Replies
2270 Views
Last post September 19, 2017, 12:39:21 PM
by hotRoboter
question
Singularity

Started by i.sabonis on KUKA Robot Forum

1 Replies
1854 Views
Last post September 15, 2014, 12:31:32 PM
by SkyeFire
xx
Singularity

Started by GeminiChris on Fanuc Robot Forum

1 Replies
349 Views
Last post March 15, 2019, 02:38:53 PM
by Doctor_C