KUKA GradProj Laith Salameen 2017

KUKA Systems and Applications Design
A technical report submitted in fulfillment of the requirements for our Graduation Project
Department of Mechatronics Engineering,

German Jordanian University, Madaba,
First semester 2017
Salman Darbisi
Abdelkarim Estatieh
Laith Salameen
Advisor: Dr. Nathir Al-Rawashdeh

Abstract
In this text, we present a detailed review of the basic understandings of a KUKA robot, an overview of
the hardware and some technical specifications. In addition to that, we review basic programming
structures and project configurations and hardware implementation using WorkVisual. Moreover, we
analyze an open source API called “JOpenShowVar” and utilize it to communicate with the robot in
soft real-time. We furthermore built a toolkit that allows the logging of any KRLVariable with a
preferred sampling period. We also created a drawing program for demonstrative purposes using the
API and created an interfacing method with MATLAB using a shared XML file. Finally we designed
a virtual cage and a simple gripper.
Table of Contents
Abstract ................................................................................................................................................... 1
Terminology............................................................................................................................................. 4
Introduction ............................................................................................................................................. 5
Basic overview ..................................................................................................................................... 5
Technical Specifications ...................................................................................................................... 5
Application Areas ................................................................................................................................ 6
System Components ............................................................................................................................. 6
Hardware Connections .................................................................................................................... 6
Safety ....................................................................................................................................................... 7
KRC4 Compact Controller ........................................................................................................................ 8
External Connections of KRC4 Compact ........................................................................................ 8
Start-up .................................................................................................................................................... 9
SmartPad (KCP) .................................................................................................................................. 9
KRC Operating Modes ........................................................................................................................ 9
User Groups ....................................................................................................................................... 10
Jogging robot ..................................................................................................................................... 10
Changing jogging coordinate system ............................................................................................ 10
Displaying actual position ................................................................................................................. 12
Tool and Base Calibration ................................................................................................................. 15
Work space monitoring ..................................................................................................................... 17
Writing KRL Code ............................................................................................................................ 20
Motion commands ......................................................................................................................... 20
Tool and base selection ................................................................................................................. 22
1
Gripper actuation ........................................................................................................................... 23
Mastering of the Axis ........................................................................................................................ 24
Mastering procedure ...................................................................................................................... 25
Shutdown or Hibernation ...................................................................................................................... 29
Technical Details .................................................................................................................................... 30
KRC4 Compact ................................................................................................................................. 30
KRC4 Compact Topology ............................................................................................................. 32
WorkVisual ............................................................................................................................................ 36
Important Initial Setup and Configuration......................................................................................... 36
Get current project from controller.................................................................................................... 41
Network Configuration of Windows interface .............................................................................. 41
Mapping inputs and outputs in WorkVisual ...................................................................................... 43
Configuring and Mapping BECKHOFF module............................................................................... 48
Mapping Input terminal EL1809 ................................................................................................... 48
Configuring Profibus Slave ........................................................................................................... 49
Transferring and activating a project ................................................................................................. 54
Projects Management KRC side ............................................................................................................ 55
JOpenShowVar ...................................................................................................................................... 56
Introduction ....................................................................................................................................... 56
Setup .................................................................................................................................................. 57
JOpenShowVar’s API ....................................................................................................................... 60
Configuring KRC global variables ................................................................................................ 62
Interfacing JOpenShowVar with MatLAB ........................................................................................ 63
GJU-KUKA Toolkit .................................................................................................................................. 65
Requirements ..................................................................................................................................... 65
Basic Outlook on OpenCV ............................................................................................................ 67
Data Logging Tool ............................................................................................................................ 68
Drawing Tool .................................................................................................................................... 71
KRC side Program ......................................................................................................................... 73
KUKA virtual cage .................................................................................................................................. 74
System block diagram and hardware used .................................................................................... 74
Software......................................................................................................................................... 75
Detection angles, blind spots and ranges of the safety cage .......................................................... 76
Simple gripper design ............................................................................................................................ 78
Von-mises stress simulations under static load of 1 kg ..................................................................... 80
2
Appendix A1 – MATLab code for Motion Detection ............................................................................. 82
Appendix A2 – Java code for Motion Detection .................................................................................... 85
Appendix B – GJU-KUKA Toolkit ............................................................................................................ 93
Appendix C - Example KRL code done by Faris Qutaishat and Al-Bara Abu Shaqra ............................ 122
Appendix D - Arduino Code for the Virtual Virtual Cage ..................................................................... 123
Appendix E – Gripper Dimensions ....................................................................................................... 129
List of important figures ...................................................................................................................... 134
References ........................................................................................................................................... 135
3
Terminology
CIP Safety: Common Industrial Protocol Safety, it is an Ethernet based safety interface for
connecting a safety PLC to the robot controller. (PLC = master, robot controller =slave)
CCU_SR: Cabinet Control Unit Small Robot
CIB_SR: Cabinet Interface Board Small Robot
EMD: Electronic Mastering Device
KCB: KUKA Controller Bus
KEB: KUKA Extension Bus
KPP_SR: KUKA Power Pack Small Robot
KRL: KUKA Robot Language
KSB: KUKA System Bus.
KSP_SR: KUKA Servo Pack Small Robot
KSS: KUKA System Software
Manipulator: KR6 R900 Robot
PMB_SR: Power Management Board Small Robot
RDC: Resolver Digital Converter
4
Introduction
Basic overview
KUKA KR Sixx is an industrial robot, founded by a German manufacturer of industrial robots, KUKA
Roboter GmbH. Moreover, it is of the particular line of AGILUS systems that are the small sized
robots from KUKA.
It has a maximum payload capacity of 6 kg and a reach of approximately 901 mm. The KR 6 rated for
particularly high working speed, and has been classified in 2014 as the Fastest Robot on Earth.
Technical Specifications
 Robot: KUKA KR Sixx R900

 Robot Serial: 501733
 Number of axes : 6
 Weight: 52 kg
 Mounting position: Wall, ceiling , floor
 Controller: KR C4 compact
 Optional Add-ons: X12 X15A/B X55
 KRC Version: KR C, V8.3.8, Build 82
 KRC Options:
1. ExpertTech ,V3.2.0, Build 6
2. Gripper&SpotTech ,V3.2.0, Build 3
3. RemoteService ,V1.1.1, Build 7
4. UserTech ,V3.2.0, Build 8
Figure 1- KUKA KR Sixx R900 robot
5
Application Areas
 Handling loading and unloading.
 Assembly.
 Forming machine tools.
 Measuring, Testing and inspection.
 Packaging and order picking.
 Application of Adhesives and sealants.
 Fastening.
 Cutting machine tools.
System Components
The industrial robot consists of the following components:
 Robot mechanical unit

 Robot controller (KRC4 compact and RDC)
 SmartPAD teach pendant
 Connecting cables
Hardware Connections
1. Manipulator
2. Teach pendant (SmartPAD)
3. Connecting cable
4. Robot controller (KRC4 Compact)
5. Data cable
6. Motor cable
6
Safety
It is very important to ensure safety regulations are met, as this is an industrial robot capable of
severely causing harm to you, and to your surroundings. So before operation ensure the following are
configured.
1. X11 is properly connected and functional

2. Workspace Monitoring is active at all times
3. Mastering done and axis limit switches configured
4. A safety gate is installed
5. Collision detection enabled
The X11 connection should have at least one dual channel EMERGENCY STOP. This is to ensure a
backup is present should the SmartPAD ESTOP fail or if a connection is broken!
As for Workspace Monitoring, it must be active and configured properly. This ensures that the robot
does not collide with the surrounding workspace, such as the table. The axis limit switches ensure that
the robot does not collide with itself.
When programming the set speed should always remain under 30%! The maximum speed is
limited to 30% during jogging; however, it is not limited in T2, AUTOMATIC and EXTERNAL
AUTOMATIC OPERATING MODES!
DO NOT ASSIGN THE FOLLOWING IP RANGES to the windows interface
 192.168.0.0 - 192.168.0.255
 172.16.0.0 - 172.16.255.255
 172.17.0.0 - 172.17.255.255
7
KRC4 Compact Controller
The KRC4 Compact has two parts:
1. Control Unit (The upper half of the KRC4)

2. Drive Box (Bottom half of the KRC4)
Control Unit
Drive Box
Figure 2 - KRC4 Compact segments
External Connections of KRC4 Compact
1. X11 - Safety interface

2. X19 - SmartPAD connection
3. X65 - Extension interface
4. X69 - Service interface
5. X21 - Manipulator interface (Data Cable)
6. X66 - Ethernet safety interface
7. K1 - power supply connection (230V Power)
8. X20 - Motor connector (Motor Cable)
9. Q1 - (ON/OFF Switch)
Additional Interfaces:
 X12 - INPUT/OUTPUT pins

 X15A/B - PROFIBUS Slave IN/ PROFIBUS Slave OUT
 X55 - Power OUT and interface to power BECKHOFF terminals
8
Start-up
After installing all the cables and providing power to the KRC; start the controller by switching on the
button (Q1) found at the right side of the controller and wait for the KRC and windows interface to
load.
SmartPad (KCP)
Once the KRC loads up and the SmartPad (also known as KCP-KUKA Control Panel) is connected.
You will be introduced with the SmartPad interface. The SmartPad interface allows you to adjust the
SmartPad options such configuring brightness and contrast, in addition and diagnostic tools such as
pinging the KRC and editing the RDP and KCP addresses. Moreover it allows you to select the
different controller modes.
Figure 3 - SmartPad Interface
The SmartPad keyswitch allows you to switch between the SmartPad interface and the controller
interface the after selecting a mode.
KRC Operating Modes

There are 4 different operating modes, each with a specific function and limitations, and are as follows:
1. T1 - Test Mode 1
This mode is used for testing and programming. Velocity is limited to a maximum of 30%.
It allows you to Jog the robot and teach points, but you are unable to run the program
continuously but rather in steps and you must hold down the enabling switch at all times
during robot motion. Note that if you programmed a velocity of 50%, and tested it your
program; the speed will only be 50% of 30% = 15% of the actual speed of the robot!
2. T2 - Test Mode 2
This mode is exactly like T1; however the velocity is not limited (up to 100%). This allows
you to test programs at high speeds.
3. AUT - Automatic Mode: This mode allows programs to run automatically at the programmed
velocity. You are unable to jog the robot in this mode. Velocity not limited! (up to 100%).
9
4. EXT - Automatic External Mode: This mode allows you to use an higher level external
controller to control the KRC. E.g. PLC (master)  KRC (slave). Velocity not limited! (up
to 100%).
User Groups
There are different user groups; each has a different permissions and authorizations in accessing,
privileged configuration options and instructions.
The main three user groups are:
1. Programmer: The default user group, set during start up or switching of operating modes. It
authorizes programming using basic KRL commands.
2. Expert: A privileged user group, that allows programming with the Expert Programming
Language and authorizes start-up options such as mastering, calibration, selection projects
and changing network configurations. It also allows you to shut down and restart the
controller with the option of reloading of the KRC files.
3. Safety Maintenance: Allows the user to change the safety configuration of the controller.
Jogging robot
In order to jog the robot it is necessary to be in T1 or T2 operating modes. In order to move the robot
you need to hold down one of the enable switches and choose which axis you would like to move the
robot in.
The enable switches are located at the base of the SmartPad and are coloured in green. These enabling
switches have three positions.
1. The normal position or released position. This is the primary position of the switch when the
switch is not pressed. You will be unable to jog the robot. If you release the switch while the
robot is moving; it will stop.
2. The enable position. This is the position that allows you to jog the robot and start programs.
You must soft press the switch in order to get to this position.
3. Panic mode: this position is the final position and occurs if you hard press the switch. This
will cause the robot to stop and an error message is displayed.
Changing jogging coordinate system

You may change from jogging in axis to using a Cartesian coordinate system by first clicking on the
earth icon located at the top right corner of the interface and selecting the Options button.
10
A new window will open and you can select the coordinate system you would like and confirm by
clicking the sync button.
You will notice that the jogging tools will change from displaying A1-A6 into X,Y,Z,A,B,C.
11
Displaying actual position
You may display the actual position of the robot by selecting display from the main menu  Actual
position.
A new window will open and you may choose between axis positions and Cartesian positions.
If you select Cartesian positions, the positions displayed are the tool centre point relative to the base
initial coordinate of the currently selected base and tool selected.
When you first choose it you will receive null values. This is because there is no base or tool selected.
If you choose the base and tool as $NULLFRAME you are selecting the world coordinate system as a
base and the flange as your Tool Centre Point.
12
When they are both select the actual positions are displayed for that configuration
13
When you choose a different base and tool these values will change.
14
Tool and Base Calibration
In our case we calibrated both the base and tool numerically as we have the actual positions of the
robot in the world and flange coordinate system. For our purposes we wanted to calibrate our zero
point for drawing purposes. By using the actual position with the base and tool at $NULLFRAME we
can determine where that point is and set it numerically for the base. The base calibration is always
relative to the World Coordinate System which is located in front of the robot. As for the tool
calibration it is always relative to the flange, in our case we kept it that way.
An easy way to grasp this is using the right hand rule of coordinate systems, where X is the Thumb, Y
is the index and Z is the middle finger. A is the rotation of the coordinate system around the X axis. B
is the rotation around the Y axis and C is the rotation around the Z axis. In our case we wanted the X
and Y coordinate systems of the drawingBase to be directed at the robot, while the Z axis negative
going up. For this reason we chose A=180deg and C=180deg.
Figure 4- Base Calibration (After rotation around A and C)
15
World
Coordinate
System
X: 762mm, Y: -447
mm, Z: 173mm
Figure 5- Base Calibration (Translation)
drawingBase
Coordinate
System
-Z
Figure 6- Final drawingBase Coordinate System after translation and rotation
16
Work space monitoring
Our concern about safety is very high because any misuse or a fault in the program executed may
constitute a fatal damage or to other material property.
Therefore high safety must be provided and controlled in order to avoid these situations. To do so we
define a workspace, in which the manipulator is allowed to move around in. The workspace is derived
from the individual axis ranges.
Figure below shows the setup of the work space borders from the defined origin we used for our
application showing the axes configuration.
1. In the main menu, select Configuration > Miscellaneous > Workspace monitoring >
Configuration. The Cartesian workspaces window is opened.
2. Define the origin of the workspace by entering the X,Y,Z coordinates relative to the world
coordinate system.
3. Define the workspace relative to the origin of the workspace.
4. Choose the mode, e.g. Outside stop means that the robot will stop if the tool exits the
workspace and Save.
17
Origin of
workspace
18
Creating a new Program
A step by step guide to build a program file
1. Select a folder in the navigator menu

2. Select” New” button in lower bar to open a new file, then choose “Modul”, then ok and set a
name for it. As seen by the below figures
A KRL program is made up of a SRC and DAT file.
 The “SRC” file contains the actual program code.

 The “DAT” file, on the other hand, contains the specific program data, such as point
coordinates and variable data.
19
Writing KRL Code
Opening the module that was previously created you can now put in the desired movement commands.
The “src” file by default contains in the first line INI command (initialization) then you can find a PTP
Home command that drives the robot back to the predefined home position.
Motion commands
You can start your first command by pressing on the “commands” button in the lower bar, then go to
motion and you can select different commands as linear, PTP, Circular, etc.… as desired for the
movement required by your application.
Axis-specific motion:
 PTP (point-to-point): The tool is moved along the quickest path to an end point.
Path-related motions
 LIN (Linear): The tool is guided at a defined velocity along a straight line.
 CIRC (Circular): The tool is guided at a defined velocity along a circular path.
3.
2.
1.
20
After selecting your command let’s say PTP motion you need to define the point this is accomplished
by pressing the “Touch up” command in the lower bar. This will teach the point that is defined in this
command the exact coordinates of the position that you placed the kuka in now and then this point is
saved in this command line with a point number e.g. “P1” that is given automatically by the controller
and incremented with every new created point.
When using circular commands we need to teach a starting point and end point by the same procedure
using “Touch up” command if you have saved the desired position confirm the movement command
by pressing “CMD OK” in the lower bar. A step by step guide can be seen in the figure below.
In velocity field, you can enter the value between 0 to 100 percent. For safety reasons: DO NOT
EXCEED 30%.
If you do not select anything in the third field the robot moves exactly to your saved position. By
choosing “CONT” the end point is approximated. In the last field there is the name for motion data
setting. Do not change anything as it is automatically generated.
21
Tool and base selection
Tool and base can be selected for each command in the program (line execution )while programing
by selecting the point then a pop up menu appears from which a tool and base can be selected as seen
in steps in the below figure.
22
Gripper actuation
If you are using inputs and outputs on the KRC for the gripper they must be first defined in
WorkVisual. You then need to define your Gripper in the GripperTech configuration. Please refer to
Mapping inputs and outputs in WorkVisual section.
If the gripper is configured and defined, you may use it by selecting “grippertech” button.
Using the same procedure fist we select the “commands” button The gripper command will
initialized by choosing in the second field “CLO” for closing or “OPN” for opening the
gripper in the “gripper state” bar.
Here it allows us to decide which gripper to choose. From a pre-designed gripper using the
gripper configuration and you can decide its state OPN, or CLO which is the method of
opening or closing the gripper.
In this command we set Gripper no.1 to open with no delay.
23
Mastering of the Axis
For every axis is a resolver that determines where the position of the rotor is relative to the stators zero
cross over point. A resolver is basically an induction motor with three transformer coils: a reference
input and a sine and cosine windings, 90 degrees apart from one another for feedback. Based on the
angle of the motor the sine and cosine output will change and the position of the rotor can be
determined relative to the reference input. However this only determines the position of the stator to
the rotor and not the actual position the robot is in.
Mastering is basically teaching the robot where its axes are. Each axis data is saved in the RDC’s
EPROM memory of robot. During shutdown of the controller each axis location is saved in that
EPROM memory. If a sudden power outage takes place, there are batteries that ensure this data is
saved. When the batteries fail during that time, the robot is unable to save its position and it no longer
knows where it is. This is very bad since the robot will not function properly and may collide with
itself and surroundings. So it is crucial and vital to be carried out regularly.
Mastering is required when:
1. Sudden disconnect of robot and controller.

2. Batteries failure or replacement.
3. Sudden controller or fieldbus failures.
4. Following maintenance work.
5. If robot axes are moved without the controller.
6. Following mechanical repairs/problems.
7. Impact or collision of robot to mechanical end stops, or surrounding.
24
Mastering procedure
Accurate Method
This is done using a dial gauge or an EMD device. Using a dial gauge requires manual approach that
may be unsafe, while the EMD is automated.
 Step 1: In order to master the robot using the EMD you need to locate the EMD tools and
assemble the tools.
1. Micro Electronic Mastering Device (MEMD): This device is used to interface the EMD with
the X32 port.
2. Electronic Mastering Device (EMD): This tool is connected directly to the axis and has a
distance sensor that measures how far the axis is from the Mechanical zero position and sends
the data through MEMD, then through the X32 port and to the controller.
3. X-32 Cable: This cable is an EtherCAT cable that is connected to X32 port and to the MEMD
box.
 Step 2: Jog the robot to the premastering position. This position is located on both the
stationary axis connector and the axis itself with a white line as seen in the figure 4. Both
these lines must be lined up as seen in figure 5. Then remove the protective cap.
25
Figure 7 - premastering position (unaligned)
Figure 8 - Premastering position (Aligned and protective cap removed)
 Step 3: Connect the EMD to the axis and the X32 cable to the base of the robot.
26
 Step 4 (Optional): If the robot is already mastered but wish to re-master it. The axis must be
un-mastered prior to mastering. Select Start-up  Master  Unmaster. Then choose the axis
you wish to unmaster.
27
 Step 5: Select Start-up  Master  EMD  With load correction  First mastering. Note
this must not have a load! If you plan on using a load, the axis must be first mastered then
select load mastering.
 Step 6: If the EMD is in range, select Master. You will be prompted to press the start key.
Hold down the enable switch and press the start key. The robot will automatically move and
locate the master point. Once complete it will exit and prompt you with a mastering complete
message.
28
Inaccurate Method
A primitive, unsafe and inaccurate method can be done using visual inspection; where one person jogs
the robot while another visually locates the robot reference points.
Shutdown or Hibernation
If you switch of the mains power or press the Q1 switch. The robot will hibernate and remain in this
state until the next power cycle. If you wish to shutdown or restart the controller and reload the
configuration files, after a bus failure or error, you may do this by first changing your usergroup to
Expert then select Shutdown from the main menu. You may also configure the power-off delay, so
that the controller does not shutdown instantly so that a running program may be configured so that it
can detect the shutdown or hibernation execution and finalize its work or return the robot to a safe
position before shutdown.
29
Technical Details
KRC4 Compact
As we reported earlier, the controller has two main parts (The control box and drive box):
1. The Control Box:
The control Box consists of three main parts. The first being the low voltage power supply. This is
used to power up all the control unit’s devices that require a low voltage. In addition to that, two
rechargeable batteries ensure a safe shutdown of all components during a sudden power outage.
During shutdown of the controller all the axes’ positions are written in the EPROM memory of the
robot for the next boot. If this saving procedure fails, then remastering will be required the next
time you boot up the controller.
The first component is the windows embedded computer components: consisting of the
motherboard, CPU, RAM, a PCIe dual Ethernet card and an SSD. This runs the windows
operating system that launches a virtual interface between the computer and the second and main
component: the CCU-sr.
The CCU-sr, Cabinet Control Unit (small robot), is the main control unit of robot. All components
are interfaced to the CCU-sr though an EtherCAT connection. Almost all components route to the
CCU-sr, including the windows computer components through the PCIe card (KCB to X31 and
KSB to X41).
Furthermore, an additional component was added to our controller box, which is a Beckhoff
EK1100 EtherCAT Coupler. This adds additional functionality to our controller and include 16
digital inputs and outputs, and a profibus slave.
This is possible due to the following terminals1:
a. EL6731-0010: PROFIBUS slave terminal

b. EL1809: 24V Digital Input terminal
c. EL2809: 24V Digital Output terminal
The three terminal’s connections are routed externally and connected to the ports X12, X15A/B
and X55; while the EtherCAT coupler (EK1100) is wired internally to X44 on the CCU-sr, and
externally to X65.
External interface X55 2is used to power these components. You may apply an external power
source or use X55 as a power source. Pins 7 and 8 are supplied with 24V and 0V, and can handle
up to 10A.
1
Refer to page 25 in “KRC4S_0011023644_SPLINFO.pdf”
2
Refer to figure 6-16 and figure 6-19 in “MA KR C4 compact Interfaces V6.pdf”
30
As an example, interfacing an external input and output with the KRC4 controller. You would
need to power the Bus Coupler (EK1100) by routing a wire from pin 7 to pin 5 (X55) and another
from pin 8 to pin 6 (X55). The next step is to power the infeed terminal (EL9100) that will supply
power to the input (EL1809) and output terminals (EL2809). This is done by bridging another
wire from pin 7 to pin 1 (X55), and from pin 8 to pin 2 (X55).
Now that the modules are powered and functional. You may use the inputs and outputs, and are
connected to X123.
However unfortunately you may not use them just yet, as they are not yet mapped in
WorkVisual to the KRC. This must be done or they will not work in your KRL code.
2. The Drive Box:
This is responsible for providing power to the robots motors. Inside is the KUKA power pack
(KPP-sr). The power pack is interfaced to the CCU-sr. It is connected to a (1.6 KW) ballast
resistor and drives some internal fans. Moreover, it powers the KUKA Servo Pack (KSP-sr).
The KSP-sr is what actually connects the robot’s motors and brakes.
KRC4 Robot
KPP-sr
A1-A6 Motors and Brakes

Windows KSP-sr
Embedded
RDC / RDW
CCU-sr
BECKHOFF
Interfaces
SmartPAD
Figure 9- Basic Interfacing between the KRC and the Robot
3
Refer to figure 6-2 in “MA KR C4 compact Interfaces V6.pdf”
31
KRC4 Compact Topology
KUKA Control Bus (KCB)
 1001: Cabinet Interface Board (CIB-sr)
 1002: KUKA Servo Pack (KSP-sr)
 1003: KUKA Power Pack (KPP-sr)
 1004: Resolver Digital Converter (RDC)
 1005: Electronic Mastering Device (EMD)
 1006: EM8905-1001 I/O Module
Figure 10 - KUKA Control Bus Topology
KUKA Extension Bus (X44)

 1001: EK1100 (Bus coupler)
 1002: EL6731-0010 (PROFIBUS slave terminal)
 1003: EL1809 (24V Digital Input terminal)
 1004: EL2809 (24V Digital Output terminal)
Figure 11 - KUKA Extension Bus Topology
32
Low Voltage
Power Supply
SSD
USB 3.0 connection to CCR-sr
Windows Embedded
Motherboard
CPU PCI-e Lan Card Connecting KCB and

KSB
Figure 12 – Bottom half of the Control Unit’s Internal Hardware (Windows Embedded Mainboard)
33
Robot Interface X21 KUKA Control Bus
(pins 9-12 Data Cable) (KCB)
Connection to
Windows’s KCB connection
to PCI-e card
mainboard USB 3.0
Fuses Connection to drive box KUKA System

(KPP-sr) Bus (KSB) to
PCIe card
KUKA Extension
Bus (KEB)
Connection to
BECKHOFF coupler
Service Interface
(X69)
SmartPAD
interface
Figure 13 - Upper half of the Control Unit’s Internal Hardware: Cabinet control unit (CCU-sr) which consists of the Cabinet interface board
(CIB-sr) and Power management board (PMB-sr)
34
EL9100: 24V
EL6731-0010:
EK1100: Bus Potential supply
PROFIBUS slave
coupler terminal
terminal
Figure 14 - BECKHOFF Module

EL1809: 24V
Digital Input
terminal
EL2809: 24V
Digital Output
terminal
35
WorkVisual
WorkVisual is a program that is used to manage the robot’s projects. The program allows you to:
 Setup your Controller, Robot and External Devices

 Map KRC inputs and outputs
 Transfer projects to and from the controller
 Configure Bus structure and options
 Manage KRL Programs on computer
 *4Online Diagnostics and Program Debugging
Important Initial Setup and Configuration5

After installing the program there are some steps that you must undergo in order to properly be able to
use it. First you need to add the KUKA DTM catalogues.
 Step 1: Click on Search for installed DTMs. Once complete Click the >> Button.
4
Available in WorkVisual 4.0. However, the version is not stable and bugged with our device configuration.
5
All Configuration Files and options can be found using our dropbox links as follows:
https://www.dropbox.com/sh/oud4kjzglurploc/AAANgW55QpSq-6TnK_RbUk6ja?dl=0
36
 Step 2: Next, you need to install the Options that came with the controller. This is only
necessary if the option requires additional configuration in WorkVisual. It is also necessary to
install the options afterwards in the KRC. For our controller we only need the following
options to be configured in WorkVisual: “UserTech”, “ExpertTech” and
“Gripper&SpotTech”. To do so click on Extras  Option Package Management…
 Step 3: Click install. Locate and add the .kop File 6for the option. Repeat for the rest of the
options.
6
37
Step 4: You then need to add the .XML catalogues 7for the Bus coupler and terminals. Click on file 
Import/Export.
 Step 5: Navigate to Import Device Description file. Click next  then Browse
7
38
 Step 6: Change the filter preferences to .xml
39
 Step 7: Install the catalogue. Repeat from step 5 for each one.
 Step 8: Once you installed the xml files you need to install the GSD file for the Profibus. To
do this change the filter to Profibus GSD and choose the appropriate file.
40
Get current project from controller
In order to retrieve a project from the controller you need to first setup an IP to the windows interface
on the controller. You must be in expert mode to perform this.
Network Configuration of Windows interface

It is very important to choose a correct IP address that does not interfere with the EtherCAT busses.
DO NOT ASSIGN THE FOLLOWING IP RANGES
 192.168.0.0 - 192.168.0.255
 172.16.0.0 - 172.16.255.255
 172.17.0.0 - 172.17.255.255
41
 Step 1: Once an IP is assigned, you need may attach a LAN cable or router8 to Interface X66
and connect it to your laptop or computer.
 Step 2: Click on File  Browse for Project
 Step 3: Click on the magnifier icon and select the project you want to retrieve. Our active
project is 2011023644000012000234915.
8
May require further setup
42
Mapping inputs and outputs in WorkVisual
Before any field buses are to be used by the KRC; they must have their inputs and output channels
mapped to the KRC’s inputs and outputs. For example we take a look at the EM8905-1001 that
controls the pneumatic DCV valves present at the head of the robot. This module/field bus consists of
7 input channels and 8 output channels. 6 out of the 8 output channels are wired to the three DCV
Valves located at the head of the robot. Let us proceed to map these outputs that control the DCVs.
This is done inside WorkVisual’s IO Mapping.
1. After you transfer and open the Robots project data, you will get something like this:
2. A) You double click on Steuerung 1 and then on
B) I/O mapping editor
43
3. Once press a new window will open up looking like this
A
4. We now click on the Fieldbusses [A] in the right panel
5. Click on EM8905-1001 I/O Modul [B]
C
B
44
6. Click on Digital Outputs [C]. After that is complete you will see something like this
Mapped devices pane
Valve’s solenoid’s outputs

(DO7-DO12)
Outputs of the KRC…used in

programming grippertech
45
7. In order to map them we do the following:
1. Highlight the Valve’s

2. Highlight the outputs we
outputs
want to assign them and
map them to
3. Click on connect
8. You can see them mapped in the mapped i/o field
46
Once done, you may generate the code and deploy. Finally, we need to define the new gripper in
grippertech’s configuration, from the smartpad or KRC. In our case the gripper is pneumatic of type 1.
This gripper is connected to the first DCV that is mapped at $OUT[1] for actuation and $OUT[2] for
retraction.
1) assign the gripper type, for pneumatic on/off, it is 1

2) for the output ports e.g. 1A and 1B (DO7 and DO10), we assign (in our case Output 1
and Output 4 which were mapped to them)
*Note: If you want to use DO13-14 and DI1-7, (free IOs not connected to DCVs) of the Module to
send and receive data for your programs, you also need to map them first in work visual.
47
Configuring and Mapping BECKHOFF module
The BECKHOFF module has the following bus structure. Make note of the Version numbers.
Mapping Input terminal EL1809

As we did with the gripper mapping we repeat the steps but for the EL1809 module
48
Configuring Profibus Slave
It is possible to use a Profinet device such as a PLC with a Profinet interface to control the KRC.
However in order to do this, you must configure the Profinet slave terminal in WorkVisual and then
configure the interface from the PLC’s side.
You need to configure add the Profibus GSD to the Profibus IO or the Bus coupler as follows:
 Step 1: Add all the catalogues to the project. And select the >> button
49
 Step 2: Due to a bug after retrieving the project, you need to remove the Profibus terminal
from the devices and add it again
After removing it we add the appropriate terminal again
50
Select the terminal and click ok
Add the Profibus configuration file to the IO bus
51
Step 3: After adding it double click on bus configuration
52
Select module configuration
Configure the device based on your application
 *9 Step 4: Once finished map the channel’s configuration to the KRC and configure the
PLC interface. In this case the PLC is master the KRC is the slave.
9
Also check if the X851 interface is switched on from inside the controller.
53
Transferring and activating a project
 Step 1: Compile by clicking the generate code icon
 Step 2: After a successful compilation click the Deploy icon. *Optional: You may activate
the project by clicking the Activate button. You may also Select it manually and activate
it at the KRC side.
54
Projects Management KRC side
To activate or change a project that is located in the KRC. First select the gear icon and choose open
You may then activate, copy and delete projects that are available.
55
JOpenShowVar
Introduction
JOpenShowVar is an open source project that allows for soft real-time direct interfacing to the KRC
written in JAVA. This interfacing allows direct reading of KUKA Variables and writing of Variables
that are not write protected. As an example the System variable for the actual robot position
$POS_ACT is write protected, another is the outputs e.g. $OUT[1] but a workaround 10is present in
order to force the change. The project allows actually does not interface to the controller but rather
creates an interface with a second open source program KUKAVARPROXY, which needs to be
installed on the KRC before operation.
KUKAVARPROXY allows up to 10 clients to connect to it, moreover, it utilizes KUKA’s proprietary

CrossComm API to directly access the variables, and relays the information to JOpenShowVar.
Computer KRC
TCP
JOpenShowVar KUKAVARPROXY
CrossComm API
Figure 15 - JOpenShowVar Interface
In order to do this, JOpenShowVar prepares a TCP packet with the following structure
Legend:
Variable ID
Total Message length
Read or Write (00 Read | 01 Write)
Variable name length
Variable name
Write Data length
Write Data
Figure 16 - TCP Packet Structure
10
*It is important to note that since outputs and inputs are write protected, it is not possible to alter them directly.
It is however possible to create a global Boolean that can set the output during KRL execution.
E.g. $OUT[1]=MYOUT1. In this case MYOUT1 is defined in $config.dat and output 1 will change depending
on this Boolean variable during KRL execution.
56
We used an example by writing a frame variable we called MYPTP, and requested to set the value to
{X 0.0, Y 0.0, Z -250.0, A 0.0, B 0.0, C 0.0}.
As we can see from examining the packet, KUKAVARPROXY requests the structure as seen in figure
11. JOpenShowVar encodes this packet and sends it through the TCP socket. KUKAVARPROXY
decodes the packet. Then proceeds to read the variable and set it.
*Note: We found a non-intrusive bug in the JOpenShowVar that prevents correct setting of the ID,
variable and message lengths.
The bug is caused by incorrect storage of the most significant byte of these values. In order to correct
this, the lines with the following structure for the ID, variable and message length:
(byte) ((*.length >> 8) & 0xff00); e.g. (byte) ((cmd.length >> 8) & 0xff00);
This should be replaced by :
(byte) ((*.length & 0xFF00) >> 8); e.g. (byte) ((cmd.length & 0xFF00) >> 8);
The bug effectively prevents the MSB to be set and will always be zero. However, this is only critical
for lengths greater than 0xFF (255). If not corrected anything with value or length greater than 0xFF
will cause an overflow and cause KUKAVARPROXY to incorrectly decode it.
However, as I said earlier this is non-intrusive as it is very rare to have a length of 0xFF.
Setup
JOpenShowVar’s API contains the CrossComClient Object. This establishes a connection to the
KUKAVARPROXY program in the KRC. Therefore, it is necessary to have the KUKAVARPROXY
installed and opened when running your program. The can be done by first minimizing the KRC HMI.
You must be in the Expert UserGroup.
57
Save the file on the desktop and open it.
Figure 17 - KUKAVARPROXY Interface
58
Also it is vital to ensure that port 7000 is also open on the KRC, as this is the port the
KUKAVARPROXY listens to.
59
JOpenShowVar’s API
The API consists of the following packages and classes
In the main package no.hails.crosscom we examine the class CrossComClient.
The constructor method requests a String with the

host address and a port. The host is the IP address
of the windows interface in the KRC controller and
the port is usually 7000. In our application, the host
address was “169.169.169.169” and the port was
7000.
This method allows you to easily read and write

variables using the simpleRead( ) and
simpleWrite( ) methods. And both return a string
object.
E.g. simpleRead(“$OV_JOG”) which requests

reading of the jog speed system variable.
60
We next examine the abstract class KRLVariable.
This abstract class is implemented in all the

classes of the classes of the packages
no.hails.crosscom.KRL and
no.hails.crosscom.structs.
All variables contain an ID that is set

automatically when the construct is called. The
constructor requires a String with the name of the
variable.
E.g. new KRLBool(“POINTREACHED”). In this
example we instantiate a new KRLBool variable
object which has the name “POINTREACHED”
in the KRC controller.
If I would like to request the value of the Boolean

variable, I will not update it from this class but
rather I will pass the variable to the
CrossComClient object’s readVariable( ) method.
E.g. CrossComClient cl=new

CrossComClient(“169.169.169.169”,7000);
KRLBool pr=new
KRLBool(“POINTREACHED”);
cl.readVariable(pr);
Note that we update the variable we can display

the value by calling the method getValue().
System.out.println(pr.getValue());
*Note that the type and sampling period are not part of the class, but rather was added by us to
identify the type of the variable and set a sampling period to read the variable.
*It is important to note that since outputs and inputs are write protected, it is not possible to alter them
directly. It is however possible to create a global Boolean that can set the output during KRL
execution. E.g. $OUT[1]=MYOUT1. In this case MYOUT1 is defined in $config.dat and output 1 will
change depending on this Boolean variable during KRL execution.
**Note that the KRLBool POINTREACHED is not a default system variable, but rather is a global
variable we added to the KRC by configuring the $config.dat file.
61
Configuring KRC global variables
This is done by configuring the $config.dat file located in the KRC and is found in KRCSTEU
folder.
*Do not configure the file $config.dat found in R1System folder.
E.g. We define a BOOL variable POINTREACHED and a FRAME MYPTP. These variables are now
global variables. We can call them from any program in the KRC and more importantly from
KUKAVARPOXY.
62
Interfacing JOpenShowVar with MatLAB
We were able to communicate with MatLAB from JOpenShowVar by creating a shared XML file that
allows both MatLAB and JOpenShowVar to read and write from the file. As an application, we had a
setup that detected motion around the robot. If a person or object is detected around the robot, the
robot will override its speed and reduce it until the person or object leaves the area.
We added a webcam and created regions of interest around the robot, that were our set points for
detecting the motion. Image processing was done on MatLAB, if detection occurs, the XML file was
opened, the motionDetected variable was changed and the file was saved. Upon saving the file, our
program will detect a file change had occurred; it will then proceed to open the file and read the
altered variable. JOpenShowVar will relay and send the override command to the KRC and reduce the
speed.
When the person leaves the region, after 5 seconds the speed returns to normal.
Figure 18 - Flowchart MatLAB interfacing (MatLAB Side)
63
Figure 19 - Flowchart MatLAB Interfacing (Java Side)
64
GJU-KUKA Toolkit
Requirements
In order to further develop the toolkit and use the image processing tools you need to install OpenCV
and configure NetBeans IDE to use the java libraries in OpenCV.
In our application, we used the build OpenCV 3.1.0. The setup may be found on OpenCV’s website.
After installation, we need to add the java libraries to the project and configure the IDE to use the
library. This is because OpenCV is written in C++ and compilation depends on the operating system
rather than a virtual machine. This means that we must use the Java Native Interface in order to
execute native code.
In order to do this you need to perform the following steps:
 Step 1: Right click the project and click on properties.
65
 Step 2: Click on Libraries  Add JAR/Folder
 Step 3: Navigate to the OpenCV’s installation folder and locate the opencv-310.jar file. In
my case it was located in *\opencv\build\java directory.
Replace the * with the directory to the opencv installation folder.
 Step 4: After adding the library, go to the Run Tab and add the VM option, depending on
your OS. Replace the * with the directory to the opencv installation folder.
For x64: -Djava.library.path="*\opencv\build\java\x64"

For x86: -Djava.library.path="*\opencv\build\java\x86”
 Step 5: For every project you create and wish to integrate OpenCV with, you must load
the library into the JVM system, by calling following method in the main class
66
Basic Outlook on OpenCV
When developing with OpenCV always check the Javadoc for the libraries. This may be found at
http://docs.opencv.org/java/3.1.0/ .
To start we examine the structure of images. Usually an image is a large matrix of pixels where each
pixel in the matrix has an RGB value. Of course, this is not always the case since sometimes you have
a greyscale image that has a single colour Black but each pixel has a different level of intensity or
saturation of that colour. You could also have images that is just zeros and ones called a Bitmask, or
instead of RGB values, you might use HSV values or even chromatic colours.
OpenCV allows you to define the matrix by using a Mat() object. This object can be assigned the
appropriate type from a preconfigured list of types by calling the CvType class and choosing one.
Lets take as an example CV_16SC3. This defines the image as a 16-bit pixel values that are signed
(Range from -32,768 to 32,767) of type integer. The image also has 3 Channels. Channels are arrays in
each pixel that defines the values of the colours. Basically like a sub container. In this case it is RGB.
But note that OpenCV by default does not save it in that order but rather as BGR.
P0 P1 P2 B0G0R0 B1G1R1 B2G2R2

P3 P4 P5  expand the pixel and you get for a 3 channel matrix  B3G3R3 B4G4R4 B5G5R5
P6 P7 P8 B6G6R6 B7G7R7 B8G8R8
E.g. Mat image3 = new Mat(new Size(640,480), CvType.CV_8UC3);
This defines a new matrix with 640 pixels of width and 480 pixels of height and an 8 bit unsigned
integer with color: blue green and red channels
67
Data Logging Tool
The Data Logging Tool allows sampling of variables at a set sampling period. It also allows
monitoring of these variables directly on an external computer. It is also possible to add read time
corrections, to take into account the read time latency.
Figure 20 - Data Logging Tool Interface
68
If a connection is established the table values are updated every second. When start is pressed and
connection is present, logging starts a timer and begins polling the variables at the period of which it is
set at. When stop is pressed polling stops and a save directory window opens to allow you to save the
log files to your directory of choice. Each variable is saved in a separate log file.
Figure 21 - Flow Chart for Data Logging Tool
69
E.g. of two log files. The first of the actual position sampled and the second of the program override
speed; both set to sample every 1000ms.
-------------------------------------------------
24/01/2017 10:56:27 Variable: KRLE6Axis $POS_ACT
-------------------------------------------------
SampleTime: 14; Value: {A=-122.532265, B=-1.24790311, C=-178.577469, E1=0.0, E2=0.0, E3=0.0,

E4=0.0, A1=0.0, E5=0.0, A2=0.0, E6=0.0, A3=0.0, A4=0.0, S=6.0, A5=0.0, T=51.0, A6=0.0,
X=601.608398, Y=72.6076813, Z=246.587433}; ReadTime: 6
SampleTime: 1014; Value: {A=-122.532265, B=-1.24790311, C=-178.577469, E1=0.0, E2=0.0,

E3=0.0, E4=0.0, A1=0.0, E5=0.0, A2=0.0, E6=0.0, A3=0.0, A4=0.0, S=6.0, A5=0.0, T=51.0, A6=0.0,
X=601.608398, Y=72.6076813, Z=246.587433}; ReadTime: 6

E3=0.0, E4=0.0, A1=0.0, E5=0.0, A2=0.0, E6=0.0, A3=0.0, A4=0.0, S=6.0, A5=0.0, T=51.0, A6=0.0,
X=601.608398, Y=72.6076813, Z=246.587433}; ReadTime: 6

E3=0.0, E4=0.0, A1=0.0, E5=0.0, A2=0.0, E6=0.0, A3=0.0, A4=0.0, S=6.0, A5=0.0, T=51.0, A6=0.0,
X=601.608398, Y=72.6076813, Z=246.587433}; ReadTime: 6

E3=0.0, E4=0.0, A1=0.0, E5=0.0, A2=0.0, E6=0.0, A3=0.0, A4=0.0, S=6.0, A5=0.0, T=51.0, A6=0.0,
X=601.608398, Y=72.6076813, Z=246.587433}; ReadTime: 7
-------------------------------------------------
24/01/2017 10:56:27 Variable: KRLInt $OV_PRO
-------------------------------------------------
SampleTime: 37; Value: 100; ReadTime: 7
70
Drawing Tool
For demonstration purposes, we created a drawing tool that allows you to upload an image and the
robot will attempt to replicate drawing it.
In order to perform this we included image-processing tools that allow you to adjust many aspects of
the image in order to find an optimal setting for drawing the picture.
Figure 22 - Drawing Tool Interface
71
Figure 23 - Flow Chart for Drawing Tool
72
KRC side Program
DEF DrawingProgram( )
INI
PTP StartPosition Vel=40 % PDAT3 Tool[1]:pen Base[1]:drawingBase
$ADVANCE=0 ;Set Advance pointer to 0
LOOP
PTP MYPTP ;Defined in $config.dat as FRAME

POINTREACHED = TRUE ;Defined in $config.dat as BOOL
ENDLOOP
END
In the program above, we defined a point known as StartPosition. The start position is configured to
move at a speed of 40%, in addition to that the tool and base are configured to a pre-calibrated
position of the TCP (pen) and the base (drawingBase). MYPTP is a frame. If StartPosition is not
execute first. The program will not run since the frame inherits the last values of previous position and
sets it’s S, R and remaining orientation values (In this case from StartPosition).
Ensure that the Base and TCP are configured and calibrated correctly before running. Moreover, add
WorkspaceMonitoring and CollisionDetection to the points!
Figure 24 - Example of Final Drawing
73
KUKA virtual cage
Since the KUKA robot runs at very high speeds and is capable of causing severe harm or damage if it
collides with people or objects surrounding it. This concerns us since the robot is moved around and
demoed quite frequently, a safety precaution must be implemented. While safety gates and light
curtains are often used, they unfortunately unsuitable for our applications, since it is constantly being
moved. To solve this we decided to use an Arduino that is connected to multiple Ultrasonic sensors
that frequently scan for objects around the table where the KUKA is situated.
System block diagram and hardware used
Figure 25 - Hardware Diagram for Virtual Cage
 Dual Latching Relays – type Yw-robot 2

 18 Ultrasonic sensors – type Hc-sr04
 Arduino Mega – type ATmega2560
 Bluetooth module – type HC-05 (ZS-040)
74
Software
First when the system is powered, initialization takes place. If it fails, or an object is detect a fault is
registered and the relays remain open. The relays are normally open and will be connected to an input
of the KUKA in addition to being connected to the Dual Channel ESTOP.
During normal operation, the normally open relays will latch and the E-Stops safety relays will be
closed. Allowing the robot to operate.
If an object is detected coming close to the robot, an interrupt is signaled and the $OV_PRO system
variable is reduced to 20%. This is the variable that is responsible for the speed limit of the KUKA. In
addition to that an alarm is sounded. If for any case the object or person continues approaching the
table, then the second relay connected to the dual channel E-Stop will delatch and the robot will stop
until it is reset.
Figure 26 - Flow Chart for Virtual Cage
75
Detection angles, blind spots and ranges of the safety cage
Overall:
Front sensors:
76
Side and back sensors:
77
Simple gripper design
The gripper currently attached to the robot, has limited opening distance of 3mm. This not ideal for
our applications, since the robot does not have a camera attached, any slight change in the objects
surroundings will cause the robot to collide with the objects. In order to prevent that a larger gripper
must be designed.
Using a simple pneumatic cylinder and a four bar linkage design we were able to create a simple
gripper that can open and close up to 50 mm. Compared to the original 3 mm this is much more
suitable. However ultimately the cylinder is only capable for holding loads of up to 1.5 kg, we rated it
only for moving objects weighing under 1 kg. In addition to that, all calculated and measured static
loads identified in the next page are under a maximum load of 1 kg.
Figure 27 - Gripper front view (closed)
78
Figure 28 - Gripper with filleting front view (closed)
Figure 29 - Gripper front view (opened)
79
Von-mises stress simulations under static load of 1 kg
80
81
Appendix A1 – MATLab code for Motion Detection
% Author: Sahba El- Shawa

% Last modified: 23/8/2016
%
% This program detects motion using a webcam and notifies user when motion
% occurs and when it stops. It is to be used in conjunction with an
% OpenShowVar program that reads the output in the xml file and adjusts the
% speed value of a KUKA industrial robot arm when motion is detected in any
% of the defined regions of interest.
%Initialize program and webcam

clc;
clear;
close all;
cam = webcam
cam.Resolution = '640x480'
preview(cam)
%Save a baseline image and crop into 4 ROIs

BImage=rgb2gray(snapshot(cam));
IB1 = imcrop(BImage, [1 1 100 480]); %Baseline image, Region 1
IB2 = imcrop(BImage, [100 1 440 100]);
IB3 = imcrop(BImage, [540 1 100 480]);
IB4 = imcrop(BImage, [100 380 440 100]);
%Initialize infinite loop

while(1)
%Initialize SAD total values to allow for upcoming iterations

I1total=0; %Total sum of absolute differences for Region 1
I2total=0;
I3total=0;
I4total=0;
%Initialize output xml file

fileID =
fopen('C:\Users\lab008\Documents\NetBeansProjects\JOpenShowVar-
core\res\matlab.xml','w');
%Initialize boolean variable in O/P file as False
fprintf(fileID,'%s\n','<root><cameraData motionDetected="False" /> </root>');
fclose(fileID);
for(i=1:1:3)
%Initialize images for comparison

Image1 = rgb2gray(snapshot(cam)); %First frame
Image2 = rgb2gray(snapshot(cam)); %Second frame
82
%Crop images into 4 regions of interest along borders
I11 = imcrop(Image1, [1 1 100 480]); %Image 1, region 1
I12 = imcrop(Image1, [100 1 440 100]);
I13 = imcrop(Image1, [540 1 100 480]);
I14 = imcrop(Image1, [100 380 440 100]);

I22 = imcrop(Image2, [100 1 440 100]);
I23 = imcrop(Image2, [540 1 100 480]);
I24 = imcrop(Image2, [100 380 440 100]);
%Calculate sum of absolute differences of ROIs
I1SAD=sum(sum(abs(I21-I11))); %SAD of Region 1

I2SAD=sum(sum(abs(I22-I12)));
%Add calculated SAD to total values

I1total=I1total+I1SAD;
end
%Average total SAD values by number of loop iterations

I1avg=I1total/3;
I2avg=I2total/3;
I3avg=I3total/3;
I4avg=I4total/3;
%Check if SAD avgs are above defined threshold in any region

if(floor(log10(I1avg))>4)||(floor(log10(I2avg))>4)||...
(floor(log10(I3avg))>4)||(floor(log10(I4avg))>4)
%Display message and change variable in O/P file to True

display('Motion detected');
fileID = fopen('C:\Users\lap008\Documents\NetBeansProjects\JOpenShowVar-
core\res\matlab.xml','w');
fprintf(fileID,'%s\n','<root><cameraData motionDetected="True" />
</root>');
fclose(fileID);
%Define motion flag as true

motionDetected = true;
%Compare new frames to baseline image to detect end of motion

while(motionDetected==true)
display('Comparing to base image');
83
Image2 = rgb2gray(snapshot(cam));
I22 = imcrop(Image2, [100 1 440 100]);
I23 = imcrop(Image2, [540 1 100 480]);
I24 = imcrop(Image2, [100 380 440 100]);
I1SAD=sum(sum(abs(I21-IB1))); %SAD for region 1

I2SAD=sum(sum(abs(I22-IB2)));
%Check whether SAD values for all regions are below threshold
if(floor(log10(I1SAD))<4)&&(floor(log10(I2SAD))<4)&&...
(floor(log10(I3SAD))<4)&&(floor(log10(I4SAD))<4)
%Change motion flag to false
motionDetected = false;
end
end
else
%Display loading message if no motion was detected
display('...')
end
end
84
Appendix A2 – Java code for Motion Detection
85
86
87
88
89
90
91
92
Appendix B – GJU-KUKA Toolkit
93
94
95
96
97
98
99
100
101
102
103
104
105
107
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
Appendix C - Example KRL code done by Faris Qutaishat and Al-Bara
Abu Shaqra
1 DECL INT Value

2 INI
3 Value = 1
4 WHILE Value< 4
5
6
7 PTP HOME Vel= 30 % DEFAULT
8
9 PTP P1 CONT Vel=30 % PDAT1 Tool[1]:tool1 Base[0]
13 LIN P5 CONT Vel=0.5 m/sCPDAT1 Tool[1]:tool1 Base[0:
14
15 SYN OUT 7 '' State=FALSE PATH=0 mm Delay=50 ms
16 WAIT Time=1 sec
17 SET GRP 1 State=CLO CONT at START Delay=200 ms
18 LIN P6 CONT Vel=0.5 m/sCPDAT2 Tool[1]:tool1 Base[0]
22 WAIT Time=1 sec
23
24 SET GRP 1 State=OPN CONT at START Delay=200 ms
25 LIN P12 CONT Vel=0.5 mts CPDAT7 Tool[1]:tool1 Base[0]
29
30
31 SET GRP 1 State=CLO CONT at START Delay=200 ms
37 WAIT Time=0.5 sec
38 SET GRP 1 State=OPN CONT at START Delay=200 ms
39 WAIT Time=0.5 sec
41
42 SYN OUT 7 ' ' State=TRUE at START Delay=200 ms
43
44 Value = Value+1
45 ENDWHILE
46 PTP HOME Vel= 30 % DEFAULT
122
Appendix D - Arduino Code for the Virtual Virtual Cage
// ---------------------------------------------------------------------------
// KUKA Virtual Cage//v0.4//24.12.2016//
// ---------------------------------------------------------------------------
#include <avr/wdt.h> //Watchdog libary
// ---------------------------------------------------------------------------
// Assign Number of sonars, and the number of itterations you need for processing here
// ---------------------------------------------------------------------------
const uint8_t SONARS = 7; // Number of sensors.
const uint8_t sigItterations = 3; // Itterations for signal processing
const uint32_t CriticalDistance = 10; // Signal constant alarm at 10 cm or less
// ---------------------------------------------------------------------------
// Assign range, trigger and echo pins here
// ---------------------------------------------------------------------------
volatile uint16_t RANGE = 200; // RANGE (in cm) to ping.
volatile uint8_t TRIGGER_PIN[SONARS] = {3, 3, 3, 3, 3, 3, 3}; // TRIGGER PINS
volatile uint8_t ECHO_PIN[SONARS] = {5, 6, 7, 8, 9, 10, 11}; // ECHO PINS
volatile uint8_t TRIGGER_DETECTPIN = 45; // Test if Trigger works
// ---------------------------------------------------------------------------
// Global Variables used in code
// ---------------------------------------------------------------------------
volatile uint32_t initi = 0; // Initilization counter
volatile uint32_t dis[SONARS]; // Ping distances array
volatile uint32_t value[sigItterations][SONARS]; // Value array to average out the readings
itterations/ SIGNAL PROCESSING
volatile uint32_t avgTotal; // Sum of the last 4 average readings of the sensors and
adds the new value
volatile uint32_t avg[SONARS]; // Avg of the readings
volatile uint32_t duration; // Time between triggering and recieving an echo [us]
volatile unsigned long maxTime; // Max time[ms] to try to ping a sensor(based on
distance)
volatile unsigned long pulseTime; // Time to wait if a timeout occours
// ---------------------------------------------------------------------------
// Global Variables used in code
// ---------------------------------------------------------------------------
volatile bool initiComplete = 0; // Initialization complete FLAG
volatile bool inspectSensor[SONARS]; // Used to signal Sensor error or warning
volatile byte startSendingData; // Start sending data to bluetooth
volatile word sensorFailure[SONARS]; // Used to detect if a sensor has failed
volatile byte triggerFailure[SONARS]; //Detect triggerFailure
//==================================================================
// Restart Arduino code
//==================================================================
void RestartArduino() {
wdt_enable(WDTO_15MS); // Enable watchdog

while (1) {} // loop until watchdog overflows
123
//==================================================================
//==================================================================
// Initialization code
//==================================================================
void setup() {
Serial.begin(250000); //Set baud rate
Serial3.begin(9600); //Set Bluetooth Baud Rate
maxTime = ((long)RANGE*90); //MAXTIME IN microsec [approximately 1.5* max time
for travel]
pulseTime=((400*60)-maxTime); //If timeout occurs wait for the full time of the pulse(4m)
pinMode(TRIGGER_DETECTPIN, INPUT); //Trigger detection
pinMode(51, OUTPUT); //Relay pin
for (uint8_t i = 0; i < SONARS; i++) {

pinMode(TRIGGER_PIN[i], OUTPUT); //Defines pin modes as input/output
pinMode(ECHO_PIN[i], INPUT);
}
}
//==================================================================
//==================================================================
// Ping Sensor and return distance [cm]
//==================================================================
uint32_t pingSensor(uint8_t Sensor) {
bool triggerFunctional = LOW;

wdt_enable(WDTO_120MS); // ENABLE WATCHDOG [120MS]
digitalWrite(TRIGGER_PIN[Sensor], LOW); // Prepare Trigger pin

delayMicroseconds(10);
digitalWrite(TRIGGER_PIN[Sensor], HIGH); // Set Trigger pin HIGH
if (digitalRead(TRIGGER_DETECTPIN)) { // TEST TRIGGER [requires 16 us]

triggerFunctional = HIGH;
}
digitalWrite(TRIGGER_PIN[Sensor], LOW); // Set Trigger pin LOW [total time on 20us]
if (triggerFunctional) {
duration = pulseIn( ECHO_PIN[Sensor], HIGH, maxTime); // WAIT TO RECIEVE ECHO
if (!duration) { // IF IT FAILS, might be echo pin fault.
delayMicroseconds(pulseTime);
pinMode(ECHO_PIN[Sensor], OUTPUT);
digitalWrite(ECHO_PIN[Sensor], LOW); // Restart echo pin
pinMode(ECHO_PIN[Sensor], INPUT);
return (0); // RETURN FALSE
}
triggerFailure[Sensor] = 0x00; // Reset triggerFailure
}
else {
124
triggerFailure[Sensor]++; // Increment triggerFailure of that Sensor
return (0);
}
wdt_disable(); // DISABLE WATCHDOG
return (duration / 60); // RETURN DISTANCE
}
//==================================================================
//==================================================================
// Main Loop
//==================================================================
void loop() {
bool far = false;

bool near = false;
bool veryNear = false;
bool criticalDistanceBreached = false;
for (uint8_t i = 0 ; i < SONARS ; i++) { //PING SENSORS AND STORE IN DIS ARRAY
dis[i] = pingSensor(i);
if (dis[i] < RANGE && dis[i] > 6 ) {

if (dis[i] < CriticalDistance) {
digitalWrite(51, HIGH); //dont wait to loop over all sensors...sound alarm even if incorrect
reading
criticalDistanceBreached = true;
}
}
}
//-------------------------DATA PROCESSING-------------------------//

if (dis[i] < RANGE && dis[i] > 6 ) { //MAX and Min Range not exceeded
uint32_t temp = dis[i];
for (uint8_t j = sigItterations; j > 0; j--) { //Error Processing, Averaging Method Started
value[j][i] = value[j - 1][i];
}
value[0][i] = temp;
for (uint8_t k = 0; k < sigItterations; k++) {
avgTotal = avgTotal + value[k][i];
}
avg[i] = avgTotal / sigItterations;
sensorFailure[i] = 0x0000;
avgTotal = 0;
}
else {
if (avg[i] < RANGE) {
avg[i] += 15; // ADD drift if now value is returned, we assume out of
range and begin to drift it back to maxRange
}
125
if (avg[i] >= RANGE) {
sensorFailure[i] += 0x0001;
if (sensorFailure[i] > 0x0100) {
inspectSensor[i] = HIGH;
}
}
if (inspectSensor[i]) {
Serial.print("INSPECT SENSOR");
Serial.print(inspectSensor[i]);
}
}
if (initiComplete) { //DISPLAY DATA

Serial.print(i);
Serial.print(" ");
Serial.print(avg[i]);
Serial.print(" ");
Serial.print(dis[i]);
Serial.print(" ");
Serial.print(sensorFailure[i]);
Serial.println();
}
}
//-------------------------DATA PROCESSING - ENDED-------------------------//
//-------------------------BLUETOOTH COMMUNICATION-------------------------//
while (Serial3.available()) {
wdt_disable();
uint8_t temp = Serial3.read();
if (temp == 'S') {
Serial3.println("Restarting!");
Serial.println("Restarting!");
RestartArduino();
}
else if (temp == 'R') {
Serial3.print("SENSOR ");
Serial3.print(i);
Serial3.print(" ");
Serial3.println(avg[i]);
}
}
else if (temp == 'M') {
startSendingData = 0xFF;
}
else if (temp == 'P') {
startSendingData = 0;
}
Serial3.flush();
}
126
if (startSendingData != LOW) {
Serial3.print("SENSOR ");
Serial3.print(i);
Serial3.print(" ");
Serial3.println(avg[i]);
}
Serial3.flush();
}
//-------------------------BLUETOOTH COMMUNICATION - ENDED-------------------------//
//-------------------------INITIALIZING DATA-------------------------//
//Start building data for processing
if (!initiComplete) {
initi++;
if (initi == 10) {
Serial.print("Initializing!");
Serial.println();
}
if (initi > 40) {
initiComplete = true;
Serial.print("Initializing complete!");
Serial.println();
}
}
//-------------------------END INITIALIZATION-------------------------//
if (initiComplete) {
wdt_disable();
int minDelay = 0;
for (int i = 0; i < SONARS; i++) {
if (avg[i] <= CriticalDistance || criticalDistanceBreached) {
far = true;
near = true;
veryNear = true;
break;
} else if (avg[i] <= 40 && avg[i] > 10) {
far = true;
near = true;
minDelay = avg[i];
} else if (avg[i] < 45 && avg[i] > 40) {
far = true;
minDelay = avg[i];
}
}
if (far && !near && !veryNear) {

digitalWrite(51, HIGH);
delay(minDelay + 5);
digitalWrite(51, LOW);
127
delay((minDelay + 10));
} else if (far && near && !veryNear) {
delay(minDelay);
delay(minDelay - 11);
} else if (far && near && veryNear) {
delay(1000);
}
else {
}
}
}
//==================================================================
128
Appendix E – Gripper Dimensions
*Note that the Scale indicated is not actually 1:1 since these are images that have been downscaled to
fit in this document. However the Dimensions labelled are correct and are all in mm.
129
130
131
132
133
List of important figures
Figure 1- KUKA KR Sixx R900 robot .................................................................................................... 5

Figure 2 - KRC4 Compact segments ....................................................................................................... 8
Figure 3 - SmartPad Interface.................................................................................................................. 9
Figure 4- Base Calibration (After rotation around A and C) ................................................................. 15
Figure 5- Base Calibration (Translation) ............................................................................................... 16
Figure 6- Final drawingBase Coordinate System after translation and rotation.................................... 16
Figure 7 - premastering position (unaligned) ........................................................................................ 26
Figure 8 - Premastering position (Aligned and protective cap removed) .............................................. 26
Figure 9- Basic Interfacing between the KRC and the Robot ............................................................... 31
Figure 13 - KUKA Control Bus Topology ............................................................................................ 32
Figure 14 - KUKA Extension Bus Topology ........................................................................................ 32
Figure 10 – Bottom half of the Control Unit’s Internal Hardware (Windows Embedded Mainboard). 33
Figure 11 - Upper half of the Control Unit’s Internal Hardware: Cabinet control unit (CCU-sr) which
consists of the Cabinet interface board (CIB-sr) and Power management board (PMB-sr).................. 34
Figure 12 - BECKHOFF Module .......................................................................................................... 35
Figure 15 - JOpenShowVar Interface .................................................................................................... 56
Figure 16 - TCP Packet Structure .......................................................................................................... 56
Figure 17 - KUKAVARPROXY Interface ............................................................................................ 58
Figure 18 - Flowchart MatLAB interfacing (MatLAB Side) ................................................................ 63
Figure 19 - Flowchart MatLAB Interfacing (Java Side) ....................................................................... 64
Figure 20 - Data Logging Tool Interface............................................................................................... 68
Figure 21 - Flow Chart for Data Logging Tool ..................................................................................... 69
Figure 22 - Drawing Tool Interface....................................................................................................... 71
Figure 23 - Flow Chart for Drawing Tool ............................................................................................. 72
Figure 24 - Example of Final Drawing.................................................................................................. 73
Figure 25 - Hardware Diagram for Virtual Cage .................................................................................. 74
Figure 26 - Flow Chart for Virtual Cage ............................................................................................... 75
Figure 27 - Gripper front view (closed)................................................................................................. 78
Figure 28 - Gripper with filleting front view (closed) ........................................................................... 79
Figure 29 - Gripper front view (opened) ............................................................................................... 79
134
References
1. KUKA-GmbH. (2003). Expert Programming KUKA System Software (KSS) Release 5.2.
KUKA-GmbH.
2. Robots. (2013). KR AGILUS sixx with W and C Variants Assembly Instructions. MA KR

AGILUS sixx V11. KUKA Roboter GmbH.
3. KUKA Roboter GmbH. (2014). KR C4 compact. Assembly Instructions. Version: MA KR C4

compact V4. KUKA Roboter GmbH.
4. KUKA System Technology. (2014). WorkVisual 3.1. Version: KST WorkVisual 3.1 V2.
KUKA Roboter GmbH.
5. Controller Option. (2014). Optional Interfaces for KR C4 compact Assembly and Operating
Instructions. Version: Version: MA KR C4 compact Interfaces V5. KUKA Roboter GmbH.
6. Qutaishat, Abu Shaqra. (2016). KUKA KR6 R900: Robotic Arm Configurations for
Pharmaceutical Industry and Research Applications. German-Jordanian University.
7. Sahba El- Shawa, Laith Salameen (2016). Vision-based Safety System for KUKA Industrial
Robot. German-Jordanian University.
135

KUKA GradProj Laith Salameen 2017

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KUKA GradProj Laith Salameen 2017

Uploaded by

Copyright:

Available Formats

KUKA Systems and Applications Design

Department of Mechatronics Engineering,

Advisor: Dr. Nathir Al-Rawashdeh

CCU_SR: Cabinet Control Unit Small Robot

CIB_SR: Cabinet Interface Board Small Robot

EMD: Electronic Mastering Device

KCB: KUKA Controller Bus

KEB: KUKA Extension Bus

KPP_SR: KUKA Power Pack Small Robot

KRL: KUKA Robot Language

KSB: KUKA System Bus.

KSP_SR: KUKA Servo Pack Small Robot

KSS: KUKA System Software

Manipulator: KR6 R900 Robot

PMB_SR: Power Management Board Small Robot

RDC: Resolver Digital Converter

 Robot: KUKA KR Sixx R900

Figure 1- KUKA KR Sixx R900 robot

The industrial robot consists of the following components:

 Robot mechanical unit

1. X11 is properly connected and functional

DO NOT ASSIGN THE FOLLOWING IP RANGES to the windows interface

The KRC4 Compact has two parts:

1. Control Unit (The upper half of the KRC4)

Figure 2 - KRC4 Compact segments

External Connections of KRC4 Compact

1. X11 - Safety interface

 X12 - INPUT/OUTPUT pins

Figure 3 - SmartPad Interface

KRC Operating Modes

The main three user groups are:

Changing jogging coordinate system

Figure 4- Base Calibration (After rotation around A and C)

Figure 5- Base Calibration (Translation)

Figure 6- Final drawingBase Coordinate System after translation and rotation

1. Select a folder in the navigator menu

A KRL program is made up of a SRC and DAT file.

 The “SRC” file contains the actual program code.

In this command we set Gripper no.1 to open with no delay.

Mastering is required when:

1. Sudden disconnect of robot and controller.

Figure 8 - Premastering position (Aligned and protective cap removed)

1. The Control Box:

This is possible due to the following terminals1:

a. EL6731-0010: PROFIBUS slave terminal

2. The Drive Box:

A1-A6 Motors and Brakes

Figure 9- Basic Interfacing between the KRC and the Robot

Figure 10 - KUKA Control Bus Topology

KUKA Extension Bus (X44)

Figure 11 - KUKA Extension Bus Topology

USB 3.0 connection to CCR-sr

CPU PCI-e Lan Card Connecting KCB and

Fuses Connection to drive box KUKA System

Figure 14 - BECKHOFF Module

 Setup your Controller, Robot and External Devices

Important Initial Setup and Configuration5

Network Configuration of Windows interface

DO NOT ASSIGN THE FOLLOWING IP RANGES

 Step 2: Click on File  Browse for Project

This is done inside WorkVisual’s IO Mapping.

4. We now click on the Fieldbusses [A] in the right panel

5. Click on EM8905-1001 I/O Modul [B]

Mapped devices pane