Haalbaarheidsstudie van ROS2 als basis voor de sturing van AGV's

i

CONFIDENTIAL UP TO AND INCLUDING 31/12/2029 - DO NOT COPY, DISTRIBUTE OR MAKE PUBLIC IN ANY WAY

Haalbaarheidsstudie van ROS2 als basis voor de

sturing van AGV’s

Jens Lepers

Student number: 01810360

Supervisors: Dieter Vandenhoeke, Ir. Glenn Aesaert (Vintecc)

Master's dissertation submitted in order to obtain the academic degree of Master of Science in de industriële wetenschappen: elektrotechniek Academic year 2019-2020

iii

CONFIDENTIAL UP TO AND INCLUDING 31/12/2029 - DO NOT COPY, DISTRIBUTE OR MAKE PUBLIC IN ANY WAY

Haalbaarheidsstudie van ROS2 als basis voor de

sturing van AGV’s

Jens Lepers

Student number: 01810360

Supervisors: Dieter Vandenhoeke, Ir. Glenn Aesaert (Vintecc)

Master's dissertation submitted in order to obtain the academic degree of Master of Science in de industriële wetenschappen: elektrotechniek Academic year 2019-2020

iv

Voorwoord

Deze thesis “Haalbaarheidsstudie van ROS2 als basis voor de sturing van AGV’s” werd geschreven in samenwerking met het bedrijf Vintecc. Ik ben masterstudent industriële wetenschappen afstudeerrichting automatisering en de masterproef is een cruciaal onderdeel in deze opleiding.

Ik hoop met deze thesis u als lezer ervan te overtuigen dat er meerdere mogelijkheden zijn om een automatiseringsproject aan te pakken. Vaak kan een resultaat bereikt worden via een traditionele aanpak, maar het is uitdagend om nieuwe methodes te integreren in bestaande projecten.

Graag zou ik Vintecc willen bedanken om mij de kans te geven om deze masterproef uit te werken. Daarnaast wil ik mijn externe promotor, Glenn Aesaert, bedanken voor de ondersteuning en inbreng tijdens het uitwerken van dit project. Ik bedank ook graag mijn interne promotor, Dieter Vandenhoeke, voor de begeleiding tijdens mijn masterproef. Tenslotte bedank ik mijn ouders en vriendin voor de steun en voor het nalezen van deze thesis.

Jens Lepers Kortrijk, Mei 2020

v

Preambule

Deze masterproef is een opdracht gemaakt in de periode van september 2019 tot en met mei 2020. Dit betekent dat de Covid-19 pandemie een invloed heeft gehad op dit project. Het gaat hier vooral over een software project, het was dus mogelijk om een groot deel van het onderzoek thuis te doen. Oorspronkelijk was er een doelstelling om een vergelijkende studie te maken tussen ROS en ROS2 en dit te testen op een pallet shuttle. Het was niet mogelijk om zo’n shuttle thuis te gebruiken dus werd de software getest op een kleinere testopstelling. Een uitgebreide vergelijkende studie maken was hierdoor ook niet mogelijk.

Een goede communicatie met de promotoren is belangrijk. Het is noodzakelijk om tijdens het project de nodige feedback te krijgen. Dit werd in deze periode grotendeels opgevangen via email en videocalls, maar het thuis werken heeft toch een negatieve impact gehad op de productiviteit.

vi

Abstract

Deze masterproef kadert in een groter project waarin een magazijn autonoom werkt aan de hand van een pallet shuttlesysteem. In de plaatst van een klassieke PLC sturing te gebruiken voor de AGV’s, wordt het Robot Operating System (ROS) gebruikt. In 2017 verscheen de nieuwe versie van ROS: ROS2. Deze thesis onderzoekt wat de mogelijkheden zijn van de nieuwe middleware en hoe deze best in het project geïntegreerd wordt. Een pallet shuttle beschikt over twee motoren en verschillende sensoren die in verbinding staan met een centrale controller. De sensoren worden via EtherCAT ingelezen en de motoren worden via CANopen aangestuurd. Om de communicatie tot stand te brengen, worden er verschillende ROS2 nodes geprogrammeerd. Een node is een proces dat berichten kan versturen en ontvangen in een ROS2 netwerk.

De masterproef focust zich op het implementeren van een CANopen node die zorgt voor de communicatie tussen de motoren en de controller. Eerst zal een literatuurstudie nodig zijn om de werking van de middleware te begrijpen. Een vergelijkende studie tussen ROS en ROS2 zal helpen bij het omzetten van bestaande ROS nodes. Als laatste zal de nieuwe CANopen node geïntegreerd worden in het ROS2-framework.

Vooraleer er kan gestart worden met het programmeren, moet er een uitgebreide studie gemaakt worden over ROS2. Deze robot middleware is relatief onbekend in de huidige industrie, maar is veelbelovend naar de toekomst toe. Het is een framework dat meerdere tools en libraries bevat waardoor het programmeren van robotica software flexibeler wordt. ROS2 kan geprogrammeerd worden in meerdere talen en is beschikbaar op verschillende Operating Systems. In deze masterproef ligt de focus op de C++ implementatie in een Linux omgeving.

De communicatie tussen ROS2 nodes kan op twee manieren: via messages en/of services. Beide mogelijkheden kunnen gebruikt worden in dit project en worden dus onderzocht. Een ROS2 message werkt volgens het producer-consumer model. Data wordt gepubliceerd volgens een bepaalde topic en één of meerdere nodes kunnen zich hierop abonneren. Een ROS2 service werkt volgens het client-server model. Een client kan een request sturen naar een server en deze antwoordt dan met een bepaalde response. De services worden gebruikt om te communiceren met de motor.

CANopen is volgens het OSI-model de applicatielaag die zich bovenop het CAN protocol bevindt. CANopen bevat twee communicatie profielen: CiA 301 en CiA 402. Basis gegevens en functionaliteiten worden meegegeven met het 301 profiel terwijl het 402 profiel gebruikt wordt voor motion control. CANopen maakt gebruik van een stateflow om via een status- en controlewoord met de motor te communiceren.

De logica van dit project wordt gecreëerd in een Simulink model. Simulink bevat een Stateflow toolbox die gebruikt kan worden om de werking van de motoren te programmeren. De kennis van ROS2 messages kan gebruikt worden om te communiceren met de CANopen node. Eerst wordt er bepaald welke CANopen parameters er nodig zijn om de motor te sturen. Deze worden dan verstuurd in een zelf ontworpen ROS2 message. Als de volledige werking getest is in simulatie mode, kan het Simulink model omgevormd worden tot een ROS2 node. De pallet shuttle kan dan werken door zowel de CANopen node als de Simulink node te runnen in hetzelfde ROS2 netwerk.

vii

Na de implementatie van de voorgenoemde nodes op een testopstelling, was het mogelijk om een motor te sturen via ROS2 en CANopen. Het is dus wel degelijk mogelijk om een industriële AGV te sturen via ROS2. Er moet echter nog een grondige studie gebeuren rond de realtime werking van ROS2 en rond de safety voorwaarden waaraan de ROS2-opstelling moet voldoen. ROS2 zit nog in een ontwikkelingsfase waardoor nog niet alle safety tools geïmplementeerd zijn. Naast de traditionele PLC sturing, wordt ROS2 zeker een goed alternatief om automatiseringsprojecten aan te pakken. Het is echter de toekomst die zal uitwijzen wat het volledige potentieel van deze robot middleware zal zijn.

viii

I.

INLEIDING

A.

Vintecc

Vintecc is een bedrijf dat gespecialiseerd is in het

ontwikkelen van machine software voor industriële

en mobiele toepassingen. Het doel van Vintecc is de

automatiseringsprocessen van hun klanten te

versnellen en te verbeteren door software op maat

te ontwikkelen.

B.

Pallet Shuttlesysteem

In vele bedrijven is er vraag naar een efficiënt

werkend magazijn met een optimale

opslag-capaciteit. Een geautomatiseerd magazijn op basis

van een pallet shuttlesysteem is een innovatieve

oplossing voor deze opslag problematiek.

Een pallet shuttle beschikt over twee motoren en

verschillende sensoren die in verbinding staan met

een centrale controller. De sensoren worden via

EtherCAT ingelezen en de motoren worden via

CANopen aangestuurd.

In de plaatst van een klassieke PLC sturing te

gebruiken, wordt het Robot Operating System (ROS)

gebruikt om deze AGV’s te sturen. In 2017 verscheen

de nieuwe versie van ROS: ROS2. Deze hernieuwde

versie mag niet gezien worden als een uitbreiding

van ROS, het platform is gebaseerd op een volledig

nieuwe data architectuur. De ontwikkelaars hebben

zich hiervoor gebaseerd op het DDS-protocol (Data

Distributed Services).

C.

ROS2

D.

ROS2

ROS2 is een robot middleware die relatief onbekend

is in de huidige industrie. Het is een framework dat

meerdere tools en libraries bevat waardoor het

programmeren van robotica software flexibeler

wordt. ROS2 kan geprogrammeerd worden in

meerdere talen en is beschikbaar op verschillende

Operating Systems.

Figuur 1: Logo ROS2

Een node is een proces binnen ROS2 dat berichten

kan versturen en ontvangen. Het is een

geprogrammeerde

logica

die

dus

kan

communiceren met andere deelnemers in hetzelfde

netwerk. De communicatie tussen ROS2 nodes kan

op twee manieren: via messages en/of services.

Een ROS2 message werkt volgens het producer-

consumer model. Data wordt gepubliceerd volgens

een bepaalde topic en één of meerdere nodes

kunnen zich hierop abonneren. Een ROS2 service

werkt volgens het client-server model. Een client

kan een request sturen naar een server, waarop

deze antwoordt met een bepaalde response.

Haalbaarheidsstudie

van ROS2 als basis voor de

sturing van AGV’s

Student: Jens Lepers

Promotoren: Glenn Aesaert, Dieter Vandenhoeke

ix

E.

CANopen

CANopen is volgens het OSI-model de applicatielaag

die zich bovenop het CAN protocol bevindt. CANopen

bevat twee communicatie profielen: CiA 301 en CiA

402. Basis gegevens en functionaliteiten worden

meegegeven met het 301 profiel terwijl het 402

profiel gebruikt wordt voor motion control.

Figuur 2: CANopen binnen het OSI-model [1]

II. D

OELSTELLINGEN

Het doel van de masterproef is tweeledig. Ten eerste

dient een studie gemaakt te worden van ROS2. De

middleware moet volledig begrepen worden

vooraleer er kan overgegaan worden tot de

implementatie ervan. Ten tweede wordt een

werkende testopstelling (AGV) verwacht die de

werking van ROS2 kan aantonen. Een vergelijkende

studie tussen ROS en ROS2 zal helpen bij het

omzetten van bestaande ROS nodes.

De masterproef focust zich op het implementeren

van de CANopen node in een ROS2 netwerk. Deze

zorgt voor de communicatie tussen de motoren en

het Simulink model.

Een werkende CANopen node is de belangrijkste

output van deze masterproef. Deze zal dan verder

gebruikt worden binnen Vintecc in meerdere

projecten. De geschreven thesis zal dienen als

ondersteuning bij het maken van toekomstige ROS2

nodes.

III. R

ESULTATEN

A.

Stateflow

CANopen maakt gebruik van een stateflow om een

motor via een status- en controlewoord te sturen.

Simulink bevat een Stateflow toolbox die zal gebruikt

wordt om de volledige werking van de motoren te

programmeren.

Figuur 3: Stateflow CANopen

B.

ROS_CANOPEN

ROS2

bevat

ondersteuning

om

code

te

implementeren op een CANopen interface. Om code

te kunnen versturen, is er een ros_canopen master

nodig. Dit is een gelaagde structuur die bovenop de

SocketCAN interface geprogrammeerd is. SocketCAN

is een open source CAN driver die in de Linux kernel

geïmplementeerd is. Figuur 4 geeft de structuur

weer van de ros_canopen master met de bijhorende

profielen.

De canopen_chain_node bevat de nodige code om

de server op te starten, er moet nu alleen nog een

client geprogrammeerd worden. De services die

ros_canopen aanbiedt zijn acties waarmee er kan

gecommuniceerd worden over het CANopen

netwerk. De twee belangrijkste services hier zijn

GetObject en SetObject, deze worden gebruikt om

data te schrijven en op te vragen uit het apparaat.

x

Figuur 4: Overzicht ros_canopen master [2]

C.

Quality of Service

Data opgevraagd uit de motor kan nu verstuurd

worden naar het Simulink model via ROS2 messages.

Een

nieuwe

toevoeging

in

ROS2

is

dat publishers en subscribers gebruik maken van

QoS-profielen. Quality of Service is een verzameling

van parameters die het gedrag van de ROS2

communicatie bepaalt.

Figuur 5: Quality of Service parameters

ROS2 zit nog in de ontwikkelingsfase, enkel de gele

parameters zijn al geïmplementeerd.

D.

Testopstelling

De werking van de CANopen node wordt getest op

een MDrive motor. Deze is verbonden met een IPC

waarop de nodes draaien in een Linux omgeving. Na

het testen, kan de IPC verbonden worden met de

motoren van de pallet shuttle.

IV. B

ESLUIT

Figuur 6 geeft de latency weer van ROS2 bij een

variërende data grootte. Het is duidelijk zichtbaar dat

er een significante hoeveelheid data nodig is om DDS

om te zetten naar ROS2. Puur afgaand op de latency

grafieken, lijkt ROS een betere keuze. De impact van

de QoS op de performantie van de communicatie

geeft echter de doorslag wat doet besluiten dat ROS2

wel degelijk een verbetering is.

Figuur 6: Breakdown of ROS2 latencies [3]

Na de implementatie van de voorgenoemde nodes

op een testopstelling, was het mogelijk om een

motor te sturen via ROS2 en CANopen. Het is dus wel

degelijk mogelijk om een industriële AGV te sturen

via ROS2. Er moet echter nog een grondige studie

gebeuren rond de realtime werking van ROS2 en

rond de safety voorwaarden waaraan de

ROS2-opstelling moet voldoen. Naast de traditionele PLC

sturing, wordt ROS2 zeker een goed alternatief om

automatiseringsprojecten aan te pakken. Het is

echter de toekomst die zal uitwijzen wat het

volledige potentieel van deze robot middleware zal

zijn.

V. R

EFERENTIES

[1] CSS Electronics, csselectronics.com [online]. Beschikbaar: https://www.csselectronics.com/ screen/page/canopen-tutorial-simple-intro/language/en [geraadpleegt op 28/04/2020].

[2] Weisshardt Florian, Lüdtke Mathias, Wiki.ROS.com [online]. Beschikbaar: http://wiki.ros.org/ros_canopen? Distro = melodic .[geraadpleegt op 28/04/2020].

[3] Y. Maruyama, S. Kato, T. Azumi, “Exploring the performance of ROS2”, Tokyo , Oct. 2016

xi

I.

INTRODUCTION

A.

Vintecc

Vintecc is a company that specializes in developing

machine software for industrial and mobile

applications. Vintecc's goal is to accelerate and

improve their customers' automation processes by

developing custom software.

B.

Pallet Shuttlesystem

In many companies there is a demand for an efficient

working warehouse with an optimal storage

capacity. An automated warehouse based on a pallet

shuttle system is an innovative solution for this

storage problem.

A pallet shuttle has two motors and different sensors

that are connected to a central controller. The

sensors are read in via EtherCAT and the motors are

controlled via CANopen.

Instead of using a PLC to control the AGVs, the Robot

Operating System (ROS) is used. ROS2, the new

version of ROS, was released in 2017 and will be used

in this project. This renewed version should not be an

extension of ROS, the platform is based on a

completely new data architecture. The developers

have based themselves on the DDS (Data Distributed

Services) protocol.

C.

ROS2

D.

ROS2

ROS2 is a robot middleware that is relatively

unknown in today’s industry. It is a framework that

contains multiple tools and libraries which makes

programming robot software more flexible. ROS2

can be programmed in multiple languages and is

available on different Operating Systems.

Picture 2: Logo ROS2

A node is a process that can send and receive

messages in a ROS2 network. Communication

between ROS2 nodes can be done by messages and

/or services. Both possibilities can be used in this

project and are therefore being investigated.

A ROS2 message works according to the

producer-consumer model. Data is published with a specific

topic and other nodes can subscribe to it. A ROS2

service works according to the client-server model. A

client can send a request to a server and it will reply

with a certain response.

Student: Jens Lepers

Promoters: Glenn Aesaert, Dieter Vandenhoeke

In cooperation with: Vintecc

Academic year 2019- 2020

Feasibility study of ROS2 as a foundation for

controlling AGV’s

xii

E.

CANopen

According to the OSI model, CANopen is the

application layer that is used on top of the CAN

protocol. CANopen contains two communication

profiles: CiA 301 and CiA 402. Basic data and

functionalities are stored in the 301 profile while the

402 profile is used for motion control.

Picture 2: CANopen in the OSI-model [1]

II.

OBJECTIVES

This thesis has two main objectives. The first goal is

to make a study of ROS2. The middleware must be

fully understood before it can be implemented in the

project. The second goal is to make a working test

setup where an AGV is working with ROS2. A

comparative study between ROS and ROS2 will help

to convert existing ROS nodes.

The master thesis focuses on the implementation of

a CANopen node in a ROS2 network. This node will

establish the communication between the motors

and the Simulink model.

A working CANopen node is the main output of this

master thesis. This will then be used further within

other projects. The written thesis will support the

creation of future ROS2 nodes.

III. R

ESULTS

A.

Stateflow

CANopen uses a stateflow to communicate with the

motors via a statusword and a controlword. Simulink

contains a Stateflow toolbox that can be used to

program the motors.

Picture 3: Stateflow CANopen

B.

ROS_CANOPEN

ROS2 supports implementing code on a CANopen

interface. A ros_canopen master is required to

communicate via CANopen. This is a layered

structure that is programmed on top of the

SocketCAN interface. SocketCAN is an open source

CAN driver that is implemented in the Linux kernel.

Picture 4 shows the structure of the ros_canopen

master with the associated profiles.

The canopen_chain_node contains the necessary

code to start a server. The client needs to be

programmed separately. The services offered by

ros_canopen allow the user to communicate with

the CANopen network. The two main services here

are GetObject and SetObject, which are used to write

and retrieve data from the device.

xiii

Picture 4: The ros_canopen master [2]

C.

Quality of Service

Data retrieved from the motor can now be sent to

the Simulink model via ROS2 messages. A new

addition in ROS2 is that publishers and subscribers

are able to use QoS-profiles. Quality of Service is a

collection of parameters that have an impact on the

behavior of the ROS2 communication.

Picture 5: Quality of Service parameters

ROS2 is still in development, only the yellow

parameters have already been implemented.

D.

Test setup

The CANopen node is tested on an MDrive motor.

This is connected to an IPC on which the nodes run in

a Linux environment. After testing, the IPC can be

connected to the motors of the pallet shuttle.

VI. C

ONCLUSION

Picture 6 shows the latency of ROS2 at a varying data

size. It is clearly visible that a significant amount of

data is required to convert DDS to ROS2. Judging

purely from the latency charts, ROS seems to be a

better choice. However, the impact of the QoS on the

performance of the communication is decisive,

which means that ROS2 is indeed an improvement.

Picture 6: Breakdown of ROS2 latencies [3]

After the implementation of the programmed nodes

on a test setup, it was possible to control a motor. It

is therefore possible to control an industrial AGV via

ROS2 and CANopen. However, a study still needs to

be done on the real-time operation of ROS2. Is the

middleware able to meet all the necessary safety

conditions? ROS2 is still in a development phase, so

for the moment not all safety features have been

implemented yet. ROS2 is a good alternative to

tackle automation projects. However, it is the future

that will reveal the full potential of this robot

middleware.

VII. R

EFERENCES

[1] [1 _{CSS Electronics, csselectronics.com [online]. Beschikbaar:} https://www.csselectronics.com/ screen/page/canopen-tutorial-simple-intro/language/en [geraadpleegt op 28/04/2020].

[2] Weisshardt Florian, Lüdtke Mathias, Wiki.ROS.com [online]. Beschikbaar: http://wiki.ros.org/ros_canopen? Distro = melodic .[geraadpleegt op 28/04/2020].

[3] Y. Maruyama, S. Kato, T. Azumi, “Exploring the performance of ROS2”, Tokyo , Oct. 2016

1

Inhoudsopgave

1

INLEIDING... 7

1.1. Voorwoord ... Fout! Bladwijzer niet gedefinieerd. 1.2. Bedrijfsvoorstelling ... Fout! Bladwijzer niet gedefinieerd. 1.3. Projectvoorstelling ... 43

2

DOELSTELLINGEN ... FOUT! BLADWIJZER NIET GEDEFINIEERD.

3

PROJECT ANALYSE ... FOUT! BLADWIJZER NIET GEDEFINIEERD.

3.1. Pallet Shuttle ... Fout! Bladwijzer niet gedefinieerd. 3.2. Testopstelling ... Fout! Bladwijzer niet gedefinieerd.

4

ETHERCAT ... FOUT! BLADWIJZER NIET GEDEFINIEERD.

4.1. Inleiding ... Fout! Bladwijzer niet gedefinieerd. 4.2. Ethernet realtime ... Fout! Bladwijzer niet gedefinieerd. 4.2.1. Master-slave ... Fout! Bladwijzer niet gedefinieerd. 4.2.2. One-Total-Frame ... Fout! Bladwijzer niet gedefinieerd. 4.2.3. EtherCAT dataframe ... Fout! Bladwijzer niet gedefinieerd. 4.2.4. Adressering ... Fout! Bladwijzer niet gedefinieerd.

5

CAN(OPEN) ... FOUT! BLADWIJZER NIET GEDEFINIEERD.

5.1. Inleiding ... Fout! Bladwijzer niet gedefinieerd. 5.2. Fysieke laag ... Fout! Bladwijzer niet gedefinieerd. 5.3. Datalink laag ... Fout! Bladwijzer niet gedefinieerd. 5.4. Applicatie laag (CANopen) ... Fout! Bladwijzer niet gedefinieerd. 5.4.1. CANopen frame ... Fout! Bladwijzer niet gedefinieerd. 5.4.2. NMT node monitoring ... Fout! Bladwijzer niet gedefinieerd. 5.4.3. Network Management (NMT) ... Fout! Bladwijzer niet gedefinieerd. 5.4.4. Synchronisatie (SYNC) ... Fout! Bladwijzer niet gedefinieerd. 5.4.5. Emergency (EMCY) ... Fout! Bladwijzer niet gedefinieerd. 5.4.6. Timestamp (TIME) ... Fout! Bladwijzer niet gedefinieerd. 5.4.7. Process Data Object (PDO’s) ... Fout! Bladwijzer niet gedefinieerd. 5.4.8. Service Data Object (SDO’s) ... Fout! Bladwijzer niet gedefinieerd. 5.4.9. Object Dictionary (OD) ... Fout! Bladwijzer niet gedefinieerd. 5.4.10. Overzicht gebruikte PDO’s ... Fout! Bladwijzer niet gedefinieerd. 5.4.11. Analyse CAN-communicatie ... Fout! Bladwijzer niet gedefinieerd.

6

LITERATUURSTUDIE ROS2 ... FOUT! BLADWIJZER NIET GEDEFINIEERD.6

6.1. Geschiedenis ... Fout! Bladwijzer niet gedefinieerd.6 6.1.1. Robot Operating System (ROS) ... Fout! Bladwijzer niet gedefinieerd.6 6.1.2. Overgang ROS naar ROS2 ... Fout! Bladwijzer niet gedefinieerd.7 6.2. Data architectuur ... Fout! Bladwijzer niet gedefinieerd.7 6.3. DDS (onderliggende laag) ... Fout! Bladwijzer niet gedefinieerd.8 6.3.1. Global Data Space ... Fout! Bladwijzer niet gedefinieerd.8

2 6.3.2. DomainParticipant ... Fout! Bladwijzer niet gedefinieerd.8

6.3.3. Quality of Service ... 19

6.3.4. Topics ... 19

6.4. Quality of Service model ... 19

6.5. DDS security ... 21

6.6. Vergelijking ROS en ROS2 ... 21

7

IMPLEMENTATIE ROS2 OP CANOPEN INTERFACE ... 23

7.1. ROS CANopen ... 23

7.2. Canopen_chain_node ... 24

7.2.1. Launch file ... 24

7.2.2. Configuration file (.yaml) ... 24

7.2.3. ROS2 services ... 24

7.3. ROS2 workspace ... 25

7.4. CANopen node ... 26

8

STURING MOTOR VIA SIMULINK ... 27

8.1. Inleiding ... 27 8.2. Stateflow ... 27 8.3. Statuswoord ... 27 8.4. Controlewoord ... 28 8.5. Sturing motor ... 28 8.6. Simulink model ... 30 8.6.1. ROS2 library ... 30 8.6.2. ROS2 parameters ... 30 8.6.3. ROS2 messages ... 31 8.6.4. Stateflow ... 32 8.6.5. Simulatiemodes ... 33

9

DUURZAAMHEID ... 34

10

BESLUIT ... 35

3

Lijst van figuren

Figuur 1.1 Logo Vintecc ... 1

Figuur 3.1 Foto Pallet Shuttle ... 3

Figuur 3.2 Topologie Pallet Shuttle ... 3

Figuur 3.3 Schematische opbouw Shuttle ... 4

Figuur 4.1 Industrial network market shares 2018 according to HMS ... 5

Figuur 4.2 EtherCAT dataframe ... 6

Figuur 5.1 OSI-model CAN ... 8

Figuur 5.2 CAN differentieel principe ... 8

Figuur 5.3 Bitcodering CAN ... 9

Figuur 5.4 CAN dataframe ... 9

Figuur 5.5 CANopen-frame ... 10

Figuur 5.6 Statuswoord in het OD ... 13

Figuur 6.1 ROS2 Architectuur ... 17

Figuur 6.2 DDS Infrastructuur ... 19

Figuur 6.3 Quality of Service model ... 19

Figuur 6.4 Deadline tijdlijn ... 20

Figuur 6.5 Breakdown of ROS2 latencies ... 22

Figuur 7.1 Overzicht ros_canopen master ... 23

Figuur 7.2 GetObject service ... 25

Figuur 7.3 Mapstructuur ROS2 canopen_node ... 25

Figuur 7.4 Custom messages ... 26

Figuur 8.1 Statusdiagram ... 27

Figuur 8.2 Statuswoord ... 28

Figuur 8.3 Controlewoord ... 28

Figuur 8.4 Build & Run in Simulink ... 29

Figuur 8.5 Configure ROS2 network Simulink ……….. 30

Figuur 8.6 ROS2 parameters in Simulink …….……….. 31

Figuur 8.7 ROS2 messages in Simulink …….……….. 31

Figuur 8.8 Stateflow in Simulink ……….. 32

Figuur 8.9 Runtime mode …….……….……….. 33

Figuur 8.10 External mode …….……….. 33

Figuur 9.1 Sustainable Development Goals ……….. 34

4

Lijst van tabellen

Tabel 5.1 Functiecodes met bijhorende COB-ID ... 11

Tabel 5.2 Heartbeat code met bijhorende betekenis ... 11

Tabel 5.3 NMT commando’s met bijhorende betekenis ... 12

5

Symbolen en afkortingen

A

ACK

Acknowledge

API

Application Programming Interface

C

CAN

Controller Area Network

CiA

CAN in Automation

COB-ID

Communication Object Identifier

CRC

Cyclic Redundancy Check

CSMA/CA

Carrier Sense Multiple Access / Collision Avoidance

CSMA/CD

Carrier Sense Multiple Access / Collision Detection

D

DDS

Distributed Discovery System

F

FCS

Frame Check Sequence

FMMU

Fieldbus Memory Management Unit

M

MQTT

MQ Telemetry Transport

MSB

Most Significant Bit

N

NRZ

Non Rerturn to Zero

O

OD

Object Dictionary

OPC UA

Open Platform Communication Unified Architecture

OS

Operating System

6

P

PDO

Process Data Object

Q

QoS

Quality of Service

R

RCL

ROS Client Library

RCLCPP

ROS Client Library C++

RCLPY

ROS Client Library Python

RMW

ROS Middleware

ROS

Robot Operating System

RPDO

Receive Process Data Object

RTR

Remote Transmission Request

S

SDG

Sustainable Development Goals

SDO

Service Data Object

SROS

Secure Robot Operating System

T

TCP

Transmission Control Protocol

TPDO

Transmit Process Data Object

U

UDP

User Datagram Protocol

W

WKC

Working Counter

X

7

1 Inleiding

1.1. Voorwoord

In de huidige maatschappij worden er meer en meer producten verkocht via het internet. Om een snelle levering te kunnen garanderen is er nood aan een efficiënt werkend magazijn met een optimale opslagcapaciteit. Sinds de integratie van robotica in de industrie, is het mogelijk om deze hoge eisen te vervullen. Een geautomatiseerd magazijn op basis van een pallet shuttlesysteem is een innovatieve oplossing op de opslag problematiek. De operator is in staat om alles vanop afstand te besturen, het wegstapelen en terughalen van de palletten gebeurt automatisch. Het gebruik van automatisering en robotica zorgt voor veel voordelen, maar er moet extra aandacht besteed worden aan safety. In deze masterproef wordt er beschreven hoe een snelle en deterministische communicatie kan gecreëerd worden zodat pallet shuttles op een veilige manier ingezet kunnen worden.

1.2. Bedrijfsvoorstelling

Vintecc is een bedrijf dat gespecialiseerd is in het ontwikkelen van machine software voor industriële en mobiele toepassingen. De firma is opgericht in 2014 en bestaat uit een team van 16 jonge professionals die gespecialiseerd zijn in modelgebaseerde software. Het doel van Vintecc is de automatiseringsprocessen van hun klanten te versnellen en te verbeteren door software op maat te ontwikkelen. Dit realiseren ze aan de hand van volgende drie niveaus: machine software, simulaties en data verwerking. Vintecc maakt gebruik van digital twins, prototypes die ontwikkeld zijn in een virtuele omgeving. Dankzij deze replica kunnen ze de software schrijven vooraleer de machine gebouwd is. Hierdoor kunnen ze elk project op een snelle en kwalitatieve manier uitwerken. [1]

Figuur 1.1: Logo Vintecc

1.3. Projectvoorstelling

Deze thesis kadert in een groter project waarin een magazijn autonoom werkt aan de hand van een pallet shuttlesysteem. Dit systeem bestaat uit meerdere zelfgestuurde shuttles die als doel hebben om palletten te verplaatsen in een op maat ontworpen rekkenstructuur. Een heftruck plaatst de shuttle op een rail waar er een product geladen of gelost moet worden. Nadien kan de bestuurder van de heftruck commando’s doorsturen door middel van een afstandsbediening. Na het automatisch uitvoeren van een opdracht, wordt de shuttle verplaatst naar een andere rail en krijgt het een nieuwe taak. Deze semi-automatische aanpak heeft als voordeel dat er optimaal gebruik kan gemaakt worden van de opslagcapaciteit. Door meerdere shuttles te gebruiken, kan er sneller en efficiënter gewerkt worden. [2]

8

2 Doelstellingen

Nu er twee verschillende versies van het robotbesturingssysteem bestaan, moet er een vergelijkende studie gebeuren. Waarin verschillen de methodes precies? Wat zijn de voordelen van ROS2 ten opzichte van ROS? Wanneer is het juiste moment om over te schakelen naar ROS2? Hoe deterministisch zijn beide systemen en welke maatregelen omtrent safety zijn er beschikbaar? Dit zijn vragen die eerst onderzocht moeten worden vooraleer er kan overgegaan worden naar een effectieve implementatie. In de thesis ligt de focus op ROS2 en zal de vergelijking opgemaakt worden aan de hand van een analyse van ROS2. Nieuwe implementaties in de software moeten aantonen dat er wel degelijk een verbetering is ten opzichte van de vorige versie.

Om de theoretische kennis omtrent ROS2 te verduidelijken, zal deze middleware geïntegreerd worden in een pallet shuttle project. Het doel is om de verschillende functionaliteiten, die aan bod komen in de analyse, te integreren en uit te testen. Uiteindelijk dient er één shuttle in werking gesteld te worden om beschikbare functionaliteiten te demonstreren. De focus ligt op het ontwikkelen van een CANopen interface met een werkend 402-profiel.

Concreet wordt volgende output voor deze masterproef verwacht: ▪ Een theoretische literatuurstudie van ROS2. ▪ Een vergelijking tussen ROS en ROS2.

▪ Een ROS2 integratie in Matlab Simulink en bestaande modellen aanpassen zodat deze kunnen communiceren via ROS2.

▪ Een werkende testopstelling bouwen zoals beschreven in figuur 1.4. De focus ligt hier voornamelijk op de CANopen communicatie tussen het Simulink model en de motoren.

9

3 Project analyse

3.1. Pallet Shuttle

Het belangrijkste onderdeel van een automatisch magazijn is de pallet shuttle. Het bevat de nodige logica om goederen naar de gewenste eindbestemming te vervoeren. De shuttle die in de masterproef gebruikt wordt, is een 1D shuttle (figuur 3.1) . Deze is dus in staat om objecten op te nemen en in 1 richting heen en weer te rijden.

Figuur 3.1: Foto Pallet Shuttle

De shuttle is opgebouwd uit drie grote componenten: de sensoren, de motoren (met interne drive) en de controller. Deze zijn met elkaar verbonden over drie verschillende communicatieprotocollen. De sensoren zijn via een Beckhoff I/O module gekoppeld aan een Ethernet poort en communiceren via het EtherCAT protocol. De motoren, die gebruikt worden om te rijden en te heffen, zijn verbonden via CAN en gebruiken het CANopen protocol. Beide protocollen werden gekozen omdat ze een realtime communicatie kunnen garanderen. Als laatste zal de interne communicatie van de controller, tussen de logica en de interfaces, via ROS2 gebeuren. Figuur 3.2 geeft de topologie weer van de volledige communicatie.

10 Oorspronkelijk werden de shuttles gestuurd door een Beckhoff controller, maar in een steeds evoluerende industrie is de vraag naar goedkope en innovatieve oplossingen sterk gegroeid. Vintecc heeft daarom de keuze gemaakt om in dit project over te schakelen naar het robotbesturingssyteem ROS. Dit is een open source middleware die voornamelijk gebruikt wordt in de robotica en automotive industrie. Figuur 3.3 is een schematische voorstelling van de communicatie binnen een shuttle. ROS wordt hier dus gebruikt als communicatie laag tussen enerzijds de controller node en de EtherCAT interface en anderzijds de controller node en de CANopen interface. Het is vanzelfsprekend dat de ROS-communicatie ook aan de realtime voorwaarden moet voldoen. De controller node is gecodeerd in een Matlab Simulink model dat in een Linux omgeving draait.

Figuur 3.3: Schematische voorstelling software

In 2017 is er een nieuwe versie uitgekomen van het robotbesturingssysteem: ROS2. Het is zeker interessant om de werking van deze communicatie onder de loep te nemen. De onderzoekers die geholpen hebben om ROS2 tot stand te brengen, garanderen dat het besturingssysteem performanter is dan zijn voorhanger. In deze thesis zal de nadruk dan ook liggen op het integreren van ROS2 in het pallet shuttle project. [3]

3.2. Testopstelling

Door invloed van externe factoren was het niet altijd mogelijk om een pallet shuttle te gebruiken als testopstelling. Een vereenvoudigde opstelling voldoet om de werking van de CANopen nodes te testen (figuur 3.4).

11

4 EtherCAT

4.1. Inleiding

EtherCAT (Ethernet for Control Automation Technology) is een realtime veldbus-systeem gebaseerd op Ethernet. Het protocol werd in 2003 ontwikkeld door Beckhoff, maar het wordt ondertussen al door andere bedrijven gebruikt. EtherCAT is een goedkope veldbus omdat het gebruik maakt van de massaal geproduceerde ethernet kabels. Het combineert de voordelen van het gekende Ethernet met een garantie op realtime communicatie. Dit zorgt ervoor dat EtherCAT in populariteit stijgt (Figuur 4.1) en dat het een ideale keuze is voor het pallet shuttle project.

Figuur 4.1: Industrial network market shares 2018 according to HMS [4]

4.2. Ethernet realtime

Ethernet wordt steeds vaker gebruikt in de industrie omdat het een goedkope manier is om grote hoeveelheden data te versturen. Het probleem is echter dat deze netwerkstandaard niet realtime is, wat juist essentieel is in de robotica. Enkele problemen zijn:

- Ethernet communicatie brengt grote hoeveelheden overhead data met zich mee waardoor er geen efficiënte en snelle communicatie mogelijk is.

- Ethernet heeft een gebrek aan determinisme doordat het gebruik maakt van het CSMA/CD protocol.

EtherCAT maakt gebruik van het master-slave principe en verstuurt data als ‘One-Total-Frame’ om de overhead te beperken en zo van Ethernet een realtime communicatie protocol te maken. [5]

12

4.2.1. Master-slave

Vaak wordt een realtime communicatie geassocieerd met het snel versturen van data, maar determinisme is minstens even belangrijk. Ethernet maakt gebruik van CSMA/CD om dataverlies tegen te gaan, m.a.w. er wordt pas gereageerd als er een databotsing heeft plaatsgevonden. Een willekeurige backoff time bepaalt wanneer de zenders opnieuw hun data mogen versturen. Wanneer de data juist zal toekomen bij de ontvanger is bijgevolg onvoorspelbaar. Door gebruik te maken van het master-slave principe kan er bepaald worden welke zender er voorrang heeft. De master heeft controle over het volledig netwerk en kan er dus voor zorgen dat er nooit een botsing zal plaatsvinden tussen twee dataframes. [5]

4.2.2. One-Total-Frame

Bij EtherCAT wordt de data in één groot dataframe verstuurd naar alle slaves. Dit heeft als voordeel dat de overhead relatief beperkt blijft. Binnen de controller (master) wordt er een logisch procesgeheugen aangemaakt dat alle slavedata bevat in een specifieke volgorde. Elke slave bevat een eigen fysiek geheugen dat elke cyclus wordt gelinkt aan het procesgeheugen. Het linken van een fysiek geheugen aan het logisch procesgeheugen heet mapping en vindt plaats in de slave. Om dit proces sneller te doen verlopen, wordt data on-the-fly verwerkt. Alle slaves zijn via een logische ring-structuur verbonden met de master. Ondanks dat het dataframe door elke slave passeert, wordt enkel maar de nuttig data door iedere deelnemer bewerkt. Op het moment dat de nuttige informatie de slave binnenkomt, wordt deze bit per bit verwerkt en is er slechts een vertraging van drie bittijden. [5]

4.2.3. EtherCAT dataframe

Figuur 4.2: EtherCAT dataframe

Figuur 4.2 geeft een schematisch overzicht van een EtherCAT dataframe. Enkele belangrijke onderdelen zijn:

- Ethernet header: hier worden de MAC-adressen bijgehouden die nodig zijn tijdens de communicatie.

De header bevat ook een preamble die noodzakelijk is voor de synchronisatie.

- FCS: is een CRC-check die dient als foutcontrole.

- EtherCAT header: bevat informatie over de lengte en type van een EtherCAT datagram (16 bytes).

- EtherCAT Datagram: bij EtherCAT wordt data verstuurd door middel van datagrammen (max 1500

bytes). Er kan een maximum van 15 datagrammen per EtherCAT-frame verzonden worden.

- Datagram header: bevat extra informatie over de data verstuurd in een datagram (10 bytes).

13

4.2.4. Adressering

Binnen EtherCAT zijn er drie mogelijke vormen van adressering: Segment, Device en Logical Addressing. Dit hoofdstuk bespreekt kort de verschillen tussen deze methodes en wanneer een bepaalde soort adressering gebruikt kan worden.

Segm ent Addressi ng

Segment Addressing gebeurt op Ethernet niveau aan de hand van het MAC-adres. Het is dus mogelijk om EtherCAT segmenten te verbinden met elkaar via een Ethernet netwerk. Niet alle EtherCAT slaves hebben een MAC-adres waardoor enkel Open Mode slaves rechtstreeks op het netwerk verbonden kunnen worden. De volledige adressering wordt ook wel Open Mode Addressing genoemd. Slaves die geen MAC-adres hebben, moeten rechtstreeks verbonden worden met de EtherCAT master. Deze vorm van Segment Addressing wordt Direct Mode Addressing genoemd.

Devi ce A ddr essi ng

Device Addressing gebeurt op het niveau van het EtherCAT datagram en maakt gebruik van een positie adres of een node adres. Het 32 bit adres wordt opgedeeld in twee gelijke delen van 16 bits.

Bij Position Addressing weet de master in het begin nog niet welke slaves aangesloten zijn en wat hun adressen zijn. Het positie adres bevat een negatief getal (16 bit) en elke slave die het EtherCAT bericht leest zal dit getal met één verhogen. De slave die het bericht ontvangt terwijl het adres op nul staat, is eigenlijk de aangesprokene en dient de data te verwerken. Ook deze verhoogt het adres opnieuw met één zodat het positief wordt, waardoor de volgende slaves weten dat ze het bericht gewoon kunnen negeren. Bij het opstarten van het netwerk loopt de master alle slaves af totdat er geen slaves meer reageren. De absolute waarde van dit positie adres geeft weer hoeveel slaves er in het netwerk aanwezig zijn. Het tweede deel van de adressering bevat een offset van 16 bit. Deze geeft aan welke geheugenplaats in de slave aangesproken wordt. Er wordt hier dus geen vast adres gebruikt, de positie van de slave in het netwerk is doorslaggevend. Deze vorm van adressering is sneller dan Segment Addressing doordat het dataframe kleiner is (MAC-adres is 48 bit lang). Het nadeel is wel dat de slaves niet zomaar van plaats kunnen gewisseld worden zonder de adressering in de war te brengen.

Als elke slave een node adres krijgt, kan er Node Addressing toegepast worden. Het eerste deel van het 32 bit adres is nu het node adres. Deze wordt meegegeven door de master, maar kan achteraf aangepast worden door de gebruiker. Het tweede deel van het adres is opnieuw een 16 bit lange offset die, net als bij Position Addressing, verwijst naar een geheugenplaats in de slave.

Logi cal Addressi n g

Bij deze adressering wordt gebruik gemaakt van het volledige 32 bit adresveld. Hierbij wordt de volledige logical process image in één datagram verstuurd. Om dit te realiseren is er nood aan FMMU functieblokken in de EtherCAT Slave Controller. Deze FMMU’s zorgen ervoor dat de informatie op de juiste plaats in het fysiek geheugen gemapped wordt. Deze manier van adressering zorgt voor zeer weinig overhead en wordt daarom meestal gebruikt tijdens uitwisseling van procesdata. [5]

14

5 CAN(open)

5.1. Inleiding

CAN is een industriële veldbus die vaak wordt gebruikt in de automotive industrie. In 1993 werd, in samenwerking met Bosch, een organisatie opgericht genaamd CAN in Automation (CiA). Deze is er gekomen door een groeiende interesse vanuit de industrie. Figuur 5.1 geeft de drie lagen van het OSI-model weer die gebruikt worden in de CiA implementaties. De specifieke applicatie laag uit de automotive wereld wordt vervangen door enkele standaarden. De applicatie laag die in het pallet shuttle project gebruikt wordt, is CANopen[6]

Figuur 5.1: OSI-model CAN [6]

5.2. Fysieke laag

De fysieke laag kan ingevuld worden door meerdere internationale standaarden, CANopen maakt gebruik van CIA DS-102, een 2-draads kabel die wordt uitgevoerd als twisted pair met een maximale lengte van 200m per segment. Indien er een langere afstand overbrugd moet worden, kan de lengte van de kabel uitgebreid worden door middel van repeaters. CIA DS-102 bestaat uit twee aders, CAN-High en CAN-Low, die afgesloten zijn door weerstanden van 120Ω. Deze afsluitweerstanden hebben als nut de transmissielijn te sluiten zodat er een minimale reflectie van het signaal aanwezig is (Figuur 5.2).

15 De communicatie via CIA DS-102 wordt binair gecodeerd volgens het NRZ-principe (Figuur 5.3).

Figuur 5.3: Bitcodering CAN

-

CAN-High kan een minimumwaarde aannemen van 2,5V en een maximale waarde van 3,5V.

-

CAN-Low kan een minimumwaarde aannemen van 1,5V en een maximale waarde van 2,5V.

Door het verschil te nemen van beide signalen kunnen er twee niveaus ontstaan. Het recessief niveau is een logische ‘1’, het verschil tussen CAN-High en CAN-Low is kleiner dan 0,5V. Het dominant niveau is een logische ‘0’, er is een minimum verschil van 0,9V tussen beide aders. Dit principe wordt het differentieel principe genoemd en zorgt ervoor dat er geen ruis op het eindsignaal aanwezig is. Externe invloeden hebben hetzelfde effect op beide signalen, door het verschil te nemen, zal de ruis opgehoffen worden.

5.3. Datalink laag

Adresser i ng

In tegenstelling tot EtherCAT, wordt er geen master-slave principe gebruikt bij CAN. Elke dataframe bevat een bericht ID dat de prioriteit van het bericht bepaalt. Een logische ‘0’ is dominant op de CAN bus waardoor een signaal met een lager ID, door de fysische opbouw van het netwerk, altijd voorrang krijgt. De verschillende dataframes worden niet specifiek geadresseerd, maar gebroadcast (= naar alle nodes gestuurd). Elke node heeft ook zijn eigen node ID, dit is een uniek nummer en zorgt ervoor dat het aantal deelnemers beperkt is tot 127 (een node ID is 7 bit lang). Een CAN node leest alleen maar de data uit een dataframe met een bericht ID waarop hij ingetekend is (= impliciete adressering)

Om botsingen tussen verschillende dataframes te voorkomen wordt het busarbitrage CSMA/CA toegepast. Berichten met een hoge prioriteit krijgen voorrang op dataframes met een lagere prioriteit. Het is dus mogelijk om realtime communicatie tot stand te brengen via CAN. Een dataframe van CAN wordt weergegeven in Figuur 5.4. [6]

16

-

Start of frame: bij elke dataframe wordt er een flank meegestuurd (= 1 bit) om te kunnen

synchroniseren.

-

Message ID: deze ID bevat 11 bits die de prioriteit meegeven van het bericht

-

CAN data: er kan maximaal 8 byte aan data verstuurd worden. Indien er een event wordt gestuurd, zal

het dataveld 0 bytes bevatten. De informatie over dit event zal meegegeven worden met het bericht ID (remote frame).

-

CRC: foutcontrole

-

ACK: de ontvangende node zal een logische ‘1’ vervangen door een ‘0’ om aan te tonen dat de data

ontvangen is.

5.4. Applicatie laag (CANopen)

5.4.1. CANopen frame

Figuur 5.5: CANopen-frame

Een CANopen frame bestaat uit volgende onderdelen:

-

COB ID: de Communication Object Identifier bestaat uit een Function code en een Node ID. De

functiecode bevat de functie van het CANopen-frame en het node ID geeft aan door welke node deze functie moet uitgevoerd worden. De functiecodes kunnen in de applicatielaag gekozen worden doormiddel van profielen (tabel 5.1.)

-

RTR: Remote Transmission Request is een bit die weergeeft als de gekozen frame een dataframe of een

remote request frame (bericht zonder data) is.

-

Lengte: de datalengte uitgedrukt in byte ( 4 bit).

-

Data: de verstuurde data kan maximaal 8 byte lang zijn. Naargelang het gekozen profiel, zal de data op

17 Communication object COB-ID (hex) Slave nodes

NMT node control 000 Receive only

SYNC 080 Receive only

Emergency 080 + Node ID Transmit

Time Stamp 100 Receive only

PDO

180 + Node ID 1. Transmit PDO 200 + Node ID 1. Receive PDO 280 + Node ID 2. Transmit PDO 300 + Node ID 2. Receive PDO 380 + Node ID 3. Transmit PDO 400 + Node ID 3. Receive PDO 480 + Node ID 4. Transmit PDO 500 + Node ID 4. Receive PDO

SDO 580 + Node ID Transmit

600 + Node ID Receive

NMT node monitoring 700 + Node ID Transmit

Tabel 5.1: Functiecodes met bijhorende COB ID [6]

5.4.2. NMT node monitoring

Om te ontdekken welke nodes zich op het netwerk bevinden, wordt er gebruik gemaakt van een heartbeat. Dit is een periodisch bericht dat verstuurd wordt door elke deelnemer op het netwerk. Kenmerkend aan deze heartbeat is dat deze een COB-ID heeft van 700 + Node ID. Alle adressen worden hexadecimaal meegegeven en kunnen bepaald worden dankzij deze heartbeat. Tabel 5.2 geeft de verschillende statussen van het heartbeat bericht weer. NMT state Betekenis 0x00 Boot up 0x04 Stopped 0x05 Operational 0x7f Pre-Operational

Tabel 5.2: Heartbeat code met bijhorende betekenis [6]

5.4.3. Network Management (NMT)

Het NMT geeft de status van de CANopen node weer en wordt ook gebruikt om deze te beheren. Het versturen van een NMT-bericht gebeurt met een COB-ID met hexadecimale waarde 0x00. Het bericht bevat 2 byte aan data. De geadresseerde node en de huidige/gewenste status wordt meegegeven. Deze status werd bepaald dankzij de eerder beschreven heartbeat. Tabel 5.3 geeft alle NMT-codes weer met de bijhorende status.

18 NMT command code Betekenis

0x01 Operational

0x02 Stopped

0x80 Pre-operational

0x81 Reset node

0x82 Reset Communication

Tabel 5.3: NMT commando’s met bijhorende betekenis [6]

5.4.4. Synchronisatie (SYNC)

SYNC-berichten worden gebruikt om acties op elkaar af te stemmen. Het SYNC-bericht kan bijvoorbeeld gebruikt worden om motoren op hetzelfde moment aan te sturen. SYNC-berichten bevatten een COB-ID van 0x80.

5.4.5. Emergency (EMCY)

Indien er zich een probleem voordoet, kan een Emergency-bericht een error-code versturen. Dit bericht bestaat uit een COB-ID van 0x80 + Node-ID en bevat error-codes in het dataveld. Bijlage 2 bevat een tabel met alle mogelijke error-codes.

5.4.6. Timestamp (TIME)

Het TIME-bericht dient om de inwendige klokken van de nodes op elkaar af te stemmen. Dit bericht bestaat uit een COB-ID van 0x100 en in het dataveld van dit bericht wordt de verstreken tijd weergegeven sinds 1 januari 1984.

5.4.7. Process Data Object (PDO’s)

PDO-communicatie werkt volgens het Provider-Consumer model, het is een snelle manier om data te versturen. PDO’s worden vaak gebruikt om sensor-data te versturen omdat er een relatief grote hoeveelheid data (8 byte) cyclisch verstuurd kan worden. Er zijn twee soorten PDO’s: transmit- en receive PDO’s (TPDO, RPDO). TPDO’s worden gebruikt om data uit het apparaat te lezen terwijl er via RPDO’s data naar een apparaat wordt verstuurd. Standaard kunnen er vier TPDO’s en vier RPDO’s verstuurd worden in een dataframe, tabel 5.1 bevat een overzicht van alle PDO’s.

19

5.4.8. Service Data Object (SDO’s)

SDO-communicatie werkt volgens het client-server principe. Het is een point-to-point communicatie tussen twee deelnemers aan de hand van een COB ID. Door de rechtstreekse adressering, hebben deze SDO’s een grotere overhead dan PDO’s. Ze worden voornamelijk gebruikt om parameter data te versturen. SDO’s zijn betrouwbaar omdat het een bevestigde communicatie is. Er wordt telkens een acknowledge bit aangepast bij het lezen van de data.

5.4.9. Object Dictionary (OD)

Het Object Dictionary is een gestandaardiseerde structuur die alle communicatie objecten van een bepaald apparaat weergeeft. Het bevat specifieke informatie over de applicatie en ook alle configuratie parameters. Ieder object in het Object Dictionary heeft een adres (16 bit), een sub adres (8bit), een naam, een datatype en de access type (read only, write only, read and write). Een voorbeeld van zo’n parameter is het statuswoord, figuur 5.6 geeft weer hoe deze parameter wordt ingevuld.

Figuur 5.6: Statuswoord in het OD

De informatie uit een OD wordt meegegeven in een Electric Data Sheet (EDS) bestand. Dit is een template die de fabrikant maakt en waarin alle parameters overzichtelijk worden weergegeven. Indien deze template wordt ingevuld met de gewenste parameters, wordt deze opgeslaan als Device Configuration File (DCF). Dit is dus een ingevulde versie van een EDS-file.

In een OD is het ook mogelijk om bepaalde SDO-parameters te mappen als PDO-parameters. Dit betekent dat deze parameters nu worden verstuurd in een PDO-frame en dus cyclisch opgevraagd kunnen worden. Het is mogelijk om 8 byte aan parameterdata te versturen.

20

5.4.10. Overzicht gebruikte PDO’s

- Position mode

Parameter Index Data lengte Access right

Controlewoord 6040 16 bit Read / Write

Statuswoord 6041 16 bit Read

Operation mode 6060 8 bit Read / Write

Profile velocity 6081 32 bit Read / Write

Target position 607A 32 bit Read / Write

- Velocity mode

Target velocity 60FF 32 bit Read / Write

- Actieve parameters

Actual Position 6064 32 bit Read

Actual Demand Position 6062 32 bit Read

Actual Velocity 606C 32 bit Read

5.4.11. Analyse CAN-communicatie

Nu de theoretische kennis rond CANopen verduidelijkt is, kan er een analyse opgemaakt worden van de CAN- communicatie over het netwerk (CAN 0). De analyse zal gemaakt worden bij de opstart van de ROS2 CANopen node.

Opstarten van de node (ID = 66 decimaal)

CAN0 000 [2] 82 42

- COB–ID is hier 000, dit betekent dus dat het bericht afkomstig is van de NMT node control. - Het bericht is 2 byte lang.

- De eerste byte (0x82) geeft de functionaliteit weer van het bericht: Reset Communication van node met node ID 0x42).

CAN0 742 [1] 00

- COB–ID is hier 742, dit betekent dus dat het bericht een heartbeat met een node ID van (0x42). - Het bericht 1 byte lang.

- Een bericht met een NMT state van 00 betekent dat de node in de “boot up” fase zit.

CAN0 742 [1] 7F

- COB–ID van 742 = heartbeat van node met node ID (0x42). - Het bericht 1 byte lang.

21 Paramaters opvragen

Bij de communicatie tussen de motor en de controller wordt elk commando weergegeven door een specifieke index. Tabel 5.4 is een opsomming van alle mogelijke commando’s met bijhorende index.

Tabel 5.4: CANopen commando’s met bijhorende index [6]

CAN0 642 [8] 2B 01 10 00 00 00 00 00

- COB–ID is hier 642, dit betekent dus dat er een SDO wordt verzonden naar de motor (Receive PDO). - Het bericht is 8 byte lang.

- De eerste byte (0x2B) geeft de functionaliteit weer van het bericht: write request van 2 byte data. - De tweede en derde byte geven weer welke parameter er opgevraagd wordt, in dit geval is dat

parameter 1001.

CAN0 5C2 [8] 60 01 10 00 00 00 00 00

- COB–ID is hier 5C2 (580 + 42), dit betekent dus dat er een SDO wordt teruggestuurd van de motor. (Transmit PDO).

- Het bericht is 8 byte lang.

- De eerste byte (0x60) geeft de functionaliteit weer van het bericht: write response (2 byte data). - Parameter = 1001 (Error Register).

- Het dataveld is leeg, dit betekent dat er voorlopig geen errors aanwezig zijn.

CAN0 000 [2] 01 42

- Na het opvragen van alle parameters stuurt de NMT node controle een bericht waarbij dat de node naar mode “operational” gaat ( code = 0x01).

Debuggen van fouten

CAN0 642 [8] 80 17 10 00 00 00 04 05

- COB–ID is hier 642, dit betekent dus dat er een SDO wordt verzonden naar de motor (Receive PDO). - De eerste byte (0x80) toont hier dat de motor een error response stuurt naar de controller.

- Parameter = 1017.

- De abort code is 0504 0000 (hex): in bijlage 2 staat deze code beschreven als een “SDO protocol timed out” foutmelding.

Command 4 byte data

(hex) 2 byte data (hex) 1 byte data (hex) Write request

(Send parameter to drive)

23 2B 2F

Write response

(Controller response to the write request)

60 60 60

Read Request

(Request to read a parameter from drive)

40 40 40

Read Response

(Response to the read request with an actual value)

43 4B 4F

Error response

(The controller indicates a communication error)

22

6 Literatuurstudie ROS2

6.1. Geschiedenis

6.1.1. Robot Operating System (ROS)

Software schrijven voor robots is niet eenvoudig. Robots kunnen sterk variërende hardware hebben waardoor het moeilijk wordt om code te hergebruiken. In een poging om hardware en software te verenigen, hebben onderzoekers aan Stanford University een framework gecreëerd: ROS. Deze robot middleware laat toe om op een eenvoudige en overzichtelijke manier elke type robot te sturen.

ROS is gecreëerd met de gedachte dat gebruikers zelf software kunnen schrijven die de basiswerking van de middleware in hun eigen applicatie implementeert. De algemene structuur is volledig open-source en makkelijk terug te vinden op GitHub.

Begr i ppen i .v .m . R OS

- Node: een proces binnen ROS dat berichten verstuurt en ontvangt. Een node is een geprogrammeerde

logica die via een bepaalde topic of via services kan communiceren met andere deelnemers.

- Master: heeft als doel om nodes, in een ROS-omgeving, met elkaar te doen communiceren. Berichten

worden peer-to-peer verstuurd via het publish-subscribe principe. De master verbindt afzonderlijke nodes met elkaar op basis van de topic name, waarbij het lookup mechanisme wordt gebruikt. Een ROS-communicatie kan dus nooit tot stand komen als er geen master actief is.

- Topic: een communicatiekanaal waarover nodes berichten kunnen zenden en ontvangen. Topics

worden gekenmerkt door hun topic name, die uniek moeten zijn binnen een bepaald ROS-domein.

- Message vs service: een message wordt cyclisch verstuurd en ontvangen via een bepaald topic. Dit

wordt voornamelijk gebruikt bij het inlezen van sensor data. Een node is echter ook in staat om een bepaalde service te versturen, dit werkt volgens het request-response principe. Dit wordt eerder gebruikt om parameter-data op te vragen tijdens de opstart van een bepaalde toepassing. Zowel een message als een service wordt beschreven in de neutrale IDL programmeertaal. Dit heeft als voordeel dat ROS berichten ondersteund worden door meerdere onderliggende talen (C++, Python, …)

- Catkin: dit is de achterliggende infrastructuur die ervoor zorgt dat ROS nodes gecompileerd en gebuild

worden.

- Rosbag: een tool dat gebruikt wordt om de communicatie tussen twee nodes op te nemen en opnieuw

af te spelen. Het registreert alle activiteit op het ROS-netwerk op een bepaald tijdstip. De enige parameter die moet worden meegegeven is de topic name. Deze tool is ideaal om sensor data te verzamelen en zo virtueel de werking van actuatoren te testen.

23

6.1.2. Overgang ROS naar ROS2

Hoewel realtime communicatie een must is in de robotica, is ROS geen realtime framework. Om toch te kunnen voldoen aan deze hoge eisen, is er een nieuwe versie uitgebracht: ROS2. Deze hernieuwde versie mag niet gezien worden als een uitbreiding van ROS, het platform is gebaseerd op een volledig nieuwe data architectuur. De ontwikkelaars hebben zich hiervoor gebaseerd op het DDS-protocol. Zowel ROS als ROS2 kunnen op meerdere OS draaien. In deze masterproef ligt de focus op de werking in een Linux omgeving.

6.2. Data architectuur

Figuur 6.1: ROS2 Architectuur [7]

RCL CPP

RCLCPP is de library die gebruikt wordt om te programmeren in C++. Hierin zitten alle functies om een ROS2 node te programmeren. RCLPY is de Python variant van deze library, maar in deze masterproef zal de focus liggen op C++.

RCL

RCL is de ROS Client Library, hier worden alle ROS2 componenten met hun functionaliteiten beschreven. RCL bevat logica met basisfuncties zodat deze library kan gebruikt worden voor meerdere bovenliggende programmeertalen (C, C++, Python).

RMW

RMW is de ROS2 middleware die de connectie maakt met de DDS middleware. Dit vormt de basis van de volledige communicatie en is tevens de plaats waar de QoS functionaliteiten zich bevinden. Bij het programmeren is het belangrijk dat er alleen maar code gebruik wordt die geprogrammeerd staat in de RCLCPP laag. Het is mogelijk om rechtstreeks code te schrijven vanuit RCL en RMW, maar dan is het noodzakelijk om de logische links zelf nog te programmeren.

24

6.3. DDS (onderliggende laag)

6.3.1. Global Data Space

DDS is een middleware protocol en API standaard die gebruikt wordt voor realtime communicatie. Deze is gebaseerd op Data-Centric publish-subscribe (= vierde generatie middleware).

-

Generatie 1 = Point-to-point communicatie tussen Client en Server (vb.: TCP)

-

Generatie 2 = Publish and Subscribe (vb: MQTT)

-

Generatie 3 = Broadcast Publish and Subscribe (OPC UA, veldbussen)

-

Generatie 4 = Data-Centric Publish and Subscribe

DDS maakt gebruik van een gemeenschappelijke database (Global Data Space) waar elke deelnemer zijn informatie kan halen. Zo zijn de deelnemers in staat om peer-to-peer te communiceren met elkaar.

De Global Data Space is een DDS-omgeving waar applicaties data objecten kunnen creëren en aanpassen. Binnen deze Data Space wordt elk data object gekenmerkt door een topic name, enkele voordelen zijn:

-

Dataverkeer is niet meer afhankelijk van verbindingen tussen meerdere applicaties.

-

Redundancy kan bekomen worden door het gebruik van meerdere DataWriters en DataReaders.

-

Data is altijd beschikbaar.

-

Nieuwe Publishers en Subscribers worden dynamisch herkend en toegevoegd (Dynamic Discovery) Deze Global Data Space mag niet gezien worden als een externe database, het is de verzameling van de lokale geheugens van alle deelnemers. DataReaders en DataWriters slaan alle nuttige informatie op en via parameters wordt bepaald hoe lang deze data wordt bijgehouden. [7]

6.3.2. DomainParticipant

Een DDS domain, ook Global Data Space genoemd, bevat meerdere deelnemers (Domain Participants). Een applicatie kan aan meerdere DDS-domeinen deelnemen door meerdere DomainParticipants aan te maken. Elke applicatie bevat een DomeinParticipantFactory die in staat is om zowel een DomainParticipants aan te maken als te verwijderen. Deze kunnen op hun beurt publishers en subscribers aanmaken. Figuur 6.2 is een schematische voorstelling van een DDS domain en bevat drie Domain Participants. Deze kunnen via een bepaalde topic communiceren met elkaar omdat ze zich in hetzelfde domein bevinden. Elke participant krijgt een domain ID mee zodat deze in het juiste domein terechtkomt. Indien deze ID uniek is, zal er een nieuw domein aangemaakt worden. Dit gebeurt allemaal tijdens de DDS Dynamic Discovery procedure. [7]

25

Figuur 6.2: DDS Infrastructuur [7]

6.3.3. Quality of Service

Quality of Service binnen het protocol, is een verzameling van parameters die het gedrag van de DDS-communicatie bepaalt. Een QoS-policy is een verzameling van meerdere gekozen parameters. Bij het aanmaken van deze QoS-policies moet er rekening gehouden worden dat deze enkel en alleen maar kunnen communiceren met deelnemers met een gelijk QoS-policy. Indien dit niet het geval is, zullen de parameters default waarden aannemen of is er kans dat de connectie niet tot stand komt. Binnen ROS2 zijn er al 5 parameters beschikbaar (figuur 6.3).

6.3.4. Topics

Zoals eerder besproken wordt elk data object gekenmerkt door een topic name. Een DataWriter en DataReader kunnen alleen maar communiceren met elkaar indien ze dezelfde Topic gebruiken. Topics worden aangemaakt en verwijderd door DomainParticipants.

6.4. Quality of Service model

QoS Policy QoS Policy

DURABILITY USER DATA

HISTORY TOPIC DATA

READER DATA LIFECYCLE GROUP DATA

WRITER DATA LIFECYCLE PARTITION

LIFESPAN PRESENTATION

ENTITY FACTORY DESTINATION ORDER

RESOURCE LIMITS OWNERSHIP

RELIABILITY OWNERSHIP STRENGTH

TIME BASED FILTER LIVELINESS

DEADLINE LATENCY BUDGET

CONTENT FILTERS TRANSPORT PRIORITY

26

Durabi l i t y

Durability beschrijft hoe en wanneer er data naar de Global Data Space wordt geschreven:

-

Volatile: data dat verstuurd wordt voordat er een nieuwe DataReader wordt aangemaakt, kan niet meer door deze DataReader gelezen worden.

-

Transient: data wordt opgeslaan in een lokaal geheugen en kan dus verstuurd worden naar nieuw aangemaakte DataReaders.

Hi st ory

Indien er gekozen is voor Transient durability, kan er met de history parameter bepaald worden hoeveel data er moet worden bijgehouden in het lokaal geheugen.

- Keep last (beperkt aantal data-instances bijhouden in het geheugen = history depth) - Keep all (tot dat de applicatie alles verwerkt heeft)

Rel i abi l i t y

-

Best effort: data wordt zo snel mogelijk verstuurd en er is geen controle op de communicatie. De latency ligt hier heel laag en er wordt geen feedback gevraagd.

-

Reliable: Hier wordt er wel feedback gestuurd en is er controle op de data.

Li vel i ness

Deze parameter geeft de status van een DataWriter weer. Er wordt gecontroleerd als deze actief is of niet. Een foutmelding wordt geactiveerd indien de timeout van de DataWriter te lang duurt.

Deadl i ne

Dit is de maximale periode tussen het schrijven en het lezen van een nieuw bericht. Indien deze deadline niet gehaald wordt, zal er een foutmelding geactiveerd en verzonden worden naar de DataWriter en DataReader. Figuur 6.4 is een schematische weergave van het deadline principe.