From prototyping code to standalone running code using ROS

.28235

FROM PROTOTYPING CODE TO STANDALONE RUNNING CODE USING ROS D.M. (Dennis) Hoftijzer

BSC ASSIGNMENT

Committee:

dr. ir. J.F. Broenink dr. ir. A.Q.L. Keemink T.G. Broenink, MSc

September, 2019

035RaM2019

Robotics and Mechatronics

EEMathCS

University of Twente

P.O. Box 217

7500 AE Enschede

The Netherlands

iii

Abstract

The goal of this bachelor assignment is to see what considerations need to be made when mak- ing the generated prototyping code from 20-Sim 4C into standalone software. Using 20-Sim 4C, C-code can be generated during development in order to quickly test the developed hard real-time control on the embedded control computer. However, this means that the setup of these prototypes is such that the embedded control computer is connected to a development station. Thus the generated code from 20-Sim 4C developed during prototyping, can not run standalone.

In order to convert the prototyping software to standalone software, the prototyping software should be able to run without a development station and soft real-time control should be added. Hard real-time control will still be provided by the prototyping code. Therefor another software framework is used to replace 20-Sim 4C command and control software. For this soft- ware framework, the Robot Operating System (ROS) is used.

Communication between ROS and the generated prototyping code is setup by converting the code to a ROS node. In order to do this, first the C-code needs to be converted to C++. The shared memory, which is used by 20-Sim 4C command and control software, is excluded. Fur- thermore, publishing and subscribing to other ROS nodes is placed right after the reading/writ- ing to and from IO hardware. Lastly, ROS functions are used to stop the code from running and to synchronize time between ROS and the calculation of model equations.

Supervisory- and sequence control can be added using other ROS nodes. However in order to alter set-points in a control loop within the model equations, artificial states need to be created.

This is done by altering the 20-Sim model, by using integrators.

This approach of making the generated prototyping code from 20-Sim 4C standalone, is ap- plied to a case study. In which the working of the approach is shown. Something to consider is the setup time of the subscriber-publisher communication between nodes.

In conclusion, this bachelor assignment has shown what considerations are necessary for mak- ing the generated prototyping code into standalone software. However the focus of this study, was on the communication between ROS and the prototyping code. This research can be ex- panded by studying, which considerations need to be made when the standalone software is installed on the embeddedd control computer of the prototype.

D.M. Hoftijzer

University of Twente, September 6, 2019

v

Contents

1 Introduction 1

1.1 Context . . . . 1

1.2 Project goals . . . . 1

1.3 Document outline . . . . 2

2 Analysis 3 2.1 Problem analysis and approach . . . . 3

2.2 20-Sim . . . . 4

2.3 ROS: Robot operating system . . . . 6

2.4 Type of data . . . . 6

3 Approach 7 3.1 Approach overview . . . . 7

3.2 20-Sim model . . . . 7

3.3 Generated C-code as a ROS node . . . . 8

3.4 Sequence control . . . . 10

4 Case study 11 4.1 20-Sim model: Cart with 2 wheels . . . . 11

4.2 ROS communication overview . . . . 12

4.3 The 20-Sim 4C ROS node . . . . 12

4.4 Results . . . . 13

4.5 Discussion . . . . 19

5 Conclusion and recommendations 20 5.1 Conclusion . . . . 20

5.2 Further recommendations . . . . 21

A Appendix: Case study model 22 A.1 20-Sim model case study . . . . 22

B Appendix: Demonstration instructions 23

Bibliography 24

1

1 Introduction

1.1 Context

At the Robotics and Mechatronics (RaM) group the main focus is on developing and research- ing robotics. Research is done in several areas of robotics, including medical and inspection robots. Prototypes are developed, which are used to validate a certain design. The setup of these prototypes is such that the embedded control computer (ECC) is connected to a devel- opment station as this allows for easy testing. Generated C-code can be tested on the embed- ded control computer during development. This is the case for software like 20-Sim

. It allows for easy prototyping of robotics by easy modelling of complex mechatronic systems and mak- ing controller designs. These models can then be used to generate C-code with the 20-Sim 4C package. (Groothuis, 2001) This generated code can easily be run on the prototype hardware in order to quickly test the software. A typical software design for embedded control systems (ECS) is structured in a way as can be seen in Figure 1.1.

Figure 1.1: Software structure of embedded control systems. (Groothuis et al., 2009)

Hard real-time behaviour is necessary for layers which are close to the hardware, whereas layers which are less close, can have non- or soft real-time behaviour. (Broenink and Ni, 2012) During prototyping, Loop control is developed on a development station. C-code, which contains this hard real-time loop control, is generated using 20-Sim 4C. This code is then run on the ECC in the prototype in order to test the loop control. 20-Sim 4C command and control software is used for non- and soft-real time layers, such as sequence control. The 20-Sim 4C command and control software is located on a development computer, which means the prototyping software cannot run standalone. In order to solve this problem, another software framework has to be used, to make the prototyping software able to run standalone on the ECC and integrable in a larger robotic system. 20-Sim and 20-Sim 4C software is still necessary in order to develop and test the loop-control during prototyping and generate the C-code, which will provide the loop-control in the standalone software.

When another software framework is used instead of 20-Sim 4C control software, sequence control can be separated from loop-control. This allows for sequence control to be imple- mented on the ECC. Additionally, the sequence control can be more complex and more easily modified.

1.2 Project goals

The goal of this project is to see what needs to be considered in order to make the prototyping software from 20-Sim 4C into standalone software. Furthermore to show, by the use of a case study, how this can be done. For this an alternative software framework will be used in order to replace the 20-Sim 4C command and control software. The focus of this research is on consid-

1https://www.20sim.com

erations, which need to be made when making the generated C-code into standalone software, without considering a physical system or IO hardware. This can be seen in Figure 1.2.

Figure 1.2: Overview of the goal design. Focus of this project is on the communication of the alternative software framework with the generated prototyping code. This is indicated in bold.

Communication between the generated code and the alternative software framework will have to be set-up, which is the focus of this research. Additionally, soft- and non real-time layers will have to be implemented by the alternative software framework in order to replace the 20- Sim 4C command and control software. Loop- and sequence control will be separated. The loop-control is provided by the generated 20-Sim 4C code. Furthermore, sequence control will have to be designed and implemented, using the alternative software framework. However soft- and non real-time layers including sequence control can, with the alternative software framework, possibly be offloaded to a base station. This reduces computational requirements on the hardware of the prototype. (van der Werff and Broenink, 2015 & 2016)

Thus the main research question is:

What considerations need to be made in order to make the generated prototyping code from 20- Sim 4C standalone?

This consists of replacing the 20-Sim 4C command and control software with an alternative software framework as well as setting up communication between the generated 20-Sim 4C code and the alternative software framework. Further project goals include designing the se- quence control using the alternative software framework.

1.3 Document outline

First of all, Chapter 2 describes an analysis on the different parts of the project. This chapter includes an elaboration on the problem, explain what alternative software framework is used and how it works. Furthermore Chapter 2 shows how the generated code from 20-Sim 4C func- tions, and it will examine, which types of data are often used in robotics. Chapter 3 describes the approach on how to convert generated C-code from 20-Sim 4C to standalone software. In order to illustrate the approach, it is applied to a case study, which follows in the next chapter, Chapter 4. Results from the case study are presented and discussed. The last chapter, Chapter 5, answers the research question and furthermore gives recommendations for further research.

Conclusions about the approach are made.

3

2 Analysis

2.1 Problem analysis and approach

The prototyping code generated by 20-sim 4C currently cannot run standalone due to the 20- sim 4C command and control software. It is necessary for this command and control software to run on a development station. In order to solve this problem, another software framework has to be used, in combination with 20-Sim and 20-Sim 4C. Standalone software can be created using the generated prototyping code. The generated prototyping code, generated by 20-Sim 4C, provides the hard real-time loop control in the standalone software.

For this alternative software framework, there are several options. The Robot Operating Sys- tem (ROS) (Quigley et al., 2009) is one of them. Real- time control has before been coupled to ROS (van der Werff and Broenink, 2015 & 2016) (Bezemer and Broenink, 2015). Other op- tions include the Open Robot Control software or for short: OROCOS. (Bruyninckx et al., 2003) (Bruyninckx, 2001) Orocos is a robotic operating system, which offers a framework for con- necting different components of a robot. However ROS is more actively supported, has a larger community and is less focused on only hard real-time control of robots. Yet Another Robotic Platform (YARP). (Metta et al., 2006) is an option as well. YARP is a set of libraries, tools and protocols to keep different modules and sensors in a robot decoupled. It is however not an op- erating system and is not designed for soft real-time control of a robot. Soft real-time control can be implemented using ROS. Therefor ROS is suitable and is used for this project.

ROS is very useful as it is network based, allowing for the generated prototyping code to be easily connected with other algorithms and functions such as sequence control. A part of the ROS network, which implements such algorithms, is called a node. A ROS software design can contain many nodes. The generated code will have to be rebuild to such a ROS node. This is shown in Figure 2.1.

(a) Prototyping software.

(b) Standalone software using ROS.

Figure 2.1: Current overview of prototyping software, which is not capable of running standalone, is

shown in Figure a. Overview of the standalone software using ROS and the generated prototyping code

is shown in Figure b. Using ROS, other nodes including a node for sequence control can be implemented

on the ECC.

Design of the communication between the generated code and ROS is required. In addition, ROS is used to implement the soft- and non real-time layers. Sequence control is implemented using ROS and hard real-time layers by the generated prototyping code from 20-Sim 4C. The standalone software including all ROS software and the generated code, can be run on a de- velopment station. This is done in order to show what considerations need to be made in the communication between ROS and the prototyping code, when making the prototyping code standalone.

In order to convert the generated C-code loop controller to a ROS node, first the structure of the generated 20-sim 4C code is analyzed to see which functionality is necessary to create the standalone software. This is done in Section 2.2. Segments of the code might not be necessary or the code might have to be altered in order to setup communication with ROS. Furthermore an analysis of ROS is described in Section 2.3, in order to see how ROS can be used to commu- nicate with the generated prototyping code from 20-Sim 4C. Lastly an analysis of data mainly used in robotics is performed in Section 2.4.

2.2 20-Sim

20-Sim is a modeling and simulating program, which allows for easy modelling of complex mechatronic systems. Using 20-sim 4C, C-code can be generated during development, which can be run on the embedded control computer on the prototype. The structure of this code is further described in the following section.

2.2.1 Generated prototyping code

An overview of the generated C-code from 20-Sim 4C is shown in Figure 2.2.

When the C-code is generated, the model is converted into a set of equations. (Oosterom, 2006) The dependent states, coming from the differential equations of the model, are calculated in the dynamic equations part. Rates of change of these dependent states are calculated using an integration method in which a time step is processed. The state of dynamic equations are calculated every integration step. Intermediate states may be calculated multiple times per integration step.

Optimization by 20-Sim 4C is such that the number of dynamic equations, is as small as possi- ble. This is done in order to improve the speed of the simulation process by reducing the num- ber of computations. (Broenink and Weustink, 1996) Hence independent states of the model are not calculated each simulation step, but only at the beginning of the code. This is done in the static equations part of the code. In- and outputs of the model equations are calculated in the in- and output equations section. When the process ends, final equations are calculated.

Initialization of all the model parameters, states, dynamic rates and variables is done in the

initial equations section.

CHAPTER 2. ANALYSIS 5

Figure 2.2: Overview of the generated C-code. The 20-Sim 4C command and control software runs on a development station whereas the generated C-code runs on the ECC in the prototype. (Broenink and

Weustink, 1996) (Oosterom, 2006)

Further tasks of the C-code include:

• Reading from the input hardware and writing to output hardware.

• A shared memory is created and synchronized with model calculations in order to al- low for logging, monitoring and controlling of data by 20-Sim 4C control and command software.

Now that the C-code has been analyzed, essential sections of the C-code in order to convert it to a ROS node can be identified:

• The calculation of the initial and static equations.

• Writing and reading to and from the hardware IO.

• Calculations of equations, which depend on an in- or output: input- and output equa- tions.

• The calculation of all the rates of dependent states, which is the dynamic equations sec- tion.

• Lastly, the calculation of the final equations.

Logging and monitoring from 20-Sim 4C is not needed, this is further explained in Section 3.3. Hence the shared memory from the C-code will be excluded when creating the standalone software.

2.3 ROS: Robot operating system

The Robot Operating system (ROS) is a collaborative effort to develop robust and general pur- pose robot software. ROS is an open-source software framework widely used all over the world.

It contains many libraries, tools and conventions in order to create robot software. It is espe- cially useful because it is broadly used all over the world and well supported. Furthermore, it supports multiple languages including C++ and Python.

2.3.1 ROS structure

ROS offers a structured network of different parts of the software. An overview is presented in Figure 2.3. The ROS master allows for nodes to communicate with each other. Nodes are regis- tered to the master in order to allow for communication between them. Nodes communicate with each other through messages, which describe the layout of the data for communication.

Nodes send these messages by subscribing and publishing to topics. A node can publish to a certain topic or it can subscribe to a topic. One node can contain multiple subscriptions and/or publications.

Figure 2.3: Overview of ROS communication structure.

2.4 Type of data

Many different data types are used in software for robotics in general. In order to make the approach for making standalone software of the generated prototyping code more applicable to other cases, it is useful to research which data is often used in robotics. Such that consider- ations for different data types in the communication between ROS and the generated 20-Sim code can be made.

ROS messages are available for many different types of data and even custom messages are

possible. However almost all of these data messages are composed of a few standard data types

and combinations of these data types. Some important examples are float64, strings and inte-

gers. Furthermore the generated 20-Sim 4C code compiles all states of the model as a signed 64

bit floating point number. A float64 ROS message is available. Thus data from all states in the

prototyping code can be simply send to other nodes, as standard ROS messages.

7

3 Approach

In this chapter the approach on how to convert the prototyping C-code to standalone software is explained. First an overview is presented in Section 3.1. Considerations which need to be made within the 20-Sim model, before generating the C-code using 20-Sim 4C, are described in Section 3.2. After the code is generated, more considerations need to be made when the code is converted to a ROS node. This is described in Section 3.3. Furthermore, sequence control is designed using ROS. This is described in Section 3.4. Keep in mind that the approach does not consider using 20-Sim, 20-Sim 4C and ROS to bring the standalone software onto the ECC on the prototype. But only shows the considerations, which need to be made in the communication between ROS and the generated prototyping code.

3.1 Approach overview

An overview of the design of the standalone software using ROS, is presented in Figure 3.1.

Figure 3.1: Overview of the design of the standalone software. Supervisory control can possibly be implemented on a base station, which is indicated with a dotted line.

The generated prototyping code, which controls the hardware is converted to a ROS node.

This node includes all the model equations and parameters from the 20-Sim model. However the shared memory, used for logging and control by 20-Sim 4C control software, is excluded.

This 20-Sim 4C ROS node is subscribed to a topic containing the sequence control commands, which are published by a second ROS node for sequence control. All ROS nodes are registered to the ROS master. Furthermore supervisory control can possibly be implemented on a base station in order to give supervisory commands to the ROS node for sequence control. This node would also be registered to the master.

The C-code is compiled and generated by 20-Sim 4C from a set of equations, which are derived from a 20-Sim model. Some changes need to be made in the 20-Sim model in order to set- up communication between the generated C-code and ROS. This is described in the following section.

3.2 20-Sim model

A very important consideration is how to create an interface between ROS and the generated

C-code. An important aspect of this interface, starts with the 20-Sim model which is used.

Writing from ROS to the C-code

In order to write from ROS to the generated code, a workaround is needed. If a state of a dy- namic equation in the 20-Sim model is controlled, it is done by some sort of feedback and a constant set-point in a control loop. However when C-code is generated using 20-Sim 4C, it will optimize the C-code such that, only the dependent states are calculated each simulation step. Namely in the dynamic equations by using an integration method. Hence, the set-point, which is non time-dependent, is calculated in the static equations section of the code as it will not change during simulation. Static equations are calculated once. Namely at the beginning of the code. If a set-point would be used in the 20-Sim model to control a dependent state, the value of this set-point cannot change while the code is running. It is necessary to be able to alter set-points for sequence control. Altering the optimization of the generating of the code is not an option as this software is inaccessible because it is owned by Controllab Products

. Thus in order to prevent that the output of a set-point in a control loop is calculated in the static equations, a workaround is needed.

In order to solve this dynamic calculations problem, it is chosen to create an artificial state. By using integrators in the 20-Sim model instead of a set point, a dependent state can be repli- cated. Hence creating an artificial state. The output state of such an integrator is calculated in the dynamic calculation part of the C-code, each integration step. This means that the output state of such an integrator can be directly altered in order to control a set-point in a control loop.

Reading from the C-code to ROS

Data contained in the C-code can directly be read by ROS from the model equations. All states are compiled as float64 data types by 20-Sim 4C. A ROS standard message for float64 is avail- able. Depending on the application of the standalone software, multiple states can be com- bined to form more advanced ROS messages if necessary.

Thus considerations in the 20-Sim model, which need to be made when making the C-code standalone are:

• Set points in control loops are calculated outside of the dynamic equations. Integrators are used to create artificial states, which can be directly altered by ROS while the code is running.

• Reading from the code to ROS, is more straightforward. States can be directly published by ROS. Thus no changes need to be made in the 20-Sim model for reading from the code to other ROS nodes.

3.3 Generated C-code as a ROS node

When the C-code has been compiled and generated, it can be converted to a ROS node. Figure 3.2 shows an overview of the 20-Sim 4C ROS node.

In order for the generated C-code to run as a ROS node, the following considerations need te be taken into account:

1. Converting the generated C-code to C++.

2. Excluding the synchronization of the shared memory.

3. Placement of ROS publishing/subscribing in the C-code.

4. How to stop running the code and calculate final equations.

5. Lastly, synchronize time between ROS and the C-code.

CHAPTER 3. APPROACH 9

Figure 3.2: Overview of 20-Sim 4C ROS node with a sequence control node. Other ROS nodes can possibly be added. Any changes with respect to Figure 2.2 are indicated in bold. Note that the artificial

states are now calculated in the dynamic equations.

3.3.1 Converting C-code to C++

ROS only supports C++ and Python languages. Thus it is necessary to convert the C-code to C++. Luckily C-code is easily converted to C++. However some of the data conversions, which are made in the generated C-code are not valid anymore. For example type conversion from a void pointer to a char pointer or from a string to a char. These type conversions can easily be explicitly mentioned in the code to solve the problem.

3.3.2 Shared memory

The shared memory in the C-code is used for logging and control by 20-Sim 4C command and control software. Command and logging of data can obviously, when the code is converted to a ROS node, be done by ROS. Hence the shared memory does not have to be included when creating the standalone software.

3.3.3 Placement of ROS in the code

Another important consideration is the placement of ROS communication in the code. Pub-

lishing and subscribing to topics would obviously have to be performed every simulation step

in order to publish and subscribe to data, while the code is running. Additionally the reading

from and writing to other ROS nodes will have to be placed before the dynamic equations sec-

tion. This is because calculations would have to be performed after writing to the code by ROS is done, in order to, for example, use sequence control to alter a certain state. In addition, read- ing to and writing from hardware has to be done before data is read by ROS, as this would give the correct sensor data for that simulation step. Thus this means that, as the shared memory is excluded, publishing and subscribing should be placed right after the IO section of the code.

ROS will then act like another hardware in- or output in the code. This can be seen in Figure 3.2.

3.3.4 Final calculations

20-Sim 4C command and control software has control over when the code stops running and final equations are calculated. In order to have control over when the code should stop run- ning, a ROS implementation is necessary. Luckily this can easily be implemented, using a ROS function: ros::ok(). This will return false when it is shut down by ROS.

3.3.5 Loop frequency

Furthermore, the calculation of dependent states of the dynamic equations, runs at a certain frequency. This frequency is determined by the time step size specified in the integration method. Thus this step size is specified by 20-Sim 4C. If the time of ROS and the model cal- culations are not synchronized, the calculations run faster or slower leading to wrong outputs at a certain time in ROS. In order to prevent this, we need to make sure the loop is running at the same frequency as was intended. Fortunately, this can easily be done by setting the loop rate using ROS functions. This loop rate should then be set equal to the frequency, which was specified by the step size.

Thus for the generated C-code to run as a ROS node, the following modifications need to be made:

1. Convert the generated C-code to C++ by explicitly mentioning type conversions.

2. Excluding the synchronization of the shared memory from the C-code.

3. Placing of ROS publishing/subscribing is right after the reading/writing to and from hardware IO.

4. Using the ros::ok() function to have control over stopping the code from running.

5. Lastly, using ROS functions to synchronize time between ROS and the calculations in the C-code.

Now that the generated code is converted to a ROS node, next it is discussed how sequence control can be added using ROS.

3.4 Sequence control

Sequence control is added using a second ROS node. This node publishes sequence control

commands to a certain topic. The 20-Sim 4C ROS node is subscribed to this topic and hence

allowing for communication between the two. The message in the topic depends on the ap-

plication of the standalone software. Fortunately ROS includes many message types and thus

sequence control is highly customizable. Dependent states in control loops in the generated

C-code can be altered using the float64 type message. Supervisory control can additionally be

added using another ROS node. Furthermore all ROS nodes can be easily placed on different

devices. Thus supervisory control could easily be moved to a base station.

11

4 Case study

The approach specified in the previous chapter is applied to an example case study in order to show how the generated prototyping code can be converted to standalone software. The case study does not consider using ROS, 20-Sim and 20-Sim 4C to bring the software onto the ECC.

However prototyping code is generated and compiled from the 20-Sim model, using 20-Sim 4C. The standalone software is run on a development station, the same way as it would be on the ECC. Thus no hardware IO is considered. The focus is on the communication between the generated code and ROS.

In this chapter, first the model that was used for this case study, is described in Section 4.1.

In addition, the ROS structure and the sequence control node, which are developed for this case study, are described in Section 4.2. Next the 20-Sim 4C ROS node, which is the generated prototyping code converted to a ROS node, is further discussed in Section 4.3. Next, results from the case study are presented in Section 4.4. Lastly, a discussion of the results follows in Section 4.5.

4.1 20-Sim model: Cart with 2 wheels

An overview of the model is presented in Figure 4.1. The complete model is shown in Appendix A. The model consists of a cart with 2 wheels in a 2d plane. The 2 wheels are modelled by a second order system containing resistance and inertia in the electrical and rotational domain.

The velocity of both wheels is controlled by feedforward in combination with feedback, by a set linear- and angular-velocity of the cart. The position of the cart is calculated, which will be read by ROS. Furthermore, the angular- and linear velocity of the cart will be monitored by ROS. The model does not contain any external connection as no hardware IO is considered.

Figure 4.1: Overview of the 20-Sim model of the cart with 2 wheels, which was used for the case study.

As is shown in Figure 4.1, the angular- and linear velocity of the cart is set by artificial states.

These contain a set point with a value of zero and an integrator. The state of the output of these integrators, is calculated in the dynamic equations. Hence it can be altered while the C-code is running, allowing for sequence control. Sequence control is processed by another ROS node.

The ROS communication structure is discussed in the next section.

4.2 ROS communication overview 4.2.1 Overview

An overview of the ROS communication structure is presented in Figure 4.2. No hardware IO is considered.

Figure 4.2: Overview of ROS communication structure of the case study.

The sequence control ROS node publishes the set angular- and linear velocity in order to con- trol the cart. Loop control is used in order to achieve these set velocities, using the generated prototyping code from 20-Sim 4C. The node, which contains the 20-Sim 4C code, is subscribed to the topic containing the set velocities. Furthermore, the 20-Sim 4C ROS node publishes the current position and velocity of the cart. The current position, linear- and angular velocity are calculated in the model equations.

4.2.2 Topics

The sequence control commands consist of a set point for linear- and angular velocity. In order to show several ROS messages, which are being used, a twist message is used in order to pub- lish this data. The ROS twist message consists of 2 vectors which specify linear- and angular velocity for the x-, y- and z-direction, consisting of float64 data type. Only the linear velocity in x-direction and angular velocity in z-direction are used. Furthermore, the position of the cart is published by the 20-Sim 4C ROS node. For this data, a point message is used, which consists of x-,y-, and z-coordinates, which are of type float 64 as well. Only x- and y-position are used.

For linear- and anguar velocity of the cart itself, standard ROS float64 messages are used.

4.2.3 Sequence control node

The sequence control node alters the set-point of the control loop by publishing sequence con- trol commands for linear- and angular velocity. When this node is run, a duration, linear- and angular velocity can be specified by the user. The duration specifies for how long the node should publish the sequence control commands. After the duration has past, the node will stop publishing and shut down. The 20-Sim 4C ROS node is subscribed to these sequence control commands.

4.3 The 20-Sim 4C ROS node

The set points for controlling linear- and angular velocity of the cart, specified by the sequence

control ROS node, are used by the 20-Sim 4C ROS node. Prototyping code was generated from

the 20-Sim model using 20-sim 4C. As described in the approach in Section 3.3, the generated

CHAPTER 4. CASE STUDY 13

The 20-Sim 4C ROS node is subscribed to a topic, which specifies the set linear- and angular velocity the cart should control towards. The 20-Sim 4C ROS node publishes the current posi- tion, linear- and angular velocity of the cart, which are calculated in the model equations. The value of the output state of the integrators, which specify the set linear- and angular velocity in the control loop, can be directly altered in order to allow for sequence control.

4.3.1 Loop frequency

In this case, a RungaKutta integration method was used to calculate dependent states. The step size, which is specified in the code, is 0.01 seconds. Therefor the dynamic equations should be calculated at a frequency of 100hz. This was made sure by using the ros::Rate loop_rate() function to specify the loop rate. The ROS function loop_rate.sleep() was used to set the loop rate to 100Hz. Dynamic equations now are calculated at a frequency of 100Hz.

4.4 Results

Next, the results of the case study are presented, in order to show the working of the commu- nication of the standalone software. A standalone software ROS package was developed. This package contains both the ROS node for sequence control and the ROS node including the generated prototyping C-code. This package was run on a development computer.

4.4.1 Communication between nodes

First the ROS structure including all topics and nodes is shown. ROS contains a tool in order to quickly provide a visualization of the ROS communication structure. The ROS communication structure is shown in Figure 4.3.

Figure 4.3: Overview of ROS communication structure shown by rqt_graph, which is the visualization tool from ROS showing all topics and nodes. Note that this is similar to Figure 4.2. The ROS master is

not shown.

Next, the data of the topics containing the position, angular- and linear velocity is compared to the 20-Sim simulation in order to see whether there are any differences.

4.4.2 Data output of the 20-Sim 4C ROS node

ROS tools exist in order to monitor and log data from topics. The standalone software ROS

package was run on a development computer. The sequence control node was run with a du-

ration of 10 seconds, a linear velocity set point of 1 m/s and an angular velocity set point of

0.5 m/s. This means that the cart will be controlled to these set velocity points and remain at

that velocity until 10 seconds have past. The ROS function rqt_plot allows for easily logging

and plotting of data from topics. The linear- and angular velocity of the cart are plotted using

rqt_plot. This is shown in Figure 4.4.

Figure 4.4: ROS rqt_plot of the velocity of the cart. The simulation lasted 10 seconds in which the veloc- ities remained constant the rest of the time.

A launch file was used in order to start both nodes at the same time in ROS. As shown in Fig- ure 4.4, rqt_plot starts its time axis at zero when the tool is first started. Hence the nodes where started at 3.6 seconds. In order to compare the velocity of the cart from ROS to the velocity sim- ulated in 20-Sim, ROS tool rqt_bag is used. Unlike rqt_plot, rqt_bag starts logging data when the tool first receives a message. Hence it will start at time zero. However before the first mes- sage is received, it will need some time to setup the subscription to the topic, which is recorded.

This is further discussed in Section 4.5. Furthermore the 20-Sim model was simulated for 10 seconds as well, with the same velocities. This is shown in Figure 4.5.

The corresponding position plot of ROS and the 20-Sim simulation is presented in Figure 4.6.

CHAPTER 4. CASE STUDY 15

(a) 20-Sim plot of the velocity of the cart.

(b) ROS tools rqt_bag and Plotjuggler are used to log and plot the data from the velocity topics.

Figure 4.5: Linear- and angular velocity of the cart. ROS function rqt_bag is used to log the data of topics

and Plotjuggler for plotting the data. The sequence control node and 20-Sim simulation where both run

for 10 seconds, in which the velocities remained constant the rest of the time.

(a) 20-Sim plot of the position of the cart.

(b) ROS plot of the position of the cart. ROS tool "rqt_multiplot" was used.

Figure 4.6: Corresponding position of the cart of the simulation of Figure 4.5. The set point for the linear velocity was 1m/s and 0.5m/s for the angular velocity. The duration of the sequence control node was 10 seconds.

The position output from ROS, after 10 seconds, is compared to the position of the cart when

simulated with 20-Sim for 10 seconds as well. This is done for several velocity set points. This

is shown in Table 4.1 and 4.2.

CHAPTER 4. CASE STUDY 17

Table 4.1: Position of the cart after 10 seconds for several velocities, simulated in 20-Sim

Angular velocity (m/s)

0 2 4

Li n ear v el ocit y (m/ s) 0 x = 0 x = 0 x = 0 y = 0 y = 0 y = 0 2 x = 19.87 x = 0.87 x = 0.43

y = 0 y = 0.51 y = 0.76 4 x = 39.74 x = 1.74 x = 0.86 y = 0 y = 1.01 y = 1.51 6 x = 59.61 x = 2.60 x = 1.29 y = 0 y = 1.52 y = 2.27

Table 4.2: Position of the cart after 10 seconds using ROS.

Angular velocity (m/s)

0 2 4

L in ear v el ocit y (m/ s) 0 x = 0 x = 0 x = 0 y = 0 y = 0 y = 0 2 x = 19.75 x = 0.87 x = 0.49

y = 0 y = 0.50 y = 0.60 4 x = 39.65 x = 1.73 x = 0.86 y = 0 y = 1.01 y = 1.50 6 x = 59.54 x = 2.57 x = 1.45 y = 0 y = 1.46 y = 1.87

The position of the cart after 10 seconds when simulated using the standalone software is not

exactly the same as the simulation in 20-Sim. Therefor a discussion follows in which the dif-

ferences are examined. But first it is shown that the set-points can be altered while the code is

running.

4.4.3 Processing ROS input

A launch file was created, which first runs the sequence control node for 10 seconds with a linear velocity set point of 1 m/s and an angular velocity set point of 0.5 m/s. After 10 seconds the angular velocity is changed to -0.5m/s. The linear velocity remains the same as in the first 10 seconds. The position of the cart is shown in Figure 4.7.

Figure 4.7: Position of the cart while a set-point in a control loop is altered whilst the code is running.

After 10 seconds the angular velocity of the cart is changed from 0.5m/s to -0.5m/s. Linear velocity remains 1 m/s.

As is presented in Figure 4.7, it is shown that it is possible to alter set-points of control loops

whilst running the generated C-code as a ROS node.

CHAPTER 4. CASE STUDY 19

4.5 Discussion

The position of the cart after 10 seconds is slightly different when simulated using ROS than when simulated using 20-Sim. This is caused due the communication between the sequence control node and the 20-Sim 4C ROS node. It takes some time before the publisher-subscriber system between the nodes is set up. Because the sequence control node first has to advertise its intent to publish on the velocity topic. A launch file was used to start both nodes at the same time. However the 20-Sim 4C ROS node only starts receiving the set points for linear- and angular velocity after about 0.18 seconds. This is also presented in Figure 4.4, where rqt_plot was used. From 3.6 seconds to about 3.78 the velocity is a constant zero, whilst in the 20- Sim simulation this is not the case for the first 0.18 seconds. The sequence control node will however still only run for 10 seconds, due to the duration that was specified. Thus this leads to a slightly different position after 10 seconds as the 20-Sim 4C ROS node does not receive sequence control commands for the first 0.18 seconds.

In Figure 4.5, rqt_bag is used to log the data from both velocity topics. However rqt_bag starts logging data when the first message is received by the tool. Before the first message is received, data is already published to the topic that will be recorder. Therefor, about the first 0.2 seconds are not logged. Thus the plot in Figure 4.5b is very similar to Figure 4.5a.

The case study has shown the working of the approach described in Chapter 3. As is shown

in Figure 4.5 and Figure 4.6, the output from the 20-Sim 4C ROS node is very similar to the

simulation in 20-Sim. The generated prototyping code was successfully converted to a ROS

node and a second node was added in order to illustrate sequence control.

5 Conclusion and recommendations

5.1 Conclusion

The approach on how to convert the generated prototyping code from 20-Sim 4C, has been applied to a case study. Using the knowledge acquired from the case study, conclusions can now be drawn about the approach. The main research question of this study stated in Chapter 1 is:

What considerations need to be made in order to make the generated prototyping code from 20- Sim 4C standalone?

First of all, this consists of replacing the 20-Sim 4C command and control software with an alternative software framework. For this alternative software framework, the Robot Operating System (ROS) was used.

Secondly, communication between ROS and the generated prototyping code is set up. Conse- quently, the prototyping code was converted to a ROS node. Now the prototyping code per- forms the hard-real time control whereas ROS performs the soft-real time control. In order to convert the prototyping code to a ROS node, the following considerations are important:

1. Convert the generated C-code to C++ by explicitly mentioning type conversions.

2. Excluding the synchronization of the shared memory from the C-code.

3. Placing of ROS publishing/subscribing is right after the reading/writing to and from hardware IO.

4. Using the ros::ok() function to have control over stopping the code from running.

5. Lastly, using ROS functions to synchronize time between ROS and the calculations in the C-code.

Further consideration needs to be made in the communication between ROS and the gener- ated prototyping code. In order to alter set-points in control loops in the C-code, artificial states need to be created to make sure the state of the set-point is not calculated in the static equations.

Supervisory- and sequence control can easily be designed and added using ROS. However do consider that the communication between nodes takes time to set-up. The subscriber- publisher communication between nodes does take time to set-up, because the publisher node has to advertise its intent to publish on a certain topic. This is something to consider when se- quence control in a ROS node is used to alter the dependent states in another node containing all model equations, as is done in this study.

In conclusion, this study has shown which considerations need to be made in order to convert

the generated prototyping C-code from 20-Sim 4C to standalone software. Prototyping soft-

ware from 20-Sim 4C can now be made standalone using the approach which was shown in

Chapter 3. However the focus of the study was on the communication between ROS and the

generated prototyping code.

CHAPTER 5. CONCLUSION AND RECOMMENDATIONS 21

5.2 Further recommendations

Hardware IO and a physical system where not considered during this study. Therefor, further recommendation include using this method of making the prototyping code standalone when, in addition, considering a real physical plant. ROS, 20-Sim and 20-Sim 4C will then have to be used to bring the standalone software on the ECC of the prototype. This could be seen in Figure 1.2.

Initial testing was performed using the Segway known from module 6 of the EE bachelor. In or- der to bring the standalone software onto the ECC of the Segway, an operating system including hardware IO drivers and a ROS installation is necessary. An operating system (OS) using Yocto- project

is already developed for the Segway. This operating system includes all the hardware drivers necessary for all the sensors and actuators of the Segway. Operating systems build with Yoctoproject are build using layers. A layer for ROS already exist, which can be added to the layer containing all hardware drivers, to create an OS that contains all ROS functions and tools.

Unfortunately, the ROS layer is not well supported and outdated making it difficult to create such an operating system. However, when this layer is added, the standalone software can be installed on the ECC.

The study can be expanded by seeing which considerations need to be made when the stan- dalone software is run on the ECC of the Segway. ROS allows for easily moving nodes across de- vices and adding nodes. Considerations such as the placement of nodes can be studied. Nodes can be run on a base station in order to reduce computational requirements on the hardware of the prototype. Lastly, communication speed between nodes can be studied. When nodes across devices have to communicate, it might be that the latency would become to large for the ECS to work properly.

1https://www.yoctoproject.org/

A Appendix: Case study model

A.1 20-Sim model case study

23

B Appendix: Demonstration instructions

Assuming a working version of ROS melodic is installed, running the standalone software is done by executing the following steps:

1. Copy the ROS package including the sequence control node and the 20-Sim 4C ROS node in the "src" folder of the "catkin_ws" folder.

2. Run the following commands in terminal:

 

$ cd ~/ catkin_ws /

$ catkin_make

 

The package including executables will now be build.

3. Start the ROS master:

 

$ roscore

 

4. Open a new terminal and source the "setup.bash" file in order to be able to run newly build executables:

 

$ cd ~/ catkin_ws /

$ source devel / setup . bash

 

5. Now the 20-Sim 4C ROS node can be run from terminal, by using the "rosrun" command:

 

$ rosrun standalone_software_package ROSnode_20sim

 

6. In order to run another node open a new terminal and again source the "setup.bash" file.

Now the sequence control node can be run. A linear-, angular velocity and duration in seconds can be entered respectively

 

$ rosrun standalone_software_package ROSnode_20sim 5 2 10

 

This example specifies a linear velocity of 5 m/s, a angular velocity of 2m/s and a duration of 10s.

7. By using "rqt_plot" or "rostopic echo" commands, data can be plotted and monitered

using ROS.

Bibliography

Bezemer, M. M. and J. F. Broenink (2015), Connecting ROS to a real-time control framework for embedded computing, in 2015 IEEE 20th Conference on Emerging Technologies Factory Automation (ETFA), pp. 1–6, ISSN 1946-0740, doi:10.1109/ETFA.2015.7301648.

Broenink, J. and Y. Ni (2012), Model-Driven Robot-Software Design using integrated Models and Co-Simulation, in International Conference on Embedded Computer Systems, SAMOS 2012, Eds. J. McAllister and S. Bhattacharyya, IEEE Computer Society, United States, pp. 339–

344, ISBN 978-1-4673-2296-6.

Broenink, J. and P. Weustink (1996), A combined-system simulator for mechatronic systems, in Modelling and Simulation 1996. ESM’96, pp. 225–229.

Bruyninckx, H. (2001), Open robot control software: the OROCOS project, in Proceedings 2001 ICRA. IEEE International Conference on Robotics and Automation (Cat. No.01CH37164), vol- ume 3, pp. 2523–2528 vol.3, ISSN 1050-4729, doi:10.1109/ROBOT.2001.933002.

Bruyninckx, H., P. Soetens and B. Koninckx (2003), The real-time motion control core of the Orocos project, in 2003 IEEE International Conference on Robotics and Automation (Cat.

No.03CH37422), volume 2, pp. 2766–2771 vol.2, ISSN 1050-4729, doi:10.1109/ROBOT.2003.

1242011.

Groothuis, M. (2001), 20-sim code generation for PC/104 target, Individual Design Report, no 009R2001, University of Twente, Enschede.

Groothuis, M., R. Frijns, J. Voeten and J. Broenink (2009), Concurrent Design of Embedded Con- trol Software, in Proceedings of the 3rd International Workshop on Multi-Paradigm Modeling (MPM2009), Eds. T. Margaria, J. Padberg, G. Taentzer, T. Levendovszky, L. Lengyel, G. Karsai and C. Hardebolle, European Association for the Study of Science and Technology, Nether- lands, Electronic Communications of the EASST, p. 10, ISBN 1863-2122.

Metta, G., P. Fitzpatrick and L. Natale (2006), YARP: Yet another robot platform, in International Journal of Advanced Robotic Systems, no009R2001, volume 3, doi:10.5772/5761.

Oosterom, H. P. (2006), On the verification of real-time distributed embedded control systems MSc Report.

Quigley, M., K. Conley, B. P Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler and A. Y Ng (2009), ROS: an open-source Robot Operating System, in ICRA Workshop on Open Source Software, volume 3.

van der Werff, W. M. and J. F. Broenink (2015 & 2016), Connecting Two Robot-Software Commu-

nicating Architectures: ROS and LUNA, in Communicating Process Architectures, IOS press,

Enschede, pp. 359 – 378, ISBN 978-1-61499-886-0.