Component-based modelling and simulation of a KUKA LWR+4 robotic arm

(1)

Component-Based Modelling and Simulation of a KUKA LWR+4 Robotic arm

E.S. (Eric) Luper

BSc Report

C e

Dr.ir. D. Dresscher Dr.ir. J.F. Broenink Dr.ir. R.J. Wiegerink

July 2017 031RAM2017 Robotics and Mechatronics

EE-Math-CS University of Twente

P.O. Box 217 7500 AE Enschede The Netherlands

(2)

Chapter 1 Introduction

1.1 Context

i-Botics, the open innovation center founded by TNO and University of Twente, deals with telerobotics:

tele-control of a robot in a remote environment combined with a focus on immersion (telepresence) for the operator [1]. Ideally, a telerobot serves as a real world avatar for the user, placing the user in the environment so to speak, and allowing full, natural, and intuitive control. i-Botics aims to develop on telerobotics and design fully immersive systems. Such systems have use in a variety of different industries, such as medical, space, defense, etc [1]. Currently, i-Botics has a prototype robot consisting of a drivable base with an attached arm and gripper. Control for the robot utilizes haptic feedback. This means that in terms of immersion, what the robot “feels”, the user feels, as the force of different objects on the robot, such as in a robots grip, is sent back to the user. The robotic arm and grip becomes an extension of the users own arm and grip.

The complex capabilities for the finalized robot as well as i-Botics’ own design goals give rise to various projects. Current projects at the time of writing include the development of a framework for implementing middleware independent scripts, controllers for improving safety when working around humans, and implementing SLAM algorithms. In a design project, testing and evaluation can occur frequently to check the integrity of the product. To perform these frequent tests on a robot, especially with many simultaneous projects, is not feasible. Real world testing naturally opens up risks to the robot as well as the user, especially for the case of untested products. Time, being crucial in any project, is also of concern, as product testing on a robot can involve transportation time to a suitable environment, or time spent in assembly. For a company, all these factors hurt cost. To overcome this, the need for testing can be satisfied instead with simulation.

Rather than prototyping on the real world robot, its advantageous to instead implement products first in a virtual model for simulation. A simulated robot incurs no risk to the environment, and of course the real robot. Implementing designs, for example of a controller, is also fast, requiring little set up time and no time that transporting a real robot or experimental set up would take.

1.2 Problem Statement

The project covered by this report will investigate the tools and steps to setting up a means for simulating a model of the i-Botics robot. A model of the robot will be designed and implemented in a simulation software; for the sake of time, the model will be limited to the arm of the robot. The model of the arm will be designed with a component-based approach, meaning extensions (base, gripper) will be easy

(5)

to add and take away, requiring no change in the arm model. The dynamic model will be imported to a simulation tool with co-simulation support, allowing for the simulation of the robot that includes dynamics, controllers, sensors, and other software products.

1.3 Report Outline

The report is structured as follows:

Chapter Two is a background chapter for additional theory on the contents of the report.

Chapter Three will cover an analysis of modeling and simulating the robotic arm. Subjects include an overview of the robot, tools used, requirements for simulation, and an analysis of the problems, solutions, and setting up of a model and simulation.

Chapter Four and Five are the design chapters. Chapter Four covers the design of the dynamic model of the arm; Chapter Five explores importing the dynamic model into a simulation software, to enable using self-defined dynamic models in simulation over black box physics engines.

Chapter Six includes testing and evaluation, and Chapter Seven ends with a conclusion to the report, and future work.

(6)

Chapter 2 Background Theory of the Serial Link Structure

In Brodskiy et al, port-based modeling with bond graphs is used to develop a model for a robotic arm with reusability in mind [2]. The model takes the form of a serial link structure: the robotic arm is represented as a series of rigid-body links, and joints [2]. This chapter explores the necessary theory needed for understanding the serial link structure in the context of the report.

2.1 Link

A link in a robotic manipulator is represented by a link in the dynamic model. Links are treated as rigid bodies for which external wrenches can be applied to [2]. Figure 2.1 shows the bond graph of a link. The link submodel has two power ports, a signal input, and a signal output. The effort and flow of the power ports represent wrench and twist respectively. The first power port inputs wrench to the submodel, with twist as output.

T wist : T =ω v

(2.1)

W rench : W = τ F

(2.2)

Figure 2.1: Link of the Robotic Arm

(7)

The input is in the “i Frame” of reference, being located at the end of the link connected to the previous joint. This input is termed “joint reaction” by Brodskiy et al, and represents an externally applied wrench to the link by the previous joint [2].

The signal input is the four by four homogeneous matrix (H-matrix), outputted by the previous joint [2]. The H-matrix represents the location of the reference frame in the base frame, with a rotational component “R” and a translation component “p” [2]:

Homogenous Matrix : H_i^j = R_i^j p^j_i 0_3x1 1

(2.3) In this case, the input is the change from the global frame to the link’s “i” frame. The first power port connects to a transformer, which contains a six by six adjointed homogenous matrix formed from an H-matrix representing a change from the i-frame to the principal inertial frame with origin at the center of mass, that takes the input wrench and outputs the wrench with respect to the principal inertial frame [2].

Adjoint Matrix : H_i^j = R^j_i 0_3x3 p^j_iR^j_i R^j_i

(2.4) Change of Coordinates for Twist : T^k= Ad_H^k

iTⁱ (2.5)

Change of Coordinates for Wrench : (Wⁱ)^T = Ad^T_Hk

i(W^j)^T (2.6)

The transformer also updates the homogeneous matrix from the second input to represent the change of coordinates from the global frame to the principal inertial frame using equation 5.7 [2].

H_o^k= H_i^kH_oⁱ (2.7)

The second power port and signal outout of the link model parallel the first power port and signal input.

The second power-port represents an external wrench coming from the joint on the other side of the link.

In the principal inertial frame, three external wrenches are summed up, two being the joint reactions, and the third being gravity. The updated H-matrix is inputted into a transformer, adjointed, and used to change gravity from the global frame to the principal inertial frame. The summed wrenches are a source in a wrench balance, represented by the upper one-junction [2].

2.2 Joint

Figure 2.2 shows the bond graph of a joint. The joint has three power ports, a signal input, and a signal output. The first power port and signal input of the joint are in the j-frame of the previous link, with the signal output and second power port being in the i-frame of the next link. The third power port is input for a torque from an actuator to the joint, which is converted to a wrench on both links. Satisfying energy conservation, the wrench from the actuator equals the wrench on the previous link, and equals the wrench on the second link [2]. This is represented with a zero junction, in which the twists are summed in the j-frame [2]. The joint changes the coordinates for next link’s twist from the j-frame of the previous link to the i-frame of the next link using a transformer whose H-matrix is updated with a signal from an integral block. This signal represents the change of angular displacement of the joint.

Creating a model of a serial link structure is a matter of directly connecting the appropriate ports, inputs, and outputs of the link submodels to joint submodels. Figure 2.3 shows the serial-link structure.

Serial link structures start with a base and end with a final link. Joints are used only for connecting links to a base or other links.

(8)

Figure 2.2: Joint of the Robotic Arm

Figure 2.3: Series of Links and Joints

(9)

Chapter 3 Project Analysis

3.1 Organization of the Problem

Before covering the tools and research for setting up a robotic simulation, an overview of the robotic simulation requirements should be established. Co-simulation consists of three parts: First, the model of the robot, including dynamics, meshes for collision and visualizing the robot on screen, and sensors on the robot. Second, the interface and software for the robot, such as controllers and middleware support, and haptic device. The virtual robot should have the same interface, and behavior dictated by the same software, as the real robot. Third, simulation requires a world for the robot to operate in. This could be a negligible aspect for simulation in the case of simulating a robot by itself in a simulation tool, or it could be a massively important aspect of simulation in the case of running the virtual robot through a detailed and constructed world to simulate accomplishing real world tasks.

The project will focus more on the first aspect of simulation, the modeling portion, however the end set up will include the means for implementing the second aspect with ease, as well as already support easy world creation.

3.2 The Robot

The i-Botics’ robot consists of a drivable base with an arm attached, and a gripper attached to the arm [3]. The arm is a Kuka LWR 4+ from the German company Kuka, with seven degrees of freedom, and will be the component focused on in the project. The gripper is a Reflex TakkTile. The base includes a Segway RMP 50 omni, and was set up along with the rest of the components and interface by Arnold Hofstede in the cited report [3]. The interface used to control the arm includes a haptic feedback device.

Figure 3.1 depicts the robot [4].

3.3 Tools

3.3.1 20-Sim

20-Sim is a tool that allows for port-based modeling of dynamic systems using bond graphs [5]. The advantage of bond graphs is that it provides a graphical representation of a dynamic model, which aids in giving insight to the workings of a system. Port-based modeling is also domain independent, meaning systems involving transitions between multiple domains (mechanical to electrical, etc) can be modeled easily [6]. The use of ports also allows for component-based modeling for systems with multiple

(10)

Figure 3.1: i-Botics Robot Consists of a Drivable Base, Kuka Arm, and Gripper [4]

Figure 3.2: Bond graph of a damped mass-spring system, with effort in and flow out signals

(11)

components. The exact theory behind port-based modeling and bond graphs is beyond the scope of the report, but can be found in, for example “Introduction to Physical Systems Modeling with Bond Graphs” by Jan F. Broenink [6].

Figure 3.2 shows an example of a bond graph of a mass-spring system modelled in 20-Sim. Input

“signals” in the form of efforts (such as force) or flows (velocity) can be connected to a bond graph for user defined input. Output signals likewise are used for obtaining information from the model. 20-Sim can be used for controller design and simulation, with the dynamic model of a system as the plant.

Finished models can be c-code generated for various targets alongside several integration methods, allowing them to be used in other software, or as standalone c++ executables [5].

3.3.2 Gazebo

Gazebo is a 3D simulator that allows for the design and test of models [7]. Models in Gazebo can represent everyday objects such as tables, to complex systems like robots. Models in Gazebo are created as consisting of links and joints, with different links or models being attachable to each other via joints.

This means that Gazebo can support a component-based approach, as components of a robot can be added or detached with ease. Gazebo supports various ways to apply forces, torques, or velocities to links and joints in a model. The dynamics of models are handled by the ODE physics engine [7].

Robots in Gazebo can have models of common sensors attached to them. Example of supported sensors are contact sensors, which gather information from collisions with the robot, laser sensors, cameras, which are useful for mapping, and IMUs [7]. Noise can be implemented in sensors as well.

Overall, Gazebo provides access to a wide range of models of frequently used hardware, with its database supported by its sizable community.

Gazebo runs the simulation in a “world”, defined as a collection of robots and objects, with other global parameters [8]. In a world, a robot can interact with its environment, such as collide with objects, utilize sensors, etc. Model settings can be changed manually during a simulation in a world, placed in dynamically, or given an input. Simulation can be paused or run at any moment. Another layer of control that Gazebo offers are “plugins”, which allow the user to programmatically control the different components of gazebo, such as the world, models, and sensors, through standard c++ classes.

An important attribute of Gazebo is its ease of connection with ROS, a middleware that can be used for implementing controllers and other features in the form of scripts into the robot. A Gazebo and ROS connection allows for a robot in Gazebo to be controlled using the same software used to control the actual robot, accomplishing co-simulation.

3.4 Tool-Chain

With having covered the requirements for a robotic simulation and the tools, a tool chain can be made and illustrated, and will help paint clear what needs to be accomplished to create a finished set-up for co-simulation with component-based modeling support. Figure 3.3 displays the tool-chain.

Because Gazebo uses a physics engine, little insight of the dynamics of a model can be obtained.

Including 20-Sim in the tool chain allows for creating and using dynamic models made in bond-graph language, which gives insight to the dynamics of the models, that dictate the dynamic behavior of a robot or other interesting models in Gazebo. A dynamic model of the robotic arm will be created in 20-sim and the generated c++ classes imported from 20-sim into Gazebo. The dynamic model must be component-based, and include the correct model parameters.

(12)

Figure 3.3: Tool-Chain for Simulating a Robot

Gazebo is the main body of the tool chain, and will visualize and perform the simulation of the robotic arm. While 20-sim is capable of running its own simulations, it does not have the collision handling and world generation like Gazebo has. Gazebo will allow for the robotic arm to be able to collide and interact with a world filled with other models. With a Gazebo and ROS connection, scripts used for the robotic arm on the i-Botics’ robot can be used on the virtual robot for co-simulation.

3.5 Port-based, Component-based Modeling of the Arm

Dynamic modeling of the robotic arm will follow a serial-link structure approach presented by Brodskiy et al [2]. In this approach, a robotic arm is represented as a series of rigid bodies (links), with each link connected to the next by a joint, [2]. The serial-link structure was designed for reusability, with coordinate transformation between links defined in the joints, and the model’s reusability not compro- mised by systems with a different number of links [2]. The use of port-based modeling also supports a component-based approach. Background Chapter 2 is provided for the reader to understanding some of the theory of the link serial structure.

The Kuka LWR 4+ has eight links, including base, and seven joints, corresponding to the actuators between links. Each joint is limited to one degree of freedom. Constraint in the joint’s rotation will be taken into account in the model. From the Kuka assembly manual: with the arm in the upright starting position, every joint that rotates about the z-axis can turn 170 degrees in both directions, and every joint that rotates about the y-axis can turn 120 degrees in both directions [9]. Figure 3.4 shows a sketch of the Kuka arm. Inertial parameters (mass, moments) for the Kuka arm links are, of course, required for an accurate model. The mass and dimensions for the dynamic model were obtained from Centro E. Piaggio, a research center of the University of Pisa [10] [11]. Inertial moments were calculated from these values. Mass and inertial parameters of the links are given below in the tables 3.1 and 3.2.

For including external wrenches from collisions with other objects, an additional input needs to be added to the wrench balance in the link model. This will be a Gazebo compatible way of applying a wrench due to collision, as Gazebo expresses forces and torques due to collision in a body’s inertial frame.

3.6 Gazebo Modeling of the Arm

Creating a Gazebo Model of the arm is straight forward. A model is defined in a SDF file: Simulator Description Format, a format developed alongside Gazebo [12]. The two main types of components of

(13)

Inertia Base Link 1 Link 2 Link 3 Link 4 Link 5 Link 6 Link 7 Ix (kg ∗ m²) 0.0038 0.0161 0.0161 0.0161 0.0161 0.0142 0.0022 0.0001 Iy (kg ∗ m²) 0.0038 0.0035 0.0035 0.0035 0.0035 0.0036 0.0022 0.0001 Iz (kg ∗ m²) 0.0036 0.0139 0.0139 0.0139 0.0139 0.0122 0.0022 0.0001

Table 3.1: Moments of Inertia of Links

Mass Base Link 1 Link 2 Link 3 Link 4 Link 5 Link 6 Link 7

kg 2 2.35 2.35 2.35 2.35 2.24 1.1 0.25

Table 3.2: Masses of Links

Figure 3.4: Sketch of the Kuka LWR 4+, with links and direction of joints

a model in SDF are links and joints. A link represents a rigid body component of a model and contains the physical properties, collision and visual elements of the body [7]. Joints define how links connect with each other. Different types of supported joints include revolute, fixed, ball and socket, etc. An

(14)

excerpt of the model SDF made for the Kuka arm showing the first couple links and joint can be found in the appendix B.3 as an example.

A CAD of each link in the robotic arm is required for visualization, as well as a mesh for handling accurate collision in Gazebo. CADs for the Kuka Arm are available from Centro E Piaggio, and will be used for the visual and collision with complex shapes in Gazebo [10] [11].

3.7 Importing 20-Sim to Gazebo

3.7.1 Introduction

The overall motivation for importing 20-sim to Gazebo is to be able to use dynamic models that are developed in 20-sim in Gazebo, which in turn will provide collision handling for the dynamic model.

Two requirements make for a successful import: the Kuka Arm model in Gazebo needs to behave exactly as defined in the 20-sim dynamic model, and Gazebo must be able to provide the 20-sim model with information obtainable from collisions with other objects so that the robotic arm can interact with the world. Figure 3.5 is a diagram of the different software components and interactions for implementing the 20-sim import.

3.7.2 20-sim C++ Class

For outputting the dynamic model, the chosen target was a c++ class. 20-sim generates a header file of the class along with the class source file and a folder of other sources and headers containing members/methods/functionality usable by the class. The generated class is modular, and contains various methods, such as a “calculate” method, which updates dynamic model outputs based on the current input and outputs of a model. The class contains its own integration methods, able to support explicit methods such as Euler’s Method and several Runge-Kutta methods. Implicit methods are not supported by 20-sim’s c-code generation. The modular and ease of use nature of the class makes implementation in the import setup easier.

3.7.3 Model Plugin

Gazebo’s Plugin feature allows models to be programmatically controlled with c++ using Gazebo’s API [13]. A plugin is written as a c++ class, and is attached to a Gazebo component, such as a model, in the SDF file. In a model plugin, the 20-sim c++ class header can be included and the class called.

The challenge comes from managing the inputs and outputs between the plug-in and the class based on Gazebo’s capabilities and maintaining component-based modeling support, and from keeping Gazebo’s physics engine from influencing the model in favor of the 20-sim dynamic model.

From the API, it can be seen that Gazebo has functions for applying a force or setting the velocities of models or links, or angular velocities of joints [14]. Inputs to the 20-sim class is a torque to the joints, and collision wrench to the links. The simplest choice of output from the 20-sim class to apply motion to the model of the arm is the angular velocity of a joint which can be inputted into a Gazebo function to apply the angular velocity to the Gazebo joint.

For keeping Gazebo’s physics engine from influencing the model, the model need to be set to “kinematic” in the SDF file. Forces and torques to a kinematic model are ignored by the physics engine, but velocity and positions can still be updated. For a model plugin, this means that links and joints can still be manipulated when setting velocities.

(15)

Figure 3.5: Diagram of the 20-Sim Import

3.7.4 Contact Sensor and Sensor Plugin

Reading in collision data of a link requires the use of a contact sensor from Gazebo [7]. When Gazebo updates the contact sensor, the sensor collects a variety of contact related information, of importance here being the number of contacts between different objects, the number of positions of the contact, and wrench from that position [7]. A position is a point in a mesh which is used for collision, with different meshes having different positions. The contact sensor finds the force and torque in each position, in terms of the inertial frame. Reading and manipulating data from the contact sensor requires a Sensor plugin.

3.7.5 Communication between Plugins

Gazebo manages topics that allow plugins to communicate with each other with messages. This will be of importance for acquiring information from collisions in the Gazebo world to be used in the model plugin. Details on managing Gazebo topics and messages, and design details of the 20-sim to Gazebo import will be presented in design Chapter Five.

(16)

Chapter 4 Design: Robotic Arm 20-sim Model

The approach for modeling the robotic arm in 20-sim is the serial-link approach, for its reusability and component-based support [2]. The base will be considered fixed to the world, thus will not move under any force in simulation. Figure 4.1 shows the partial series of links and joints in the final arm model, consisting of eight links and seven joints. Design of the model will be divided up into two sections, the link model, and the joint model.

4.1 Link Model

Figure 4.2 shows the bond graph of the link. After constructing the bond graph, geometrical parameters need to be given to the transformers. For the H-matrix used in the transformers connected to the input and output, the rotational component is simply the identity matrix, as the frame doesn’t rotate going up the link. The translation component is the distance between frame i or j to the center of mass. Since the principal inertial frame of the link is attached to the center of mass of the link, collision effort input does not require a change in coordinate frame, as input from Gazebo is already expressed in a frame originating from a link’s center of mass. The base link does not have a wrench balance with inertial parameters or collision input, since it is considered fixed to the world.

4.2 Joint Model

Figure 4.3 shows the bond graph of the joint. The joints of the Kuka arm have only one degree of freedom, so input effort is a one dimensional torque. The transformer relates the torque and angular

Figure 4.1: Series of Links and Joints

(17)

Figure 4.2: Link of the Robotic Arm

velocity into the six dimensional wrench and twist, as expressed in equation 4.1 and 4.2 for the case of a joint that is free to rotate in the y-axis:

W =







−(R ∗ f₁+R f₁/c dt) τ

−(R ∗ f₃+R f3/c dt)

−(R ∗ f₄+R f₄/c dt)

−(R ∗ f₅+R f₅/c dt)

−(R ∗ f₆+R f6/c dt)







(4.1)

ω = T [2] (4.2)

Constraints are placed for all other directions. Counting joints from base to tip of the arm, odd number of joints rotate about the z-axis, and evens about the y-axis. The axis of the joints effect the H-matrix used in the modulated transformer depicted in the figure, with the rotational component given in the appendix. The translation component equates to zero for all joints.

The Kuka LWR 4+ has a limit to how far it can rotate that needs to be represented in the joint.

Connected to the one-junction is a collision block, whose innards can be seen in figure 4.4. When the joint has turned to its limit, a “wall” represented by a dampener and spring element, of high damping for the former, and low compliance for the latter, is connected to the one junction using a switch junction.

This effectively puts limits on the rotation of a joint, allowing links to turn freely in between the limits, but not beyond.

(18)

Figure 4.3: Joint of the Robotic Arm

Figure 4.4: Collision Block

(19)

Chapter 5 Design: 20-sim to Gazebo Interface

5.1 Importing 20-Sim to Gazebo

To evaluate the possibility of importing a 20-sim model in Gazebo, a first design will be made using a simple, one-degree of freedom, mass-spring-damper system. A dynamic model of the system will be made in 20-sim and c-code generated. Gazebo plug-ins will be set up such that the generated c-code will be applied to a model of a block, whose dynamics will thus mimic the mass-spring-damper system in addition to collision handling.

The first steps include creating the 20-sim dynamic model, and model SDF for Gazebo. The bond graph for the mass-spring-damper system is shown in figure 5.1. The input signal in the figure will be a force due to collision, and the output is the velocity of the mass. Both signals will be used in the Gazebo model plugin. A contact sensor is attached to the block in the model SDF so that forces and torques from collisions are obtainable.

5.1.1 Interface Map

Figure 5.2 showed a diagram of the different software components and communication between them.

Two plug-ins are called in the model SDF, a model plug-in called by the model, and a collision plug-in called by the contact sensor. The ContactSensor plug-in will send the force due to collision, represented in the block’s inertial frame, to the Model plugin. The Model plugin will call the 20-sim class of the damped mass-spring system, and upon every Gazebo world update, will call a class method to input

Figure 5.1: Bond graph of a damped mass-spring system, with effort in and flow out signals

(20)

Figure 5.2: Diagram of the 20-sim Import

forces and receive velocities from the 20-sim class to then apply to the block. More specifically, the visual representation and collision mesh of the block will have a velocity.

5.1.2 Collision Plug-in

On every update of the contact sensor, the ContactSensor plug-in must loop through the different contacts, and the positions in each contact, summing up forces. At the end of the loop, a total force (in the x-direction for the mass-spring) is obtained.

Communication between plug-ins uses the topic system. Since the ContactSensor plug-in only outputs to the Model plug-in, publishing to a topic is the only concern. A node is initiated and is told to advertise to a topic of a name free for choosing. Data in the form of messages are passed to a topic, so total force of collision is converted into a message and passed to the topic.

5.1.3 Model Plug-in

The Model plugin starts with creating a node, which will subscribe to the topic that the ContactSensor plugin publishes to. The topic told to subscribe to must be the same name as what ContactSensor publishes to. When the topic is updated, the Model plugin will read in the force message and a callback function is called where the message is converted to a usable form and used to set a variable representing the effort input of the 20-sim dynamic model, called “U”. “Y” will represent the velocity output. At start, the Model plugin also initializes an object of the 20-sim class type. To do this requires including and linking files that is explained in the appendix. On every update of the world, the model plug-in

(21)

Figure 5.3: Sketch of the Damped-Mass-Spring System

calls a “calculate” class method, with “U” and “Y” of the 20-sim dynamic model as the input to the method. “Y” is updated and used to set the linear velocity of the block.

5.2 Comparison and Testing of a Mass Spring in 20-sim and Gazebo

5.2.1 Introduction

Two tests were carried out to confirm that the dynamic model from 20-sim was successfully imported in Gazebo, and that the mass represented by a block in Gazebo responds to collision. The first test is a comparison between 20-sim and Gazebo, where the block is provided a constant force and the motion compared between 20-sim and Gazebo. The second test is a response to collision in Gazebo, where another block model will collide with the mass-spring block.

5.2.2 Comparison

First step is running a simulation in 20-sim. Refer to figure 5.1 for the bond graph of the mass-spring- damper system, and figure 5.3 for the sketch of the system. The parameter values for the system are listed:

Dampening Coefficient R = 1 Ns/m Spring Compliance C = 1 m/N Mass I = 1 kg

The simulation will run for ten seconds, during the duration a constant force of one Newton will be applied to the mass. Position and velocity are recorded and pictured in figure 5.4. It can be seen that the mass settles around the eight to ten second mark.

The same simulation was done in Gazebo, with position and velocity recorded to a file and imported into 20-sim for graphing. Figure 5.5 confirm a successful import of the 20-sim dynamic model to Gazebo in regards to dynamics, as the mass-spring-damper system behaved identically in both simulations.

(22)

Figure 5.4: Position and Velocity of the Mass over ten Seconds (20-sim)

Figure 5.5: Position and Velocity of the Mass over ten Seconds (Gazebo)

(23)

Figure 5.6: Sketch of the Mass-Spring System

Figure 5.7: Velocities of Two of two Masses (Gazebo)

5.2.3 Collision Testing

A setup for a collision test will be reminiscent of a Newton’s cradle, in which damping is removed, and a second block of 1kg and same dimensions as the first block in the mass-spring system is introduced and given a velocity of 1 m/s. The second block will collide with the first, in which an exchange of momentum should take place. The ideal result is that the second block comes to a stop, the first block moves and rebounded by the spring, and then on a second collision the first block should come to a stop, with the second block regaining its velocity, but in the opposite direction. A sketch is given in figure 5.6.

Figure 5.7 shows the results of the simulation. The velocity of both blocks are plotted and compared.

The blocks hold initial velocities: zero for the first block and negative one for the second. At the two- second mark, the blocks collide, showing a quick exchange of momentum. The first block comes back and another collision occurs at around five seconds, with another exchange of momentum. The second mass holds a velocity equal but opposite to its initial velocity.

5.2.4 Conclusion

Import of the dynamic model for a one degree of freedom mass-spring system into Gazebo was successful.

In a test of dynamic behavior between 20-sim and Gazebo, dynamics was consistent. The 20-sim

(24)

dynamic model fully dictated behavior, with no interference of Gazebo’s physics engine. In a collision test, impact supplied an effort to the dynamic model. Between Gazebo models, exchange of momentum was maintained.

5.3 Extending Plugins to work with the 20-Sim Model of the Kuka LWR 4+

5.3.1 Introduction

A robotic arm modeled as a serial link structure consists of several links. Following the reusable nature of the serial link structure, different robotic arms can have different numbers of links but still follow the same general structure. To work with a robotic arm model using the serial link structure, the plug-ins need to be extended to work with models of several links. To support reusability, the code must be generalized to handle an arbitrary number of links and joints. Effort and flow are also no longer a one dimensional force and velocity as in the mass-spring system, but now a wrench and twist (meaning six-dimensional).

5.3.2 20-sim Class Input Organization

Organization of the inputs(U) and outputs(Y) to the 20-sim submodel is needed for formulating an algorithm in the model plugin to support arbitrary number of links. For the example of a robotic arm with two links, not including base:





 U [0]

U [1]

U [2]

U [3]

U [4]

U [5]







=> Collision for Link One (5.1)





 U [6]

U [7]

U [8]

U [9]

U [10]

U [11]







=> Collision for Link Two (5.2)

U [12] => Joint One Input (5.3)

U [13] => Joint Two Input (5.4)

Y [0] => Joint One Angular Velocity (5.5)

Y [1] => Joint Two Angular Velocity (5.6)

(25)

5.3.3 Collision Plugin

Compared to the plug-in used for the mass spring, the first change is simply sending the wrench through the plug-ins output versus just a force in the x-direction. Since multiple links exist in the model, each with a contact sensor plugin, a naming convention for the links is required so topics can be named using the model and link names, avoiding the plugins from overriding each other’s output during a contact sensor update. The convention chosen is to name the links with integer values, the base being “0”, and the next link “1”, etc. The naming will also have another use in the model plug-in for applying the efforts to the correct 20-sim related variables for the method input, described in the Model Plugin section. The name of the link needs to be sent to the model plugin along with the collision wrench. This requires making a custom message, since this task goes outside the scope of Gazebo’s normal message types.

5.3.4 Model Plugin

On start, the model plugin creates an array of pointers to the links, and an array of pointers to the joints. The size of these arrays is used in loops for updating the links and joints. When the model plugin receives a wrench from one of the contact plugins, it needs to send the six values to the correct inputs(U) for the 20-sim class calculate method. This is where the organization of the 20-sim submodel inputs and naming convention of the links come into play. When the callback function from a node is called, the following algorithm is used:

U [(LinkN ame − 1) ∗ 6] = W rench[1] (5.7)

U [(LinkN ame − 1) ∗ 6 + 1] = W rench[2] (5.8) ...

U [(LinkN ame − 1) ∗ 6 + 5] = W rench[6] (5.9)

(26)

Chapter 6 Testing and Evaluation

6.1 Introduction

Two tests are performed to check the competence of the model, and the 20-sim to Gazebo import. In the first test, the completed dynamic model of the robotic arm will be simulated with basic movements in 20-sim to evaluate the model’s reliability. Both explicit and implicit integration methods will be used, and performance of the simulation will be discussed. After simulation in 20-sim, the arm will be simulated in Gazebo with the same movements, and the results of the two simulations compared. The starting position of the robot for all motions is upright. The first motion is five seconds in duration.

Each joint that rotates about the z-axis (odd number joints) will be given a torque of 50 Nm for one second each, one joint after the other. The second motion is an arm wave due to an input sine wave of amplitude 100 Nm and 1 rad/s angular frequency applied to the second joint.

The second test focuses on the integrity of the model by comparing experimental results from the Kuka LWR 4+ to the model. A controller was used to manipulate the real arm, in which torques to the joints and the position of the joints were sampled and recorded. The torques are inputted in the model, and the consequential joint positions over time are acquired and compared to the real arm’s results.

6.2 Simulation of the Arm in 20-sim

The first motion is attempted using Runge-Kutta 4 with time step 1 ∗ 10⁻5. This produced an error indicating that the time step was not small enough, however smaller time steps yielded unfavorable calculation times. Other explicit integration methods are attempted with similar results. Next attempt is with an implicit method: the modified backward differentiation formula. Results are visible in figure 6.1. Visible in the graph is rotation of the joints when a torque is applied. Test of the second motion had similar results for an attempt with an explicit integration method. Figure 6.2 displays results for the implicit method.

The performance issue with using an explicit integration method is a drawback since 20-sim’s c-code generation is only compatible with explicit methods. Calculations for simulations should be within reasonable time, and for the case of simulating the robotic arm with cosimulation in mind, with real time interfacing, the simulation needs to be able to keep up with real time. In order to even simulate with the Runge-Kutta method, and generate c-code for Gazebo, all parameters for the moments of inertia of the links had to be raised to one kg ∗ m² as to increase time constant to allow for increased time step size. This compromises alot of accuracy in the models representation of the Kuka LWR 4+, but is sufficient for testing that the model behaves generally like a similar robotic arm. Figure 6.3 and

(27)

Figure 6.1: Angular Velocity of Joints: Motion 1 with Implicit Method

Figure 6.2: Angular Velocity of Joint 2: Motion 2 with Implicit Method

(28)

Figure 6.3: Angular Velocity of Joints: Motion 1 with Explicit Method

Figure 6.4: Angular Velocity of Joint 2: Motion 2 with Explicit Method 6.4 show the results that will be used in the comparison with Gazebo.

6.3 Comparison in Gazebo

Both motions are performed in Gazebo. Figure 6.5 and 6.6 shows the plots made from the Gazebo simulation, which compared to the plots from the 20-sim simulation shows that the arm behaves correctly and that import was successful.

6.4 Comparison of the Kuka LWR 4+ to the Dynamic Model

Torque and joint positions were sampled from a recorded motion of the arm through ROS. The data files were plotted with Matlab: figure 6.7 shows the torques to the first three joints (rest were omitted to save space), and figure 6.9/6.10 plot the positions of every joint over time. Input torque to the dynamic model was derived from a linear interpolation in 20-sim of the torque samples. Figure 6.8 shows a plot of the torques in 20-sim.

(29)

Figure 6.5: Angular Velocity of Joints in Gazebo: Motion 1

Figure 6.6: Angular Velocity of Joint 2 in Gazebo: Motion 2

(30)

Figure 6.7: Torques on the Joints

A simulation was performed for twenty seconds, and the resulting joint positions (radians) over the time is presented in figures 6.11 and 6.12. The dynamic model did not behave sufficiently similar to the real arm. Joint one showed the closest relationship, maintaining the oscillation seen in the real arm, though with some shift and instability. Aside from a peak, joint four also showed some consistency.

Explanation for big movements in some of the other joints was a consequence of gravity, as the applied torque could not overcome gravity.

A couple of possibilities for the inconsistencies in the simulation exist. First is incorrect parameters.

Inertia parameters and gravity are correct. Friction in the joints, however, was roughly estimated and is a possible source of error. Another source of error are the torques read from the experimental results versus the actual torques applied to the joints. The Kuka arm has a controller which may apply gravity compensation, and possibly other dynamic compensations. If the torques read and used in the model are input torques without compensational torques included, error in simulation will, of course, happen.

(31)

Figure 6.8: Torques on the Joints

Figure 6.9: Positions of the Joints

(32)

(33)

(34)

Chapter 7 Conclusion

7.1 Conclusion

The objective of the project was to model a Kuka LWR 4+ in a component-based manner, and implement its dynamic model from 20-sim to Gazebo in a effort to set up the means for simulating a robot with co-simulation support. With Gazebo, simulated robots can be ran with the same software as their real counterparts, and the 20-sim import opens up bond graph support to gain insight in the dynamics of the systems.

Dynamic modeling was mostly successful. A model of a robotic arm was realized using the serial-link structure approach, upholding the component-based goal. The arm was simulated, and kinematically behaved as expected in accordance to the model. However, simulation times were quick to get imprac- tically long with the use of explicit integration methods. This poses a problem, since c-code generation only supports explicit methods.

With Gazebo’s plug-in functionality, and 20-sim’s class generation, importing dynamic models into Gazebo was a success. Design and testing of the software components was done successfully for the case of a simple mass-spring, and then extended upon to handle an arm of arbitrary number of links.

In a comparison with an actual Kuka LWR 4+, the dynamic model did not give results that corre- sponded with the real arm.

7.2 Future Work

Future work first includes examining possible solutions to simulation performance to handle real-time requirements. Its possible the dynamic model may somehow be optimized to improve simulation speed and stability. Use of powerful computing hardware may be required for real-time simulations. Second is exploring the dynamic model’s integrity with the real arm. More experiments may give more insight into how the dynamic model compares, and where the problems lie. Investigating joint friction can lead to a more accurate model. The controller of the Kuka Arm is worth investigating for its role on the torques of the actuators. Understanding the dynamic compensation and being able to read the correct torque applied to the joints allow for correct use of the model. Lastly is completing the tool chain by setting up the Gazebo to ROS connection, and setting up ROS with the scripts and interface. A more in depth simulation could be performed by performing a task with both the virtual and identical arm.

(35)

Appendix A 20-sim Model

A.1 Generating C-Code

Generating C-Code requires that the model has no dependent states, and that the used integration method is explicit. To generate a class, open the simulator, select tools, Real Time Toolbox, C-Code Generation. Option for targets should open up. Select C++ class (or any other target if desirable), choose a submodel, and then directory for the scripts to be placed into. If a target does not show up, go to settings, options, folders, C-Code Folders, Add, and search 20-sim for the ccode folder.

Using the 20-sim code can give an error with the variable “major” used in the integration script files

“integ.cpp” and “integ.hh”. Changing this variable to a different name solves the issue.

Figure A.1:

(36)

Figure A.2:

Figure A.3:

Figure A.4: bool major may need a name change.

(37)

Appendix B

Gazebo Plug-Ins

B.1 Contacts Plugin

Figure B.1 displays the code for the Contacts Plugin.

Figure B.1:

B.2 Model Plugin

Figure B.2 displays the code for the Model Plugin.

(38)

Figure B.2:

B.3 Model SDF

Figure B.3:

(39)

Bibliography

[1] i-Botics. N.p., n.d. Web.

[2] Dresscher, Douwe, Yury Brodskiy, Peter Breedveld, Jan Broenink, and Stefano Stramigioli. “Model- ing of the youBot in a serial link structure using twists and wrenches in a bond graph.” Proceedings of SIMPAR 2010 Workshops: International Conference on Simulation, Modeling, and Program- ming for Autonomous Robots. Darmstadt (Germany) November 15-16, 2010 (n.d.): 385-400. Web.

http://doc.utwente.nl/76356/1/05-SimTechRDP.pdf.

[3] Hofstede, Arnold. On Design and Realization of a Telemanipulation Demonstration Setup. En- schede: University of Twente. 2017. Print. 002RAM2017.

[4] Robotics and Mechatronics. Utwente, n.d. Web. https://www.ram.ewi.utwente.nl/research/project/i- botics.html.

[5] Kleijn, C., Groothuis, M.A., Differ H.G. 20-sim 4.6 Reference Manual Enschede, Controllab Prod- ucts B.V., 2017 ISBN 978-90-79499-19-9

[6] Broenink, Jan. Introduction to Physical Systems Modelling with Bond Graphs. Enschede: University of Twente. 1999. PDF file. https://www.ram.ewi.utwente.nl/bnk/papers/BondGraphsV2.pdf [7] Open Source Robotics Foundation. Gazebo. Web. http://gazebosim.org/

[8] Open Source Robotics Foundation. Gazebo. Web. http://gazebosim.org/tutorials?tut=build world

&cat=build world

[9] KUKA Roboter GmbH Lightweight Robot 4+ Assembly Instructions 2012. PDF.

[10] Center “E.Piaggio”. Bioengineering and Robotics Research Cen-

ter “E. Piaggio”. Web. https://github.com/CentroEPiaggio/kuka-

lwr/blob/master/lwr description/model/kuka lwr.urdf.xacro.

[11] Center “E.Piaggio”. Research Center “E.Piaggio” Faculty of Engineering University of Pisa. Web.

http://www.centropiaggio.unipi.it/

[12] Open Source Robotics Foundation. SDFormat. Web. http://sdformat.org/

[13] Open Source Robotics Foundation. Gazebo. Web. http://gazebosim.org/tutorials

?tut=plugins hello world&cat=write plugin

[14] Open Source Robotics Foundation. Gazebo API. Web. http://osrf- distributions.s3.amazonaws.com/gazebo/api/dev/index.html