Hello all. I am new to KUKA and wondering what software option KUKA uses to allow two robots to work in the same space and monitor each other. I did a project similar with Fanuc and its called interference check or space check. Curious what i will need to do the same thing but with KUKA robots. Thanks!!
KUKA robots sharing workspace
-
Iprogram -
January 23, 2019 at 10:14 PM -
Thread is marked as Resolved.
-
-
I'm not sure that KUKA has an exact equivalent -- on those Fanucs, was it two separate controllers, or two robots on the same controller?
Anyway, there are multiple methods one could use to deconflict multiple KUKAbots in the same workspace:
You could use simple handshaking I/O in your programs.
You could create volumes using the Cartesian or Axis Workspace system variables in each robot, and link those Workspaces to outputs that the other robot(s) monitor as inputs.
-
I realize this thread is old, but SkyeFire you're describing something I've been trying to find with little luck.
I think I understand the workspace and using outputs to inputs method, but could you elaborate on the handshake method? As I understand, handshakes are used to establish communication between devices. Do you mean using something like EthernetKRL to send position data between the robots?
In case you need context:
I'm currently researching how to have two robots monitor each while working on the same workpiece, but opposite each other. I was thinking of creating volumes with the workspace that divide the workpiece in half. However, there may need to be work done on the workpiece near or across the workspace boundary. I'm not sure how to make sure that when one robot is near (given some tolerance) or at the boundary, that the other can't go near the boundary at the same time.
Thanks!
-
in this case term handshake was meant as an interlock. that is where workspaces come in (of course cell must be safeguarded so humans cannot get in). exact strategy depends on size, position, shape if spaces, speeds involved, stopping distances etc.
for example on robot A you can configure one space to tell to robot B if robot A is within that space (type #INSIDE). it is not a position value, it is just a flag. on robot B you can use same volume in space as a workspace. and change the type of space to (#INSIDE STOP) when robot A is already there (and same thing could be on the other robot). one can use an arbiter to prevent deadlocks and if needed handle requests to reserve space (more signals needed).
and nobody says this has to be one volume, you can have several and let arbiter make suitable choice.
or if you are transmitting robot position value, you could keep space type fixed but dynamically change size of space. good luck..
and if you really want to make sure that robot programmers cannot cheat, use safety PLC as arbiter, have SafeOperation on robots (so make sue of safe spaces) and change passwords.
-
Yeah, I was using "handshake" in the sense of two (or more) workers yelling "Clear? CLEAR!" at each other across a noisy workspace. Not in the communication-protocol sense.
There are some similarities, though. You want a complete "closed loop" of request and acknowledgement for clearance zones, not just the "in zone/clear of zone" signals.
The reason for this is signal lag -- run the machine long enough, and eventually, you will hit a condition where each robot hits the zone entry at the same time, each sees the other as being clear, and they both enter the zone, because it takes a few tens of milliseconds for the "not clear" signal to propagate. Don't ask me how I learned this -- it certainly wasn't on my very first robot job, and definitely didn't result in a very loud, expensive collision.
Cross-linking their respective zone-clear signals with their motion enables is a safety net -- if the one-time check at the zone edge somehow fails and lets both robots into the zone at the same time, you can use the combination of "both robots not clear" to E-Stop or otherwise halt the robots to prevent a collision.
One of the nice things about using the WorkSpaces built into the KRC is that they work dimensionally, regardless of whether the program is running, or if someone, say, skipped over the program lines that should have reset the clear signal. One weakness to the Cartesian workspaces is that they are dependent on the active $TOOL, as they measure the active TCP position against the workspace boundaries. The AXWorkSpaces don't have this issue, but don't lend themselves to rectangular spaces very well.