• No results found

Application and Control of Robotic Manipulator through PLC

N/A
N/A
Protected

Academic year: 2022

Share "Application and Control of Robotic Manipulator through PLC"

Copied!
67
0
0

Loading.... (view fulltext now)

Full text

(1)

Application and Control of Robotic Manipulator through PLC

Fredmer Andreas

Högskoleingenjör, Maskinteknik 2017

Luleå tekniska universitet

Institutionen för teknikvetenskap och matematik

(2)

Abstract

This thesis analyses the background of the kinematics and control of an articulated robotic arm in order to control it’s motor controllers with a custom controller using PLC programming.

The goal was to create a MATLAB simulation of a manipulator and then establish a working configuration. This would then later be used by the division of Signals and Systems at LTU to educate students in PLC programming for autonomous setups with the robotic manipulator.

The thesis was successful following the schedule established at the beginning and most of the objectives were accomplished. The results were a functioning control framework of Siemens PLC that could control the manipulators motor controllers to preform pick and place tasks in conjunction with a conveyor belt.

(3)

Preface

Thesis was performed at the Lule˚a University of Technology within the Department of Computer Science, Electrical and Space Engineering under the Division of Signals and Systems, at Campus Lule˚a in Lule˚a.

The supervision was carried out by Professor George Nikolakopoulos and Senior Re- search Engineer Dariusz Kominiak at the division of Signals and Systems, LTU.

I would like to thank the following for their contribution and assistance during this thesis:

George Nikolakopoulos - Professor LTU

Dariusz Kominiak - Senior Research Engineer LTU Christoforos Kanellakis - PhD LTU

Jerker Bergstr¨om - Student LTU

Christian Meyer - Commonplace Robotics Christian Schlosser - HMS Industrial Networks

(4)

Abbreviation List

R (Revolute) Rotating joint

P (Prismatic) Linear motion joint between 2 links

End-effector Typically a tool at the end of an manipulator

DOF . . . Degrees of Freedom describes the flexibility of the robotic motion T . . . Transformation matrix

Rot (R) . . . . Rotation matrix T rans . . . Transformation matrix S . . . Skew symmetric matrix v . . . Linear velocity

ω . . . Angular velocity J . . . The Jacobian

q . . . Joint angle configuration q . . . .˙ Joints angular velocity

on. . . Distance between end-effector and reference point n zn. . . Coordinate system at the reference n

ai . . . Link i length of robotic arm αi. . . Link i twist

di . . . Link i offset θi. . . Joint i angle

PLC . . . Programmable Logic Controller CAN . . . Controller Area Network

Buadrate . . . Rate of data transfer over the CAN bus

(5)

Contents

1 Introduction 8

1.1 Robotics in practice . . . 9

1.2 Background . . . 10

1.3 Description and planning . . . 10

1.4 The required specifications of the Manipulator . . . 11

2 Theory 12 2.1 Analysis of an Manipulator . . . 12

2.1.1 Forward Kinematics . . . 13

2.1.2 Inverse Kinematics . . . 14

2.1.3 Velocity Kinematics . . . 15

2.2 Motors . . . 18

2.3 Control . . . 18

2.3.1 Control Panels . . . 20

2.3.2 PROFINET . . . 21

2.3.3 Controller Area Network (CAN bus) . . . 21

2.3.4 CPR-CAN protocol . . . 22

3 Method 23 3.1 Selection of the Manipulator . . . 23

3.2 Analysis of the Manipulators Kinematics . . . 24

3.2.1 Forward Kinematics . . . 25

3.2.2 Inverse Kinematics . . . 27

3.2.3 Velocity Kinematics . . . 30

3.3 Establishing connection between PLC and the Mover4 . . . 31

3.3.1 Configuring the functions in TIA Portal . . . 32

4 Result 33 4.1 Kinematics . . . 33

4.2 Control . . . 34

4.2.1 Manual mode . . . 34

4.2.2 Automated mode . . . 35

(6)

5 Discussion and analysis 36

5.1 Analysis . . . 36

5.2 Discussion . . . 37

5.2.1 Largest issues and suggested solutions . . . 38

5.3 Advancing the work . . . 39

Bibliography 40 Appendices 43 A MATLAB source code 44 B TIA Portal Programming source code 48 B.1 PLC Tags . . . 48

B.2 Mode selection . . . 49

B.3 Control & Receive . . . 51

B.4 Cyclic interruption OB . . . 52

B.5 Reset & Enable motor . . . 54

B.6 Conveyor belt . . . 54

B.7 Manual operation . . . 55

B.8 Automated operation . . . 58

B.9 Some of the custom SCL code . . . 62

(7)

List of Figures

1.1 Lynxmotion AL5D Robotic Arm[11] . . . 9

1.2 Fanuc R-2000iC[10] . . . 9

1.3 In application[10] . . . 9

2.1 Joint concept[1] . . . 12

2.2 The ABB IRB 120 articulated robot arm[13] . . . 13

2.3 Elbow up or down state[1] . . . 14

2.4 Description of the Jacobian’s variables[1] . . . 17

2.5 Overview of the control system . . . 18

2.6 Siemens S7-1200 with CM CANopen Module and I/O Array . . . 19

2.7 Panel setup, AKA Cable mess . . . 20

2.8 Visual representation of a 11-bit CAN message[7] . . . 22

3.1 Unboxing of the Mover4 . . . 23

3.2 Mover4 Geometry[4] . . . 24

3.3 Mover4 Geometry principal in 3D[1] . . . 25

3.4 Mover4 Geometry in 2D from the side[9] . . . 27

3.5 Mover4 Geometry in 2D from the top[9] . . . 27

3.6 Mover4 Geometry in 2D from the side[9] . . . 28

3.7 Mover4 Geometry in 2D[9] . . . 28

3.8 Mover4 Geometric Equations[9] . . . 29

3.9 Coordinate frame of 2-link planar arm[1] . . . 30

4.1 Simulation from Robotic Toolbox in MATLAB[2] . . . 33

4.2 Panel 2 . . . 34

4.3 A simple flow chart of the program . . . 35

B.1 List of tags part 1 . . . 48

B.2 List of tags part 2 . . . 49

B.3 OB for automated and manual mode selection part 1 . . . 49

B.4 OB for automated and manual mode selection part 2 . . . 50

B.5 OB for automated and manual mode selection part 3 . . . 50

B.6 OB for CTRL / RCV part 1 . . . 51

B.7 OB for CTRL / RCV part 2 . . . 51

(8)

B.8 OB of cyclic interruption for manual operation part 1 . . . 52

B.9 OB of cyclic interruption for manual operation part 2 . . . 52

B.10 OB of cyclic interruption for automated operation part 1 . . . 53

B.11 OB of cyclic interruption for automated operation part 2 . . . 53

B.12 OB of Reseting and enabling all joints . . . 54

B.13 OB of Conveyor belt . . . 54

B.14 OB of manual operation joint 1 . . . 55

B.15 OB of manual operation joint 2 . . . 55

B.16 OB of manual operation joint . . . 56

B.17 OB of manual operation joint 4 part 1 . . . 56

B.18 OB of manual operation joint 4 part 2 . . . 57

B.19 OB of manual operation joint 4 part 3 (Gripper) . . . 57

B.20 OB of automated operation part 1 . . . 58

B.21 OB of automated operation part 2 . . . 58

B.22 OB of automated operation part 3 . . . 59

B.23 OB of automated operation part 4 . . . 59

B.24 OB of automated operation part 5 . . . 60

B.25 OB of automated operation part 6 . . . 60

B.26 OB of automated operation part 7 . . . 61

B.27 OB of automated operation part 8 . . . 61

B.28 OB of automated operation part 9 . . . 62

B.29 SCL of the send state machine part 1 . . . 62

B.30 SCL of the send state machine part 2 . . . 63

B.31 SCL of the send state machine part 3 . . . 63

B.32 SCL of the send state machine part 4 . . . 64

B.33 SCL of the send state machine part 5 . . . 64

B.34 SCL of Prepare Frame with SetJoint command part 1 . . . 65

B.35 SCL of Prepare Frame with SetJoint command part 2 . . . 65

B.36 SCL of arbitrary Joint Values . . . 66

(9)

Chapter 1

Introduction

In modern times humanity strive to find ways to solve problems in virtually every part of life with technology. The sophistication has risen to such a grade where it started to replace much of our manual solutions with automated alternatives. Each choice had of course it’s reasons but mostly it had same common factors, efficiency of available resources such as manpower, time, material, workspace and ultimately costs.

Then came what’s today commonly referred to as Robotic arms, also known as Ma- nipulators. Commonly a mechanical structure combined with electrical components such as circuit boards, sensors, motors etc. In all sorts and sizes, multi or dedicated purpose. Together with Computer Science making a device that can be used in many applications, such as welding, painting, assembly, packaging and palletising. Other than being able to work tirelessly it’s also a solution for extreme environments that could be dangerous.

Robots can also be categorized by their geometry (configuration) as well as their pur- pose, the geometry of the robot is often described by the motion of the different motors.

It can either be revolute (R) or prismatic (P) per motor (joint), which means each joint can have a rotational or linear motion. By this description the arrangements of the joints can be formulated as e.g. (RRR) which is a tripple revolute robot arm.

The term Robot came from science fiction back in the 1920s and were often the means for devastating ends for the human race. The type of robot that came to life however was not some sort of domination bent machine of doom, rather a child of classical mechanic and the newly developed computer science.

George C. Devol was the first to take the patent for what now refers to as a robot back in 1954 and created the first industrial robot that was first used for General Motor back in 1961[1].

The science in robotics have come a long way since then but the field that advanced most has been in the computer and sensor technology and today’s focus is on artificial intelligence with environment awareness. Aim is for robots to adapt to be around humans for safe interaction and and learn like humans how to deal with new situation.

This thesis investigates how a manipulators can be controlled through a Programmable Logic Controller(PLC) by directly communicating with the motor control boards. The report is part analytical and experimental to get a deeper understanding of the essentials of robotic motion and control.

The equipment that was used for the experimental part was a robotic manipulator called Mover4 from Commonplace Robotics[4] and a SIMATIC S7-1200 PLC from Siemens[5].

(10)

1.1 Robotics in practice

Robots that are being utilized today are all from hobby to industrial level, where it can be a tool for amusement, educational or production. Some examples are presented below.

Figure 1.1: Lynxmotion AL5D Robotic Arm[11]

The Lynxmotion AL5D is a small robot arm that are typically used for fun or as a entry level robot.

Figure 1.2: Fanuc R-2000iC[10] Figure 1.3: In application[10]

While the Fanuc R-2000 series is a industrial robot that are used in industries such as automobile production where it welds and assembles the different pars.

There are very many different examples of application of a robot and it’s essentially a replacement for the human arm. It’s main area has been the industry because of the big and expansive machines. But now when the prices of electronics decrease and newer simpler parts and controllers are available, the market for private use is growing.

(11)

1.2 Background

Purpose of this thesis were the creation of a new educational exercise for the students in a industrial automation course. An robotic manipulator controlled through PLC programming and adapted to autonomous scenarios. The control framework from this thesis will then be the platform from which the students construct their own automated concepts and learn more about the programming of the PLC.

The inspiration for this thesis in the robotic subject came from my fascination in the advances that can achieve through the application of automation in our lives.

For this reason i attended a extra course in industrial automation and got to know my teachers George Nikolakapoulos and Dariusz Kominiak that helped form this thesis.

1.3 Description and planning

The objective of the thesis was twofold. Firstly, a review on the manipulator kinematics and dynamics was to be performed, to get an in depth understanding of the topic.

Secondly, a control framework for a robotic manipulator was to be developed, for pick and place tasks. The developed framework was experimentally tested.

The thesis was based on the schedule and content presented below:

1. Research into existing robotic manipulators to find a suitable solution for the thesis purposes

2. Analysis of manipulator kinematics and dynamics 3. Setup and configuration of the manipulator

4. Development of control pipeline for pick and place tasks based on Programmable Logic Controller (PLC) programming

5. Experimental trials and evaluation of the results

Table 1.1: Original schedule of the thesis

Week Goals

39 Research the market for potential manipulators suited for the thesis Research the fundamentals in robotic control

40 Decision on the manipulator and place order Analyze the manipulators kinematics and dynamics

41 Build up a fundamental MATLAB library with manipulator data for simulation 42 Setup of the manipulator and start of configuration

43 Implementation of the PLC into the robotic control 44 Optimize the programming for coordinated control 45 Program an automated pick and place task

46 Continue programming controlled pick and place tasks 47 Write thesis report and presentation material

48 Continue report and the presentation material and present thesis

(12)

1.4 The required specifications of the Manipulator

Before research into the market began the required specifications of the manipulator had to be determined. After discussions with my supervisors we reach a few key specifications that was necessary for operation and it was following: Connectivity, Configuration, Size, Price.

Connectivity

Since the robot was suppose to be able to take commands from the PLC it was the main specification to look for. This was also the hardest to find answers to. Every modern industrial robot has its own controller for operation, and through this they have the capability to program in different languages but usually with the manufactures own fine tuned programs. The goal was to find a manipulator that could be controlled through PLC directly without any other dedicated controller.

Configuration

For the main task to pick and place objects a robotic arm that had a articulated config- uration equipped with a gripper was preferred. Because of its good maneuverability, range and variability.

Size

The laboratory and office which was used for the experiments did not have a lot of space left over and it was then important to try to make this experimental area small.

The focus of the search for the manipulators that had around 500mm reach.

Price

Budget of the project was limited, therefor important to find the most cost effective product that could for fill the criterion. This left the industrial robots out of the selec- tion since they were quite over qualified/priced for our objective with it. Therefor the aim was to try to find something that was somewhere between the industrial and hobby level.

(13)

Chapter 2

Theory

2.1 Analysis of an Manipulator

This chapter will begin with describing the fundamental concepts that will be important for understanding the thesis.

A robotic arm, if considered in separate parts, is a combined mechanical structure with motors that have generally 2 different operations, revolute (R) or prismatic (P).

Revolute joints can only rotate about its axis and the prismatic is used for linear motion between two links.

Figure 2.1: Joint concept[1]

With only these 2 operation all necessary configurations in a 3-dimensional workspace can be achieved.

In order for the manipulator to interact with material it needs an End-effector. The end-effector is usually a tool that’s at the end of the arm that performs a task like a gripper, picking objects up at location A and releasing it in location B[1].

(14)

There are different types of robotic arms that has different areas in which they are suited for. This thesis will be focusing on Articulated robotic arms that’s often a serie of revolute joint in a kinematic chain. The Articulated robotic arm can be found in a lot of industries because of its highly variability and easy control, it therefor has a vast area of application.

Example is the ABB IRB 120 Robot that can be used for industrial production.

Figure 2.2: The ABB IRB 120 articulated robot arm[13]

Workspace is the area in which the robotic arm operates, this depends on the applica- tion of the robot and mobility of the specific type.

Degrees Of Freedom (DOF) is a way of describing how maneuverable the manipulator is. Typically it should consist of 6 DOF if the arm is supposed to reach all positions in a workspace, three for positioning and three for orientation. If the manipulator has more than 6 DOF’s then it becomes rapidly more difficult to control but it can better reach behind objects. Less DOF would make it unable to reach all positions in a workspace.

In order to move the arm it will have to adjust the motors accordingly to reach a selected destination. The Parameters that’s needed to achieve this is the Forward, Inverse and Velocity kinematics[1][3].

2.1.1 Forward Kinematics

First parameter is the forward kinematics. This is possible to obtain by using the De- navit Hartenberg convention (D-H). This is an general matrix for either a revolute or a prismatic joint in a certain orientation. With the following equation a transformation can be calculated by multiplying the matrices of the rotation and linear motion to- gether to gain the total transformation of the end-effector by the joint i. (Ti) Illustrated below[1]:

Ti= Rotz,θi∗ T ransz,di∗ T ransx,αi∗ Rotx,αi (2.1)

=

Cθi −Sθi 0 0 Sθi Cθi 0 0

0 0 1 0

0 0 0 1

1 0 0 0

0 1 0 0

0 0 1 di

0 0 0 1

1 0 0 αi

0 1 0 0

0 0 1 0

0 0 0 1

1 0 0 0

0 Cαi −Sαi 0 0 Sαi Cαi 0

0 0 0 1

This means that when all the angles and displacements are known the pose of the end- effector can be computed in a cartesian coordinator system.

(15)

Ti=

Cθi −SθiCαi SθiSαi aiCθi Sθi CθiCαi −CθiSαi aiSθi

0 Sαi Cαi di

0 0 0 1

(2.2)

where C (cos), S (sin),θi(joint angle),ai(link length),di(link offset),αi(link twist), i = 1, 2, 3, 4.. (number of link/joint)

The transformation matrix can also be described as 4 different groups:

Ti=

R T

0 0 0 1

(2.3)

The top left 3x3 square is the rotation matrix (R) and the top right (T) is the three-vector position in space[1].

2.1.2 Inverse Kinematics

Second parameter is the inverse kinematic. Its a way to choose a pose of your end- effector and then calculate the joint angles based on the inverse kinematic algorithm.

This algorithm can solved by 2 methods.

The Analytical method is a numerical method called Newton’s method, or Newton- Raphson method. This approach of solving the inversed kinematic problem is an it- erated way that successively finds a better approximation for the angles of the joints.

This can end up being very heavy calculations if it needs to run several iterations to find a good position. Therefor not the best approach if precision and speed is necessary for applications e.g. welding.

The Geometrical approach is calculated by analyzing the geometric relationship of the joints and the end-effector on a manipulator. This was the method in which calcula- tion were conducted for the inverse kinematic parameter used in the simulation. What makes this approach better than the numerical method is that it can be configured in the desired shape. A common configuration that is preferred is the Elbow up configuration.

Figure 2.3: Elbow up or down state[1]

The Inverse kinematics is a common way to get your end-effector to its desired pose when no angles and displacements of the joints is given[1].

(16)

2.1.3 Velocity Kinematics

The third parameter is the rate of change of the displacement in the joints and the end-effector. The way to determine this is by looking at the relationship between the end-effectors velocity and the joint velocities referred to a common frame.

For this a compact way of describing this relationship is preferred.

The Manipulator Jacobian is one of the most important quantities in the analysis and control of the motion to achieve a smooth trajectory for the manipulator.

The Manipulator Jacobian is a matrix that encodes relationships between velocity of the end-effector and the joints angular and linear velocities. Hence knowing how the end-effector moves compared to rest of the arm.

Solving it requires finding the matrices for both linear and angular motion and com- bining them. For the angular motion the skew symmetric matrices can be used for obtaining the velocities.

The skew symmetric matrix is a useful tool for computing the relation between the angular velocity of the rotating frame x1, y1, z1to a fixed frame x0, y0, z0The vectors are defined by denoting x, y and z to a 3-vector

s = (sx, sy, sz)T (2.4)

Now each direction is described in the workspace by a separate matrix.

wherei = (1, 0, 0)T j = (0, 1, 0)T k = (0, 0, 1)T

S(i) =

0 0 0

0 0 −1

0 1 0

 (2.5)

S(j) =

0 0 1

0 0 0

−1 0 0

 (2.6)

S(k) =

0 −1 0

1 0 0

0 0 0

 (2.7)

A skew symmetric matrix S with all directions combined:

S =

0 −Sz Sy

Sz 0 −Sx

−Sy Sx 0

 (2.8)

Since the joints are rotating, a standard rotation matrix is needed to describe the joint angular movements:

R = Rx,θ=

1 0 0

0 Cθ −Sθ

0 Sθ Cθ

 (2.9)

With some future derivation it reveals that the vector of both the rotation matrix and the skew symmetric matrix are the same. This relation is needed for referring the rotation of the joints to the base frame.

∂u

∂θ

∂θ

∂t = ˙θS(i) ∗ R(t) (2.10)

(17)

In order to rotate the frame of the manipulator a vector ω(t) is required, It’s the angular velocity and it’s represented in the Shew symmetric.

R(t) = S(ω(t)) ∗ R(t)˙ (2.11)

where ω = i ˙θ and i = [1 0 0]T By derivation:

S(ω(t)) = ˙R(t) ∗ R(t)T (2.12)

The angular velocity vector ω(t) of the end-effector can now be solved by transforming back the skew symmetric matrix to a vector. A relation between the angular and the linear velocity vn0 now needs to be obtained. It can be expressed in the Manipulator Jacobian Jn0:

vn0 = Jvq˙ (2.13)

ω0n= Jωq˙ (2.14)

where Jvand Jωare 3 x n matrices f or each plane of the x, y, z and n is the amount of joints

 v0n ω0n



= Jn0q˙ (2.15)

When combining The Jacobians it becomes a 6 x n matrix that can now can used for both revolute and prismatic manipulators to calculate the velocity of the relative joints.

In the case of pure revolute articulated manipulator only the revolute Jacobian needs to be considered, which in principal is:

Ji=zi−1× (on− oi−1) zi−1



(2.16) wherezi−1≡ angular velocity (ω), (on− on−1) = is the distance between axis i to end effector(r), which is the same as the velocity equal to the angular velocity crossproduct with the distance from joint to end-effector,v = ω × r

(18)

Figure 2.4: Description of the Jacobian’s variables[1]

After the Jacobian is obtained for the robotic motion, it can be used to calculate the relative velocity between the joints and the end-effector[1][3].

(19)

2.2 Motors

Previously the physical relations of the structures joints was described. For this to even be able to move the apply of force/torque is required in the form of a motor.

These motors can have different types of designs and power source for operation, such as servo motor, stepper motor, electric and hydraulic, pneumatic etc. This thesis will be looking into and testing servo motors with direct current (DC) that operates in pure rotation[1][4].

A servo motor usually also comes equipped with a motor controller that provides it with the right amount of current and voltage for precise and smooth movements. The motor controllers can also be referred to as micro controllers and these can store parameters and other settings.

2.3 Control

This is where it all comes together, the software to the motors to the structure to the end effector desired position.

To explain, for control it’s necessary to have a software connected to the motor con- trollers. Giving it commands that the motor controller translates to movements of the joints. A simplified overview of the systems connectivity is by following figure:

Figure 2.5: Overview of the control system

The control system starts with the PC where the programming is preformed, then the program is uploaded to the PLC’s memory. Once this is completed the PC should no longer be necessary and the PLC is running on its own.

(20)

To control the PLC’s program it’s connected to a control panel where the buttons are used to activate the different programs. Once a functioning program has been estab- lished it will be able to communicate with the robots controller boards in order to move its joints.

The PLC that was used was the Siemens SIMATIC S7-1200[5]. Shown below in figure 2.6.

Figure 2.6: Siemens S7-1200 with CM CANopen Module and I/O Array

The PLC comes with the software Siemens TIA Portal V12 that’s a software designed for ladder programming. A PLC is an industrial digital computer that operates based with discrete signals. Logic as in, on or off, 1 or 0, high or low, etc. PLC’s are often used for control of manufacturing processes such as assembly lines or robotic devices[5].

(21)

2.3.1 Control Panels

In order for the PLC to operate it needs inputs from sensors or control panels to activate their preprogrammed operations. For this experimental setup two control panels were used for the selection of operations since there was no sensors to automatically start the sequences. Figure 2.7 shows how the panels were connected to the PLC.

Figure 2.7: Panel setup, AKA Cable mess

(22)

The challenge with the communication between the Siemens PLC and the motor con- trollers of the manipulator was that they were using two different communication net- works. The PLC uses PROFINET[5], that’s a field bus commonly used in industrial systems. While the motor controllers were using the manufactures own CPR-CAN protocol, which is a CAN field bus network[7].

The reason why the motor controllers is using the CAN bus is because it’s designed to be able to connect several motor controllers to each other without a host computer.

This is efficient for multi joint systems that do not have a dedicated controller unit and is free to use custom controller.

In order to make the connection possible between these protocols an adapter had to be used, the CM CANopen module[6]. It translates CANopen or CAN 2.0A to PROFINET and vise versa. Not until after a two-way translation was established could the program- ming start sending commands to the motor controllers via the PLC.

2.3.2 PROFINET

Profinet is a modern network protocol that’s developed from the PROFIBUS network in the goal of raising the the capacity of the network to meet the ever more demanding automation application of the future.

It’s based on communication over industrial Ethernet with three protocol levels: TCP/IP, RT and IRT. These makes the PROFINET protocol suitable for wide application with particular strength in delivering data within a very short time constraints (on the order of 1ms or less)[8].

In our case the PROFINET communicates between the PC, PLC and the CM CANopen module, at the CANopen module it translates the messages from the PROFINET to the CAN bus through what’s called Transparent CAN Mode. This establishes a communi- cation between a CAN 2.0A (11 bit identifiers) protocol and the PLC.

2.3.3 Controller Area Network (CAN bus)

In order to send control commands over the CAN bus it’s necessary to understand how messages are sent and received in the communication.

It’s a message-based protocol that’s a network of several CAN nodes (devices) that are connected to a ”bus”. A bus is the link between the nodes enabling them to communi- cate.

Each node has the capacity to send and receive but only the host processor of the net- work can decide what will be received out of the messages that’s transmitted onto the bus[7]. So a configuration needed to be constructed.

The CAN 2.0A protocol was used for the experiment, that’s a standard format and an underlaying protocol of the CANopen. CANopen is one of several the higher level protocols developed for standardization.

A CAN 11-bit message has a standard base frame format that consists of following details:

(23)

Table 2.1: CAN frame table[7]

Field name Length (bits) Description

Start of frame 1 Denotes the start of frame transmission

Identifier 11 A (unique) identifier which also represents

the message priority

Remote transmission request (RTR) 1 Must be dominant (0) to send data frames and recessive (1) for remote request frames Identifier extension bit (IDE) 1 Determents if frame is standard 11-bit (0)

or extended (1)

Reserved bit (r0) 1 Reserved bit for future standard amend-

ment. Can be either dominant (0) or re- cessive (1)

Data length code (DLC) 4 Number of bytes of data (0-8 bytes)

Data field 0-64 Data to be transmitted (length in bytes dic-

tated by DLC field)

CRC 15 Cyclic redundancy check

CRC delimiter 1 Must be recessive (1)

ACK slot 1 Transmitter sends recessive (1) and any re-

ceiver can assert a dominant (0)

ACK delimiter 1 Must be recessive (1)

End-of-frame (EOF) 7 Must be recessive (1)

IFS 7 Contains the time required by the con-

troller to move message to buffer area

Figure 2.8: Visual representation of a 11-bit CAN message[7]

2.3.4 CPR-CAN protocol

The motor controllers of the Mover4 had it’s own specified protocol in order to operate.

This protocol uses the CAN field bus to send position commands from the controlling software to the motor controllers.

It’s a 16 bit position data protocol that requires a specific configuration of the CAN bus message to work[4]:

1. CAN field bus at 500kbits Baudrate

2. A main loop sent in a constant time span, e.g. 20hz/50ms that sends the position command cyclically

3. Sync the hardware position given by the magnetic encoders found in the motor control board

4. Reset all joints 5. Enable motors

Main loop must cycle in order to keep motor boards engaged so the robot can receive new position commands. The motor controller boards are originally designed by the manufacture to be connected through a CAN to USB and then commanded by its own software.

(24)

Chapter 3

Method

3.1 Selection of the Manipulator

After being in contact with several robot manufacturers and searching though the In- ternet for available manipulators it became clear that it was a very small amount of manipulators that would fit for the required specification and the limited thesis time.

After acquiring prices and specifications of 15 different manipulators and summarized them into 3 different groups. Industrial, Mid-level, Low-level. Which with the indus- trial manipulators had high quality and optimized, therefor more expansive. While Mid and Low-level was less expansive and more for hobby use. The manipulators in these groups had similar specifications such as max reach, lift capacity, degrees of freedom and price. This gave a good overview to compare them with each other.

Examples of the manipulators that was examined was the ABB IRB 120[12], which can be seen at 2.1 and the Lynxmotion AL5G[11] which can be seen at 1.1.

Resulting in that the Mover 4 became the choice because of it’s lower price and con- nectivity to the PLC. It did however lack the availability to direct connect the PLC to the motor controller since the PLC is using a different communication network then the motor controllers. Therefor an adapter also had to be acquire so the different network could communicate.

Figure 3.1: Unboxing of the Mover4

(25)

3.2 Analysis of the Manipulators Kinematics

Now when the type of manipulator had been determined, it was time to get to know the characteristics of it. This is done by analyzing the motor servos and the mechanical structure.

The Mover4 consists of 4 DC servos that rotate the link between the different joints.

Figure 3.2: Mover4 Geometry[4]

An analysis of the geometry from a 3d perspective will describe the orientation of the rotation of the joints better, viewed in figure 3.3 on the following page.

(26)

Figure 3.3: Mover4 Geometry principal in 3D[1]

The table below contains the values of the figure 3.2 on the previous page.

Table 3.1: The Mover4 Specifications[4]

Links ai(mm) αi() di(mm) θi()

1 60 pi/2 0 θ1

2 190 0 0 θ2

3 220 0 0 θ3

4 45 0 0 θ4

Described in Chapter 2 there are 3 different kinematics that needs to be determined:

Forward, Inverse and Velocity Kinematics.

3.2.1 Forward Kinematics

To obtain the Denavit Hartenberg convention for the Mover4 the equation (2.1) on page 13 is directly applicable with the values given from figure 3.2 on the previous page & table 3.1.

Ti= Rotz,θi∗ T ransz,di∗ T ransx,αi∗ Rotx,αi

=

Cθi −Sθi 0 0 Sθi Cθi 0 0

0 0 1 0

0 0 0 1

1 0 0 0

0 1 0 0

0 0 1 di

0 0 0 1

1 0 0 αi

0 1 0 0

0 0 1 0

0 0 0 1

1 0 0 0

0 Cαi −Sαi 0 0 −Sαi Cαi 0

0 0 0 1

(27)

Ti=

Cθi −SθiCαi SθiSαi aiCθi

Sθi CθiCαi −CθiSαi aiSθi

0 Sαi Cαi di

0 0 0 1

Applying this for the Mover4 will get 4 equations that needs to multiply to obtain the full transformation of the arm:

T1= Rotz,θ1∗ T ransz,d1∗ T ransx,α1∗ Rotx,α1

T2= Rotz,θ2∗ T ransz,d2∗ T ransx,α2∗ Rotx,α2 T3= Rotz,θ3∗ T ransz,d3∗ T ransx,α3∗ Rotx,α3

T4= Rotz,θ4∗ T ransz,d4∗ T ransx,α4∗ Rotx,α4

Ttot= T1∗ T2∗ T3∗ T4 (3.1) Ttot is the total transformation of the end-effector based on values on the links and arbitrary angles.

Once values has been entered into the transformation matrices, the Ttotdescribes the grippers position and orientation in the work space.

To check if the equation is correct the robotic toolbox in MATLAB by Peter Corke[2]

could be used by configuring it with the Mover4’s specifications to then have as a reference.

(28)

3.2.2 Inverse Kinematics

Solving the inverse kinematics was done by analyzing the structure and joints by the geometric approach. This approach can be done by sketching up the configuration and finding the geometric relationships.

Figure 3.4: Mover4 Geometry in 2D from the side[9]

Figure 3.4 shows that the end point at the edge of the end-effector is dependent on the lengths and the angles of the links and joints. These relationships can then be described in equations that will solve possible values of angles that respective joint needs in order to reach a desired end position.

The method for doing this is to continue making sketches of the structure in different planes and views to obtain all necessary relations of the manipulator.

Figure 3.5: Mover4 Geometry in 2D from the top[9]

(29)

Figure 3.6: Mover4 Geometry in 2D from the side[9]

Figure 3.7: Mover4 Geometry in 2D[9]

With figure 3.4 on the previous page, 3.5, 3.6, 3.7 the necessary geometric relations can be obtained. With this MATLAB can calculate for an ”elbow up” configured inverse kinematics. Then just apply the specifications of a 4 DOF articulated manipulator like Mover4 into the variables.

The figure 3.8 on the following page describes the geometric equations:

(30)

Figure 3.8: Mover4 Geometric Equations[9]

Once complete, the script will provide suggestions on the joints angles to reach a arbi- trarily desired pose of the end-effector.

(31)

3.2.3 Velocity Kinematics

For the analysis of the Manipulator Jacobian its important to first find the coordinate systems of the joints rotating axes and then the length between the joints to the end- effector[3]. Figure 3.3 shows the orientation of the first joint (J1) has a pi/2 degree rotation on its axis plane compared to the rest of the joints.

The rotational coordinate system of the first joint can be described as:

Z0=

 0 0 1

 (3.2)

Which is the base plane of the system.

Because the other joints plane are relatively rotated to the base their coordinate system need to described as a the rotation in the x and y vectors to describe the relate them to base coordinate system.

Z1= Z2= Z3=

 sinθ1

−cosθ1

0

 (3.3)

After obtaining the coordinate systems of the joints it’s now important to know how far the arm can reach. One way of finding this is by taking the links length and the joints angles in both vertically and horizontally scalar and add the it like a chain.

Figure 3.9: Coordinate frame of 2-link planar arm[1]

where x, y coordinates can be expressed with the link lengthαi

x = α1cosθ1+ α2cos(θ1+ θ2) (3.4) y = α1sinθ1+ α2sin(θ1+ θ2) (3.5) This principle can be applied and just continues the more planar joints there are, so for the Mover4’s case it needs to extend by another joint.

With both the individual coordinates and lengths of the system and with the help of the Jacobian equation (2.16) on page 16 calculate the relation between each joints rotation to the common base frame.

Ji=zi−1× (on− oi−1) zi−1



(32)

With 4 revolute joints the Jacobian becomes:

z0× (o4− o0) z1× (o4− o1) z2× (o4− o2) z3× (o4− o3)

z0 z1 z2 z3



(3.6) This matrix derivatives to a 6x4 matrix that gives us each joint rotation and end effectors pose velocity relative to the base frame. This is useful for establish a ratio of velocity for each joint with respect to the end-effectors velocity.

3.3 Establishing connection between PLC and the Mover4

First step to begin connecting the PLC to the Mover4 is the installation of the CM CANopen module into the PLC. By simply plugging it into the module slot on the side of the S7-1200. This integration lets the user plug in a CAN bus into the module that then translates and sends to the PLC. This happens by configuring the module after the required specifications of the CAN bus of the Mover4[7][4][6].

The software configuration is done inside the TIA portal V12 by first installing the CM CANopen module support package and after that adding the library that contains the the function blocks used for the ladder programming.

Once the TIA portal V12 is updated with the support package and the library of the CAN module its now ready for connecting the Mover4 to the PLC via a CAN bus cable.

After that’s configured, it’s time to look over the requirements for the ladder configu- ration. As described in control section 2.3 the software configuration is key, it needs to have a specific setup in order for the motor controllers to stay engaged long enough to move the servos.

One of the specifications of the Mover4 motor control boards is that it needs to have a cyclic position commands from the controller(PLC in our case) to stay connected, if the cyclic process is interrupted or delayed(lag) it will lose the contact with the controller and go offline.

This is the first obstacle to overcome with the PLC programming.

For this the Cyclic interrupt Organization block(OB) was used as the main loop block of the PLC ladder programming. The settings sets the interval of the blocks interrupt- s/resets and therefor sending the signals periodically out to the CAN field bus. E.g. at 20 ms intervals.

With the OB set up the ladder programming starts, which is mainly govern by function blocks(FBs) and logical gates organized in a way that allows a desired function to be reached.

The FBs are of 3 types in the transparent operating mode that can be used in TIA portal:

CAN SEND or CAN SND - Contains the Send parameters of whats transmitted onto the CAN bus.

CAN RCV - Contains the Receive parameters from the CAN bus.

CAN CTRL - Contains the Control parameters and state of the transparent CAN layer.

CAN Send is the function that handles data that’s transmitted onto the CAN bus, this includes the 11 bites that’s described on table 2.3.3 on page 22 while the CAN CTRL and CAN RCV are there for regulating the receiving feedback from the CAN bus.

These Function blocks that comes with the CM CANopen module has limitations how- ever that makes them insufficient for the Mover4 application. For this reason the man- ufacturer of the CM module had to be contacted and asked for directions[6].

They already had a solution, modified functions coded in the TIA Portal as Structured

(33)

Control Language (SCL). These were referred to as functions (FC).

They essentially replace the FBs and adopt the names (CAN SND, CAN RCV, CAN CTRL)

With these FCs and the well documented descriptions inside the SCL, it was possible to apply them in a way that would enable contact with the motor controllers in the robot and the PLC.

3.3.1 Configuring the functions in TIA Portal

Step one: Settings up the state machine

The transparent operation mode of the CM module works after which state its set to.

The CAN CTRL is the FC that contains state change criteria code that allows the sys- tem to know how to operate. As in sending and receiving massages, also what param- eters that are accepted by the module. This FC is did not need any specific custom coding by user for basic operation, it just needs to be energized for the system to be active.

Step two: Transmission

The CAN messages are sent in two steps, first it needs to be prepared in a specific order and then sent into the buffer and after that sent out onto the bus. The way of preparing a message(frame) is by describing, what bit holds what information, again referring to the 11-bit standard CAN message protocol on table 2.3.3 on page 22. To prepare a message the user assigns what information should be transmitted by coding in the SCL of the FC (PrepareFrame). By assigning the array of bits that contain information such as CAN-ID, Data etc.

Once the data is entered into the array it’s then sent to a data block that collects all the temporary data that can later be called by the FC CAN SND. The next step is by the CAN SND to read the state of the transparent mode. Different states activate different functions in the Send SCL code, these are referred to as FCN(i), and are not to be confused with the functions or blocks (FC & FB).

E.g. in FCN 1 the CAN SND will send the data from the data block into the CM module that later will transmit it into the CAN bus. These FCNs are described inside the FCs in TIA Portal.

Step three: Receiving the feedback

To be able to get the feedback signals from the robots motor controllers a setup of the CAN RCV function needs to be done. This for the CM CANopen module to read and assign the responds from the CAN bus and put the bytes into an array that can later be read by the user.

The Receive function is like the send function and uses a data block to store the infor- mation received and it’s governed by the CAN CTRL in FCN and states.

(34)

Chapter 4

Result

4.1 Kinematics

Applying the theory of the kinematics and the use of MATLAB with robotic toolbox by Peter Corke[2] it was possible to see my calculations were consistent with the toolboxes own algorithms by entering arbitrary values and putting them into the simulation.

Since the thesis was about doing the experiments on the Mover4 robotic arm, it’s values were used in the kinematic algorithms. The results were after couple trails consistent with the toolbox and behaved expectingly in the simulation.

Figure 4.1: Simulation from Robotic Toolbox in MATLAB[2]

By this toolbox it was possible to see how the configuration of the manipulator would be with the values that were used. These values are also described in the matrices them selfs but it was easier to get complete picture with the help of the simulation.

The way that was used to confirm that the algorithms were correct were to first enter a desired coordinate (x,y,z) in the inverse kinematic formula and then with the resulted angles that it suggested put into the forward kinematics formula to see if the end-

(35)

effector got to the desired coordinate.

An issue with my inverse kinematics were that it was very dependent on the arbitrary pitch angle in order to reach a coordinate with precision. The algorithm did not pro- duce the most accurate of results, it could vary quite a bit. But the forward and Jacobian matrices were working just fine and was consistent with the robotic toolbox own algo- rithms.

With the kinematics solved, the work with the research on the communication and configuration with the PLC and the robot motor controllers began.

4.2 Control

The control part is where it proved to be the toughest mainly due lack of previous knowledge going into the thesis. There was no information available about this config- uration being used before and it made it a puzzle mission to take pieces of information from both the Mover4 and CM CANopen module manufacturers and putting it together.

Essentially in order to succeed a complete controller had to be created from the base functions that were provided by the manufacturer.

The goals were achieved in the scheduled time. The control of the manipulator in both manual and automated mode. These 2 modes are chosen on the external control panel 1 displayed in figure 2.7 on page 20.

Ladder program found in Appendix B.

4.2.1 Manual mode

A simple mode that utilizes two different external control panels. First the selection of which joint to activate via the buttons on external control panel 2 shown infigure 4.2, then rotate left or right depending on what the bottoms pressed/energized on the exter- nal control panel 1.

The PLC programming is based on mutual exclusion and latching logic to control each motor at a time. The buttons for rotation work as deadman switches.

Figure 4.2: Panel 2

(36)

4.2.2 Automated mode

The automated version of control, it’s designed to have fixed values of the joint rotation per joint and go there by rotating one joint at a time, starting from joint 1 and stops with joint 4. After each joint has reached desired value, it will de-energize and enable next motor.

In other words the Automated sequence is one that commands the robot to move from A to B to C and so on. In it’s logic it moves one joint to set point, triggering the next joint to move to it’s set point which also locks out the previous command. This repeats all the way until joint 4 reaches value.

Figure 4.3: A simple flow chart of the program

Once one full cycle has been completed the sequence needs to repeat but with new set of values/set points. This is done by reseting all relays that energizes the ”lock out” of the send commands, making them start from joint 1 again but with new values.

This sequence can be added on and edited with as many steps or values as the user desires.

The source code can be found in the Appendix B.

(37)

Chapter 5

Discussion and analysis

5.1 Analysis

The end-results of the thesis were good, the robot could preform pick and place tasks that was the goal of the thesis. It did however not have any other functions then Manual and Automated mode with control of one joint at a time.

The control of more then one joint at a time was an issue due to not finding a stable way of sending the CAN commands to all motors at the same time without the signals bouncing around and getting mixed up with the wrong motor controller. Resulting in unpredictable behavior since each joint often had different values of position.

After many trails with different methods and no success it felt like it was more impor- tant to focus on getting it to work with one motor at a time and leaving the multi-motor function for later research.

A drawback with the activation of one joint at a time is that the gripper is controlled by the joint 4, so therefor the joint 4 must always be engaged for the gripper to actually remain in a closed state. This makes it impossible to lift anything thats not resting on top of the gripper and not forcing the gripper open.

The final program that was developed includes timers to separate between the different functions. This was necessary because having no timers could result in the values for the current joint would be receive and used by the next joint, since the motor controllers of the robot only needs one send command to start moving to its target, it created a unwanted motion that in worst case could result in the motor ramming the arm into itself or the surrounding area.

Getting the right values to their respective joints is a key feature to make the robots operation reliable and therefor each sequence had a double check of the CAN-ID, both in the main loop and in the SetJoint of each step. This made the operation more reliable since the most effective way of making sure it did not get mixed up was by mutual exclusion in the PLC programming. This leads ultimately to isolated motor control.

(38)

5.2 Discussion

From start to finish of the thesis the content of the planning did evolve because of the challenges that came with connecting the different parts. The lack of knowledge of this configuration made it hard to predict a reliable planing. The schedule however was surprisingly accurate even of the content that had to be changed to reach the goal.

The theoretical part of the thesis went without much issues mainly due to the literature that gave much guidance to understand the mechanics that could be used for calculating the kinematics and then simulate the manipulator in MATLAB. The dynamics of the robot was not calculated however due to the limited time and it was not applicable for this base control of the robot anyhow. The theory of the kinematics were not directly applied either but it can be if a mapping of what angles of the joints are translated into the hexadecimal values. There was not time to correctly map the coordinate system of the workspace and convert it into hexadecimals.

The experimental part with getting a working configuration of the robot arm proved to be more demanding then expected. The Mover4 arrived one week later then the scheduled, which gave me about 4 weeks to experimentally develop the custom robot controller. First week went to first figure out how the standard function blocks of the CM CANopen Module were to work with the specific CPR-CAN Protocol that was demanded by the motor controllers.

However realized that it was something missing and contacted the provider of the CM CANopen module to asked about the issues. The answer was that the standard function blocks were not sufficient in the version of TIA Portal that was used, V12. The solution of the problem was that specially configured functions had to be used to replace the function blocks to provide enough functionality to satisfy the CPR-CAN Protocol.

Once the base functions was received that was necessary for sending the CAN mes- sages in a proper way it was possible to configuration them to send the correct CAN messages with specific content, length and frequence.

Obstacles with this configuration came one at a time and had to be solved by trail and error since there was no information on similar setup.

(39)

5.2.1 Largest issues and suggested solutions

1. Custom code

Since the functions had to be custom coded by user it was the first challenge to get used to how the SCL programming worked and what the functions actually did. Being new to the area of programming this took some time to get familiar with.

2. The Main Loop

The main loop had to be a active signal with a constant frequency e.g. 20 hz to ac- tivate the motors. To make this possible the TIA Portal programming had to have a CAN SND function configured with the SetJoint command with the current position that was received by the Mover4. Achieved either by timers or cyclic interrupt.

Solution: Using the Organization block - Cyclic interruption set to 50 ms interruption the PLC could with accuracy deliver a constant loop of the SetJoint command inside that block. Using timers were not reliable since the CM CANopen module receives the writing / reading instructions from TIA Portals as the functions enter asynchronous telegrams into a transmit queue. This leads to an nondeterministic transmission and would not reliably satisfy the CPR-CAN protocol[6]. The current position data was received and used from the array of data that CAN RCV was storing the data in.

3. Smooth movement

First attempts to movement was based on directly sending the robot to an end position.

This was a problem since the motor controllers then based the trajectory and moved the joints very fast if the distance was too far. A safeguard in the motor controller is a velocity limit, if a joint were to reach a high enough angular velocity the motor controller go into error mode, stopping all motion. This resulted in every now and then having to stop and reset the motor.

It was not always constant either, sometimes the motor controller could handle the movement just fine and most times it got stuck. My guess is how the PID controllers in the motor controller handled the inputs.

A way to get around this problem was to try to move the motors with very small incre- ments with each signal. In this way the motor controller did not exceed any velocity limit and could then move smoothly. Since the magnetic encoder registered the current position in 16 bit with one high and low value of hexadecimals, a small step could chosen with the low value or bigger steps with the high value. The right value had to be picked with just the right amount of increment that would result in best movement.

The values was sent in bytes, and sending a byte additional increment was not possible, so it first had to be converted the current position value from byte to unsigned and then add the increment i and then convert it back to byte to actually transmit unto the CAN bus.

Solution: Sending increment of i = 2 seemed to be general value for small and smooth movement, it however sometimes do some jerky motion at the start of a sequence but after it passed the static friction it moved smoother.

4. Micro controller getting stuck

During the trails a problem were encountered when joint 1’s motor controller got into a constant rotation without any send commands were entered besides the main loop.

When sending commands to turn the opposing rotation it got stuck in between and otherwise turning until it reached the mechanical stop. What caused this is unknown.

Solution: It was recommended by the manufacturer to use the command set joints to zero, found in their CPRog software[4]. This caused the motor controller to stop sending motor signals without command and it also changed the coordinate system of what values were what position in the workspace. Reason unknown but probably has to do with the magnetic encoders got effected after the bug and reset.

(40)

5. Ghost/Lingering values

The last puzzle came with much struggle. The manipulator was acting very random and what caused it’s behavior was hard to detect at first. In the manual mode and after getting the base automated movement programmed, things worked as intended.

Problem emerged once additional automated sequences in a row and then the robot was sometimes performing as intended and sometimes not.

First suspicion was that somethings wrong with the code and tried to copy much from the manual since that was working fine but nothing really seemed to eliminate the illusive bug that either made the joint stand still, move very fast or in the wrong rota- tional direction. The problem had to be something that happened when the sequences changed.

The issue was that the set values of the increments lingered between the different CAN SND command functions, So when a SetJoint value determined the increment value that either rotated the joint left or right it was suppose to change and adapt ev- ery time a new joint was engaged. What came unexpectedly was that the values set in the SCL code inside each separate function was saved by the PLC and not overwritten when the function was de-energized. This caused the following sequences to receive multiple inputs of increments, causing the signals to either cancel each other out or double the output or rotate the joint the wrong way.

Solution: Set all increment values to 0 as default at the start of each new send command function.

5.3 Advancing the work

Better reliability

It was much struggle to overcome the obstacle with a reliable and repeatable code using the PLC, it had some bugs that caused the robot to behave more and more unreliable the longer period it was active, e.g. if the robot was running the PLC code for a longer period of time (1-10+ min). This could be because the buffer of the CM CANopen modules was not configured correctly and after some time it began to stagger up and due to the looping. It could also have something to do with the micro controllers that was not receiving the signals in a steady loop because of the CAN SND command is not being sent in a consistent loop due to the PLC missing its timings.

Rotation restrictions

Safety limits of the robot could be programmed into TIA Portal, setting a max or min value of each joint that would de-energize the PLC programming once read from the CAN RCV. Since both automated and manual mode is mutual exclusion based a limi- tation can be set to each joint separately or the hole sequence if a limit is reached.

Multi joint control

The ability to control all motors at the same time would be preferred in automated mode for its speed and smoothness. Also maintaining the gripper closed.

The send functions sent onto the CAN bus are suppose to be able to carry up to 19 frames, each frame can contain on set of command to a specific CAN-ID. Then con- figure a send function that have all 4 frames at the same time and send. But these signals were getting mixed up. Worst result was when trying to send all of them in the same PrepareFrame, splitting the CAN-IDs up and sending each with a separate PrepareFrame parallel worked better but still not reliable enough.

PID Parameters

Each motor controller had an PID controller built in and these parameters can be con- figured for a optimized motion. The default setting of the micro controllers PID was set to only proportional and 0 integral and small derivative value of the PID[4].

(41)

Configuring State machines

The preprogrammed functions that helps govern the states of the transparent mode of the CM CANopen (CAN CTRL, CAN RCV, CAN SND) can be modified to perhaps improve the communication between the PLC and the Mover4. This was an area in which was not explored all too much and could maybe be optimized.

Rotation Values and use of MATLAB libraries

The position values that are using in the control of the rotation of the joints are in hexadecimals and quite hard to get a grip of how much rotation a change in the values give. Estimation was 2-3 degrees of rotation per High value increment but there was no measurement done and just used the experimental values from the motor controllers from trail runs.

The MATLAB scripts that use the D-H and inverse kinematics are set in degrees or radians. If a coordinate system is mapped with the joints values to degrees, then a direct calculation of the MATLAB script can be used and applied into the PLC programming instead of manually ”jogging” the robot to a end position and then look what values it has.

Application to production

The next step after a reliable controller was established was the application to a auto- mated sequence with external equipment such as conveyor belt, motion sensors, limit switches. Whatever equipment that can be used in PLC programming generally. There was no time to configure any sensors to the setup but its merely hardware configuration and adding into the logic of the program.

Worth mentioning is that the Mover4 should not be used for any real production pur- pose.

(42)

Bibliography

[1] Mark W. Spong, Seth Hutchinson, M.Vidyasagar, Robot Dynamics and Control Second Edition, January 28, 2004.

[2] Peter Corke, Robotics, Vision and Control, Fundamental Algorithms in MATLAB, 2011.

[3] Lorenzo Sciavicco & Bruno Siciliano, Modelling and Control of Robot Manipu- lator, Second Edition, 2000.

[4] Commonplace Robotics, Mover4 User guide & Wiki, CPR-CAN Protocol, November 2016,

http://www.robotshop.com/media/files/pdf/

userguide-mover4-v10.pdf

http://wiki.cpr-robots.com/index.php?title=Main_Page http://wiki.cpr-robots.com/index.php?title=CAN_

Protocol

[5] Siemens, PLC SIMATIC S7-1200, Manual, November 2016,

https://cache.industry.siemens.com/dl/files/465/

36932465/att_106119/v1/s71200_system_manual_en-US_

en-US.pdf

[6] HMS Industrial Networks, IXXAT, Manual and technical support, November 2016,

https://www.ixxat.com/products/products-industrial/

plc-extensions/cm-canopen

[7] Texas Instruments, Wikipedia, November 2016,

http://www.ti.com/lit/an/sloa101a/sloa101a.pdf https://en.wikipedia.org/wiki/CAN_bus

[8] Profibus, Wikipedia, November 2016,

http://www.profibus.com/technology/profinet/

https://en.wikipedia.org/wiki/PROFINET [9] Aberystwyth, The University of Wales, Novermber 2016,

http://www.aber.ac.uk/˜dcswww/Dept/Teaching/

CourseNotes/2012-2013/CS36510/Inverse_kinematics.pdf [10] Fanuc, Januari 2017,

http://www.fanuc.eu/

[11] Robotshop, Januari 2017,

http://www.robotshop.com

(43)

[12] ABB, Januari 2017, http://www.abb.se/

[13] References Figures & Tables,

figure 2.1 on page 12 - Spong Textbook figure 2.1 on page 13 - ABB

https://www.robots.com/media/usedrobots/1456166884_1.

jpg

figure 2.1.2 on page 14 - Spong Textbook figure 2.1.3 on page 17 - Spong Textbook

table 2.3.3 on page 22 - Texas Instruments and Wikipedia figure 2.3.3 on page 22 - Texas Instruments

figure 3.2 on page 24 - Commonplace Robotics figure 3.3 on page 25 - Spong Textbook

(figure 3.4 on page 27, figure 3.5 on page 27, figure 3.6 on page 28, figure 3.7 on page 28) - Aberystwyth, The University of Wales

http://www.aber.ac.uk/˜dcswww/Dept/Teaching/

CourseNotes/2012-2013/CS36510/Inverse_kinematics.pdf figure 3.9 on page 30 - Spong Textbook

figure 4.1 on page 33 - MATLAB, Peter Corke’s Robotic Toolbox

(44)

Appendices

(45)

Appendix A

MATLAB source code

Mover4 configuration for Peter Corkes robotic toolbox in Matlab

1 a1 = 0 ; %l i n k 1 , n o t u s e d due t o o f f s e t and b a s e

2 a2 = 0 . 1 9 0 ; %l i n k 2

3 a3 = 0 . 2 2 0 ; %l i n k 3

4 a4 = 0 . 1 2 0 ; %l i n k 4 , c e n t e r o f g r i p p e r

5

6 r o b = S e r i a l L i n k ( [

7 R e v o l u t e (’ d ’, 0 . 0 6 0 , ’ a ’, a1 , ’ a l p h a ’, p i/ 2 , ’ s t a n d a r d ’)

8 R e v o l u t e (’ d ’, 0 , ’ a ’, a2 , ’ a l p h a ’, 0 , ’ s t a n d a r d ’)

9 R e v o l u t e (’ d ’, 0 , ’ a ’, a3 , ’ a l p h a ’, 0 , ’ s t a n d a r d ’)

10 R e v o l u t e (’ d ’, 0 , ’ a ’, a4 , ’ a l p h a ’, 0 , ’ s t a n d a r d ’)

11 ] , . . .

12 ’ name ’, ’MOVER4 ’) ; %R o b o t arm l i n k c o n f i g u r a t i o n

13 qz = [ 0 0 0 0 ] ; %z e r o j o i n t a n g l e

14 qz1 = [p i/ 4 −p i/ 3 p i/ 6 −p i/ 8 ] ; %a r b i t r a r y i n i t i a l p o s

15 qz2 = [p i/ 5 . 4 p i/ 3 . 7 −p i/ 7 . 5 −p i/ 9 . 2 ] ; %a r b i t r a r y j o i n t a n g l e s

16 r o b . b a s e = t r a n s l ( 0 , 0 , 0 . 1 5 8 ) ; %mount b a s e

17 M = [ 1 1 1 0 0 0 ] ; %mask m a t r i x

18 t = ( 0 : 0 . 0 5 : 2 ) ’ ; %t i m e f o r m o t i o n 2 s e c w i t h 50 ms s t e p s

19 T1 = t r a n s l ( 0 . 3 , 0 . 3 , 0 ) ; %( x , y , z ) end− e f f e c t o r e d g e p o s i t i o n

20 T2 = t r a n s l ( 0 . 1 , 0 . 3 5 , 0 . 2 ) ;

21 T3 = t r a n s l ( − 0 . 2 , 0 . 3 , 0 ) ;

22 q1 = r o b . i k i n e ( T1 , qz1 , M) ; %j o i n t a n g l e p o s i t i o n b a s e d on end p o s T an d s t a r t i n g c o n f i g u r a t i o n q

23 q2 = r o b . i k i n e ( T2 , q1 , M) ;

24 q3 = r o b . i k i n e ( T3 , q2 , M) ;

25 [ q0 , q0d , q0dd ] = j t r a j (qz, q1 , t ) ; %t r o j e c t o r y b e t w e e n qz and q1 i n t i m e t

26 [ q , qd , qdd ] = j t r a j ( q1 , q2 , t ) ;

27 [ qw , qwd , qwdd ] = j t r a j ( q2 , q3 , t ) ;

28 [ qe , qed , q e d d ] = j t r a j ( q3 , q2 , t ) ;

29 [q r, q r d , q r d d ] = j t r a j ( q2 , q1 , t ) ;

30 [ q t , q t d , q t d d ] = j t r a j ( q2 , qz, t ) ;

31 op1 = [ q0 ; q ; qw ; qe ; q t ] ; %c o m b i n d e d t r o j e c t o r y s i n t o one s i m u l a t i o n

References

Related documents

The development of this project includes the production of a set of tools and components, such as the METERON Robotic Services (MRS), the METERON Operations Software (MOPS)

Going into the field of non-holonomic agents, dipolar navigation functions are used in [ 6 ] among others to con- struct centralized control strategies for N agents with

Joining is categorised as a group of manufacturing processes which allow the creation of a value-added product out of raw material. Joining includes a wide variety of methods

Keywords: Friction stir welding; Process automation; Temperature control; Force control; Deflection model; Robotics.. The Friction Stir Welding (FSW) process has been under

The main intension of designing this pick and place machine is there will be no need of manual operation of picking the sheet form stack to shearing machine and the auto

The major purpose and objective of our thesis is to develop interfaces to control the articulated robot arms using an eye gaze tracking system, to allow users to

This issue contains a collection of papers that have been selected from the conference “Les rencontres scientifiques d’IFP Energies nouvelles: International Scientific Conference

It is always a risk to go at a higher speed than the normal speed which we can control it easily, that is why the motor is placed there has limited rpm (rotation per minute) speed by