Switching base without stop the robot

[lun81]

Hi guys!

Someone know if it's possibile to switch from (for ex. $BASE_DATA [1]) to another one (for ex. $BASE_DATA[2]) avoiding stop the kuka??   

I have to go from point1(calculated in BASE_DATA[1])  to  point2(calculated in BASE_DATA[2]), but i don't want that the robot "stop" to switch base. Does exist some trick?

Thanks in advance for eventual helps   

[Sven Weyer]

Jupp, no problem my friend.
When you use system variables from the KUKA-System like $..... try to use a line befor the instruction "CONTINUE". Thats makes wounder. It's the same when you want use IF $IN[??]==TRUE THEN. Try to use the line befor the "CONTINUE". You will see it works better.

Sven

[mookie]

when you say stop, are you talking about the robot "jolting"? I dont know of a way to have it not jolt when changing a tcp or baseframe.

[lun81]

Thank u Sven for the advice, as soon as possible i will try to put "CONTINUE" before switch the base and i will see if it work good...

For mookie: yes I'm talking about the robot "jolting" when i switch $BASE...
For example if I'm working on $BASE_DATA[1] and the next ptp is in $BASE_DATA[2] I have to switch $BASE_DATA, but when i switch base the robot make a little arrest and then go.

Maybe exist an instruction to avoid it.
I'm working on a Kuka Palletizer and i have to use many external bases and consequently switch many times $BASE_DATA[].
For now I solve the problem switching base in some positions where the kuka work slowly and so the "jolting" is less visible..

[mookie]

I dont know if its a hack or not but you may be able to do the following,

def PornSet()

DECL Frame TempFrame = {x 0,y 0,z 0,a 0,b 0,c 0}

INI


ptp $pos_act

$base  = base_data[1]



base_data[1] = tempframe

; put a move using baseframe 1 here

tempframe.x = 100

base_data[1] = tempframe


end


try something like that


changing the base data on the fly without changing the actual base frame may help in solving it

[asimo]

I've you tried the geometric operator (:)?

Something like:

base_data[1]:base_data[2]:{x ?, y ?, z ?, a ?, b ?, c ?}

This is what I would try, but not sure if it can work.

[lun81]

Yes, I see the Geom_op in the manual but I don't understand very much his function.
Because I've tried some operations with the simulator program but don't work good, give me errors like "point not reachable", maybe I wrong something..   
I'm studying now geometric operator.

If I'm working in $Base_data[1] and I have to go on point2 calculated in $Base_data[2]

I have to program the instruction

base_data[1]:base_data[2]:point2

it's right?

[the leg]

if you have a move p1 with base 1 and move p2 with base 2 then try

P1 .....

continue

$base= base_data[2]

p2........

[mookie]

the problem isnt the continue statement, the problem will always be switching

$base = base_data[1] to
$base= base_data[2]

regardless of the continue statement.

I think i have some people much smarter than me back in town this morning that ill ask but im pretty sure that this is something  you gotta live with and thats why i suggested finding a way to modify the base data. that may not even work correctly without a geometric operator.

sorry I dont have more time to help or else id try it on my own.

Skyfyre is out for the day with SARS but he may be able to help shed some more light on the topic, i think i asked him about it and we both agreed.

I dont know of anyway around that either.. 

[the leg]

I will try it in the morning but i thought you could switch the base and tool on the fly using the $base= command
but i will try it and see

[asimo]

To answer your last question lun81, I would say no. At first, I thought your second base was defined in reference from the first one and the first one from $WORLD, but as I understand it now, your point "point2" seems to be defined relatively to your second base only and you are working from base_data[1]. If you use the geometric operator this way (base_data[1]:base_data[2]:point2), that would probably put your point to far (unreachable) depending on where your bases are defined. For example, if your 2 bases have the same orientation, you can see this operation like "adding" the 2 frames together (only in the case where the 2 bases have the same orientation, i.e. one is not rotated relatively to the other) and then go to the point relatively to that new base...everything from the base you are currently in!

It is an interesting problem. Honestly, I will have to think about it, I don't have an answer. If we could find a way to specify the $WORLD relatively to $BASE, then I think we could achieve that, because then it will be possible to return to $base_data[2] from $WORLD relatively to $base_data[1]. But I think it is not as easy as to specify the inverse values, because of all the rotations and depending on the axes directions.

It's too late now and I need some sleep.  I'm probably really unclear. I hope somebody will find a solution for you. Sorry for now.

[lun81]

Thanks guys for the reply and for the help of my problem.

For asimo: unfortunately I see too that the geometric operator work good (in my case) only when the Bases have the same orientation.It is all the same, I have learn something new   

My problem is not top urgent.In my application I have to use many external bases and I switch base in strategic points where the "jolting" is less visible...
But i thought that it would be nice solve this problem (in general) for 2 reason:

1 Earning time
2 Earning aesthetics

This doubt hit me because I've  see some robot's videos where the robot work and make complex operations without "jolts" with nice linear movements.
I think I will try to phone to kuka assistance and hear what they tell me...

[asimo]

I thought at something today but haven't tried it and wanted to share it with you, so that perhaps it will give a good idea to somebody else to find a solution. Actually, it is complicated and there must be a better way to do so (don't know if it works):

{x 0, y 0, z 0, a 0, b 0, c -base_data[1].c}:{x 0, y 0, z 0, a 0, b -base_data[1].b, c 0}:{x 0, y 0, z 0, a -base_data[1].a, b 0, c 0}:{x -base_data[1].x, y -base_data[1].y, z -base_data[1].z, a 0, b 0, c 0}:base_data[2]:point2

I was thinking that if we want to put one base back to the $WORLD, we had to reverse the transformation in the right order. In order to do so, we have to rotate, one at a time, in C first and in reverse direction (because it's the last transformation), then in B, then in A and then translate in reverse order X, Y and Z. From that point, we know that the other base is defined from the $WORLD, so we put it relative to it and finally, we add 'point2'.

[asimo]

I tried it virtually and it seems to work! The only thing is that you cannot use directly a variable inside a frame. So I did something like this:

;--------8<--------
; Declaration section
DECL FRAME base_c, base_b, base_a, base_xyz

; Initialisation section
base_c = {x 0, y 0, z 0, a 0, b 0, c 0}
base_c.c = -(base_data[1].c)
base_b = {x 0, y 0, z 0, a 0, b 0, c 0}
base_b.b = -(base_data[1].b)
base_a = {x 0, y 0, z 0, a 0, b 0, c 0}
base_a.a = -(base_data[1].a)
base_xyz = {x 0, y 0, z 0, a 0, b 0, c 0}
base_xyz.x = -(base_data[1].x)
base_xyz.y = -(base_data[1].y)
base_xyz.z = -(base_data[1].z)

; MAIN
;...
; movement here and change to base_data[1]
;...

; Go to point2 calculated with respect to base_data[2] from base_data[1]
PTP base_c:base_b:base_a:base_xyz:base_data[2]:point2
;--------8<--------

I've only tested 1 point and it seems work fine (I hope that my mind haven't trick me because I want it to work). Maybe you can try this way and let us know if it works. I hope that there is a more aesthetic solution (if this one is working) :-)

[lun81]

I prepare the simulation and as soon as possible I try it and I tell you!