Robot-Tool collision

[florian82]

Hi!

I would like to know if this is possible to make sure that the robot will not hurt himself with his tool...
For example, a gripper (1000mm * 1200mm )

Is there an easy way to do this ?

Regards,

[SkyeFire]

That depends on what you are trying to do. 

You can set 3D areas where the robot will be stopped if it tries to enter or leave.

You can turn up the sensitivity of the torque monitoring and slow the robot down so that any impact stops the robot before much harm is done.

[florian82]

Thanks Sky,

isn't it possible to define the tool (wich is fixed to the head of the robot) and then the KUKA knows by himself where he is able to go without hurting himself?
 
I mean, set the volume of the tool...

If not, how to set 3D areas ? (it seems to be harder)

Regards,

[bipinpaul]

Hi Florian

It is not possible , to just tell the volume of the tool to the robot, because the volume ( cube or cuboid) can be mounted any where on the surface of the gripper,

Normally robot works in orign points , u have to define a 3d or 6d and its orign...say if u use gripper as a tool , u should first teach  the tool center point ( Tool center point). Robot will move the TCP point accordingly, but other than that if u want to know about the finding the volume of the gripper and its volume , u have to implement camera systems... which we use it for  dynamic tool change syatems and it is a hell lot of money.

u need to know what type of application u r using it for..we always need to keep in mind that  robots are just to keep our life and work easier, quicker and simpler  in real time.  so what type of application u need robots far.?

[florian82]

hi bipinpaul, thank you,

I just need it to depalettize a layer of 8 boxes, so this is a "big" gripper (1300*1100 mm * 400)

We can maybe define our tool as a cuboid, with the cotation from the origin of the head ( , example x1: -400 x2: 700
y1: -550 y2: 550  Z1:0  Z2:-400

Any suggestions ?

regards,

[markopo]

Hello Florian82.
One is that You are worrying about overload ?
And second to make sure that robot push nothin' around ??
Simply I say that we don't use any 3d spaces where robot is safe. If You have a good trained operators, which knows when he can SIMULATE signals and when NOT, there is no NEED to make this complicated 3d spaces.
For example You have to depaletize two stacks of boxes right? You are using LIN SUCHE command. And for example there was last layer of boxes on pallette ? Without any sensors You have to TRUST your OPERATOR :) No other way :)

Marek.

[florian82]

I'm not worrying about overload because we have a 180-2PA  and the 8 boxes are about 80-100Kg ...

Then , I don't worry about robot push nothin' around, I worry if the robot hits HIMSELF with his tool...

[SkyeFire]

Well, the problem is that the robot simply can't keep track of the entire end effector in realtime.  Even for computer programs that do this for simulation, like Delmia and RobCAD, this is a hard task and slows down the computer.

The robot normally tracks a single point, the TCP, in space while the program is running.  This is well within the mathematical capacity of the processor.  But a large, complex end effector would be, in effect, a "cloud" of thousands and thousands of points, and trying to calculate where all of them are in realtime would be more than most robot processors can handle.  I'm sure that this is a feature that will come into being over time (and some rigs I've seen that actually use RobCAD to drive the robot in realtime already exist), but not right now.

If you had good measurements of the end effector, it would probably be possible to track some points (say, the corners) of the tool in realtime by hand-coding some routines in the SPS.  But then we run into the next problem:  industrial robots don't keep track of where their "bodies" are -- they depend on us not to program them to hit themselves.  Again, it is mathematically possible to do something like that, but since most robot arms have complex shapes, it wouldn't be easy at all.

[markopo]

florian82.
I don't get one think. You have programs tested, trajectory is known, all programs ran in hand mode ?
All of up's and makros to gripper tested ? What kind of hits ? You have robotic cell ? with fance ? with e-stop wiring ?
Or there is just robot in open space and there is possibilty that some moving part can hit robot ?
I saw a many crashes ? Last one in last wednesday when one of Kuka 180 crashes on A2 - gear ? Robot just lay (and even gas cylinder not balance robot ax) on weld station. ? And what ? change of robot corrections on gripper ( measuring) , with TCP and run again of production.
The crashes can happens and will be. By accident, by operator mistake, by broken parts. I think that You can mount some sensors on gripper ( optical or else) and read this signals while robot works. But what for ?
The key is proper program, and good tested locking with other devices like robots or convoyers or else.

Marek.

[florian82]

Okay,
In fact, I'm in internship in a factory and I have to programm a kuka to depalettize.
The idea is:
- one basis with the full palet
- one basis with the empty palet
- one basis with the conveyor

Then, the program is "general" and go to palet-conveyor,palet-conveyor.....palet-emptypalet  palet-conveyor....
So these basis are not fixed, we want to place them for each customer, and by their choices, I was scared that the Kuka hurts itself by going to palet to conveyor or to palet-emptypalet...

I already tested my program with 3 basis and its working fine but if the customer puts three basis close too the Kuka, maybe he will hurt himself.

This is a problem because I want to have a "general" programm but we can do and test for each customer, so this isn't a big problem but it could have been cool ^^

[SkyeFire]

Well, that's where the 3D zones come into play.  Look up "Workspace Monitoring" in the manuals.  You can create "forbidden zones," either rectangular or cylindrical, where the TCP is not allowed to go.