An EtherCAT-based Real-time Control System Design for a ...m...Remote-Direct-Drive 2-DOF manipulator by Zikun Yu Master of Science in Mechanical Engineering, Mechatronics Northeastern

An EtherCAT-based Real-time Control System Design for a

Remote-Direct-Drive 2-DOF manipulator

A Dissertation Presented

by

Zikun Yu

to

The Department of Mechanical and Industrial Engineering

in partial fulfillment of the requirements

for the degree of

Master of Science

in

Mechanical Engineering

Northeastern University

Boston, Massachusetts

Aug 2019

Contents

List of Figures iii

List of Tables v

Acknowledgments vi

Abstract of the Dissertation vii

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Summary of Remaining Chapters . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 EtherCAT Real-Time Software Design 42.1 Real-Time optimization for Low-Latency Linux System . . . . . . . . . . . . . . . 4

2.1.1 Real-time Operating Systems & Latency . . . . . . . . . . . . . . . . . . 42.1.2 Real-time Approaches: RTAI, Xenomai and PREEMPT-RT . . . . . . . . 72.1.3 Core-Isolation Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 EtherCAT master design and real-time motor control . . . . . . . . . . . . . . . . 102.2.1 Open EtherCAT Masters: IgH & SOEM . . . . . . . . . . . . . . . . . . . 102.2.2 SOEM-based Motor Control Method . . . . . . . . . . . . . . . . . . . . 112.2.3 Loaded Real-time Performance of EtherCAT Master . . . . . . . . . . . . 14

2.3 Gripper Control and System Identification . . . . . . . . . . . . . . . . . . . . . . 14

3 Gripper Control System Design 193.1 System Infrastructure Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.1 Design by parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Schedule analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 RDDA Control Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1 Design of RDDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Control implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 ROS-interface Development via Shared Memory . . . . . . . . . . . . . . . . . . 243.3.1 Shared Memory Implementations . . . . . . . . . . . . . . . . . . . . . . 263.3.2 Robust Mutex Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3 ROS package design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

i

3.4 ROS Interface Tests: Visualization & GUI . . . . . . . . . . . . . . . . . . . . . . 303.4.1 Remote Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.2 Gripper control via GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Force Control Implementations 324.1 Implementation of a DoB-based Impedance Controller . . . . . . . . . . . . . . . 32

4.1.1 Simple Impedance Controller . . . . . . . . . . . . . . . . . . . . . . . . 324.1.2 Force Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.3 Natural Admittance Control . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4 DOB-based Impedance Control . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Collision Detection under Unknown Environment . . . . . . . . . . . . . . . . . . 394.2.1 Collision detection approaches without force sensor . . . . . . . . . . . . . 394.2.2 Homing routine with a current-based approach . . . . . . . . . . . . . . . 41

4.3 Teleoperation with gloves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Conclusion and Discussion 465.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 Future Works and Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Bibliography 49

ii

List of Figures

1.1 A multi-axis motion control application design using Core-Isolation . . . . . . . . 2

2.1 System latency range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Architecture of RTAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Architecture of Xenomai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Goal of Core-Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Latency test on PREEMP-RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Latency test on Core-Iso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Motor control test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.8 Motor control diagram in CSP mode . . . . . . . . . . . . . . . . . . . . . . . . . 122.9 Low-pass filter response for an arbitrary position reference . . . . . . . . . . . . . 142.10 Loaded latency test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.11 Chirp test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.12 Torque chirp input to gripper system . . . . . . . . . . . . . . . . . . . . . . . . . 172.13 Actual position of grippers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.14 Motor system identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Infrastructure diagram of the system . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Shared space: producers insert data asynchronously into the shared space, while

consumers read data synchronously . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Schedule Analysis of System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 UML of EtherCAT layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 UML of user-friendly layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.6 Remote control test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7 Results of GUI test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.8 Position control through ROS interface . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Single DoF model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Relation between force-feedback and non-passivity of a coupled system . . . . . . 364.3 Conceptual diagram of disturbance observer . . . . . . . . . . . . . . . . . . . . . 384.4 DOB-based impedance control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 Momentum-based residual observer . . . . . . . . . . . . . . . . . . . . . . . . . 404.6 Hardstop is hard to detect by pressure sensor . . . . . . . . . . . . . . . . . . . . . 414.7 Commanded torque is distinguishable . . . . . . . . . . . . . . . . . . . . . . . . 42

iii

4.8 Homing routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.9 Flowchart of homing function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.10 Teleoperation with exoskeleton gloves . . . . . . . . . . . . . . . . . . . . . . . . 45

iv

List of Tables

2.1 Cyclic position input PDOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Cyclic position output PDOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 RddaProxy Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Attributes of JointCommands . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3 Attributes of JointStates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4 RddaProxy Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

v

Acknowledgments

Here I wish to thank those who have supported me during the process of the thesis work.My advisor Professor John Whitney has been very supportive in giving me this opportunity to workon this exciting topic. I would also like to thank Professor Alireza Ramezani as the committeemember of my thesis presentation and gave me a couple of inspirations on the further directions. Iwould like to thank Chunpeng Wang who designed an extraordinary controller which worked prettywell on the control system, and also offered me lots of ideas and suggestions on my thesis works.Thank you to Eric Schwarm and Evelyn Mendoza providing an amazing gripper as the hardwaresupport for our control implementations and helping with the experiments and manufacturing skills.Additionally, I would like to thank Jorge Canedo who developed a very persuasive teleo-controlapplication based on the control system. And lastly, I would like to thank my friends, especially myparents for supporting me throughout my education.

vi

Abstract of the Dissertation

An EtherCAT-based Real-time Control System Design for a

Remote-Direct-Drive 2-DOF manipulator

by

Zikun Yu

Master of Science in Mechanical Engineering, Mechatronics

Northeastern University, Aug 2019

John Whitney, Adviser

The control system of a high-DOF human-interaction robot requires the high-frequencysimultaneous control of multiple joints, which needs the capability to handle computation-massivetasks with low latancies. Aiming at the force control of 2-DOF fluid-actuated manipulator, I’mgoing to introduce a distributed infrastructure design with good flexibility and scalability, whilemaintaining a high-quality real-time performance.

In this thesis, a motor control library, arranged on a core-isolated real-time machine,is developed to provide control implementers with functional APIs and input/output mapping oflow-level data structures from SOEM (Simple Open EtherCAT Master) interfacing the direct-drivemotors and peripheral sensors via EtherCAT bus communication. While on a remote machine,the ROS (Robot Operating System) is deployed to deal with high-level non-realtime applications,including algorithm processing, data visualization and status analysis. At the same time, a user-friendly Python proxy with a couple of control APIs are offered as an auxiliary medium besides theROS native interfaces. To synchronize the user-facing data on both sides, a robust ROS interfaceis developed using the Shared Memory technique which is an IPC (Inter-Process Conmmunication)mechanism supported by Linux POSIX standards.

The teleoperation experiment demonstrates that the robot system can operate the closed-loop control consistently at 2 kHz, while limiting the loaded latency below 100 us. In addition, thecollision detection test shows both dexterity and maneuverability under unknown environments.

vii

Chapter 1

Introduction

The past fifty years have witnessed a magnificent growth of the robots’ intelligence and

capabilities. At the same time, the robot control systems have been attached great importance and

continuously improved for better functionality, flexibility and real-time performance.

1.1 Background

The primitive industrial robots are developed with a centralized control system with all

actuators and sensors assembled on a central control machine, which is equipped with a number

of standard interfaces including PCI slots and serial ports for control and data acquisition de-

vices. Though the integrated scheme makes hardware extension and data analysis easier, it becomes

clumsy and even unreliable for users to maintain and upgrade due to the lack of flexibility. What’s

more critical is that the centralized system shows insufficiency in real-time control and multi-task

processing particularly under the condition of massive computation.

In this situation, the distributed control architecture came into being. With decentralized

control concepts, most of the computational efforts can be offloaded to a high-level machine while

only motor controllers are running on the low-level real-time machine. To communicate with each

machine, the EtherCAT bus has become increasingly popular for its fast, reliable and widely-used

technology. On the basis of EtherCAT, Sygulla proposed a high-performance control system ar-

chitecture for humanoid robots against the general centralised systems. [8] Though the system can

operate at the control rates beyond 2 kHz, the system latency is compromised to 1ms, which impacts

the real-time performance of the controller, especially when both high-speed and high-precision mo-

tion control are required.

1

CHAPTER 1. INTRODUCTION

It’s true that the powerful CPUs today dramatically improve control systems’ ability to

deal with more complex tasks, whereas it doesn’t means that the real-time performance is guar-

anteed, because it’s often influenced by CPU scheduling and IRQ handling in a general-purpose

Linux system which result in immeasurable latencies and inconsistent control loop rates. To handle

this issue, people are prone to build EtherCAT masters using the open-source EtherCAT software

and libraries under the background of several real-time Linux platforms, including RTAI, Xenomai

and PREEMPT-RT. By examining the performance of these approaches, Kim [15], Delgado [6] and

Moon [12] concluded that the proposed open-source EtherCAT-based robot system showed desired

real-time performance, but a superior choice due to its less cost and better flexibility in application

development. However, the kernel-based approaches do not support part of the mobile platforms

which don’t use real-time kernel patches, such as Intel Appllolake and Raspberry pi 3. So an

application-centric CPU-partitioning (Core-Isolation) technique was developed and implemented.

Kang applied the approach into the servo control system on Android platform and migrated time-

sensitive motion control tasks to the dedicated CPU with much lower latencies. [9] In the thesis, the

loaded cyclic test for the core-isolated control system showes that the maximum latency could be

limited to no more than 50 us, which is an acceptable performance compared with the works shown

above.

Figure 1.1: A multi-axis motion control application design using Core-Isolation (Source [9])

To deal with non-realtime tasks, ROS becomes increasingly popular due to the scalabil-

2

CHAPTER 1. INTRODUCTION

ity and flexibility of the publisher/subscriber communication scheme, which shows superiority in

space, time and synchronization decoupling characteristics. For instance, the high-level applica-

tions on ROS like motion planning and data visualization do not require the explicit dependency

between each other. [7] Peekema demonstrated a complete method to employ ROS in a remote

control application of a bipedal robot. The low-level part of the architecture also followed the above

strategy, which implemented the SOEM EtherCAT master on a Xenomai patched real-time Linux

system. Whereas, the SOEM master works with Xenomai bindings and RTT-ROS controllers on the

OROCOS deployer. [1] The issue is that the system becomes cumbersome since it requires a bunch

of modules for both real-time and ROS applications. The thesis puts up with a new idea to decouple

the ROS applications from the control driver, and the data synchronization between the two levels

is achieved by the IPC mechanism in Linux POSIX APIs.

1.2 Summary of Remaining Chapters

In chapter 2, the conception of real-time operating systems with latencies is introduced

with the necessity of the deployment of RTOS in a robot control system explained. The design

and features of main real-time Linux platforms and other optimization approaches are explicitly

discussed and compared. An SOEM-based EtherCAT master software design is described and tested

using a closed-loop motor control, with which the dynamics of 2-DOF gripper can be identified for

further force control methods. And a loaded latency test is implemented to show the real-time

performance of the EtherCAT master.

In chapter 3, a new infrastructure design of the robot control system is proposed. Accord-

ing to the EtherCAT master design in chapter 2, a motor control driver is developed based on an

independent library with a series of features and utilities provided for control implementation. To

communicate with ROS applicaitions, the ROS interface for the control PC is developed using a

kind of IPC mechanism. And two ROS applications are used to demonstrate the performance of the

system as a whole.

In chapter 4, several force control methods are introduced, and A DOB-based impedance

controller is implemented on the gripper control system. A homing routine is developed through a

collision detection method. And the teleoperation demonstrates a remote control prototype of the

gripper system.

In chapter5, the main contributions of the thesis are summarized. Further works are dis-

cussed to improve the control system and couple of directions for future research are suggested.

3

Chapter 2

EtherCAT Real-Time Software Design

In this chapter, I’m going to introduce a design of high-performance robot control sys-

tem based on a real-time Linux system and EtherCAT communication protocol, where low-latency

optimization for real-time operation and EtherCAT master build-up for real-time control are de-

scribed separately. Then the closed-loop motor control is implemented, interfacing with networks

that includes motor drives and various analog input sensors. At last, an old version of robot control

system is compared to demonstrate this system’s advantages, such as performance, compatibility

and scalability.

2.1 Real-Time optimization for Low-Latency Linux System

2.1.1 Real-time Operating Systems & Latency

Real-time operating system (RTOS) has the ability to reliably measure or calculate its

maximum latency (Figure 2.1), which is the operational deadline between triggering event and

application’s response.

For a general-purpose operating system (Microsoft Windows, Unix, Linux, etc), latency

could be the delay from firing the interrupt until the interrupt handler starts running. In general,

there’s a variety of causes for high latency, including CPU power management, system interrupts

(SMI) and simultaneous multithreading (SMT), which could be optimized through multiple meth-

ods. In addition, a bad hardware may cause high latency, which could be improved by EtherCAT

based design that will be introduced later.

In contrast, it’s not intuitive to understand RTOS by its name, which is designed to handle

4

CHAPTER 2. ETHERCAT REAL-TIME SOFTWARE DESIGN

Figure 2.1: System latency range

a series of time-critical applications with complexity. Although today’s microprocessors allow op-

erating systems to run fast, speed alone cannot guarantee that time-critical application will meet its

operational deadline consistently, because the general-purpose systems are not designed to respond

to time-critical events within a predictable time frame. For a hard RTOS, whereas, can always re-

spond in time except for system’s failure, which means that the maximum response time is always

within an acceptable range, though a relatively worse RTOS may have a significant jitter (latency).

Such a priority becomes the prerequisite to build control systems with high reliability and robust-

ness, which are quite widely deployed in industrial applications, such as aerospace, networking,

medical, to name a few.

In control theory, a decent RTOS influences dramatically on controller design. It’s mainly

because the maximum latency could be shrink down to a relatively tiny range compared to a system’s

working cycle that we could practically pursue a high-frequency feedback control system with good

stability, high bandwidth, high precision and high robustness. To be specific, a well-developed

RTOS built on a good hardware should be deterministic within 20 50 us, such that the loop rate

could be raised to 2 kHz (500 us cycle time) or even higher, with which such a high-performance

controller could be realized in following reasons.

Take an example of a feedback controller implemented on a multi-DOF robot arm. A low

latency system paves the way to the complex control design, since it raises the margin of computa-

tional time covered in whole control cycle time. Oftentimes, requiring real-time control with high

frequency is hard for general embedded systems, considering the high time complexity of robot arm

5


control algorithms. Due to the low latency of RTOS, we can not only make controllers more power-

ful, but enhance the control system by adding more real-time functionalities. For sake of designing a

adaptive and robust control system, the control plant can be measured and identified on the fly, par-

ticularly for a robot system working under unknown environment. Also, a high-frequency feedback

controller running under a low-latency system significantly ameliorate the impact of delay, which

may cause system’s instability, especially when multiple sensors are deployed with high order fil-

ters. Furthermore, the robot with high-frequency control can respond quite fast, which also means

that the controller could be designed for higher bandwidth. In addition, high precision often plays

an important role in manufacturing with multi-DOF robot arms. However, due to the open-link

mechanical design of robot arms, the absolute trajectory of the end-effector is hard to guarantee.

In other words, a little error on forearm’s trajectory could result in an augmented error on wrist or

end-effector, when all joints or actuators cannot activate simultaneously, due to the non-realtime

execution of control system. This is often emphasized in later parts when we talk about EtherCAT

protocol and its distributed clocks mechanics. Last but not least, a high-frequency motor controller

has the ability to provide a large stiffness range for a better power to weight ratio and a high stable

margin for payloads, which are quite critical for a robot arm since the forearm is required to bear

with higher payloads compared to end-effector. In summary, RTOS has become indispensable in

robot control and related applications.

Figure 2.2: Architecture of RTAI Figure 2.3: Architecture of Xenomai

6


2.1.2 Real-time Approaches: RTAI, Xenomai and PREEMPT-RT

There are three typical real-time operating systems that are widely adopted in decades,

namely RTAI, Xenomai and PREEMPT-RT. All of them are equipped with required features of

RTOS including deterministic timing behavior, preemption and priority inheritance, however, they

are developed in different approaches. Both RTAI and Xenomai are dual-kernel based RTOS, while

PREEMPT-RT (RTL) with an In-kernel approach, is integrated into native Linux system.

With a long history, RTAI (Real-time Application Interface) are designed in a way to reach

the lowest latency for a couple of specific platforms, so most of real-time development are in kernel

space and its supported platforms are limited.

As shown in Figure 2.2, All the time-critical tasks are handled by the micro-kernel which

is patched to the Linux kernel with a HAL (Hardware Abstraction Layer), since the linux kernel

cannot directly deal with the hardware interrupts. However, RTAI is neither user-friendly nor easily

maintained, since the users are forced to compile their real-time threads as a module in kernel space

and the developers find it complicated to strike a balance between userland and the real-time kernel

modules which is closed-source.

In contrast, Xenomai is much more popular in the communities due to the real-time so-

lution in user space. With a similar infrastructure of RTAI, Xenomai (Figure 2.3) also maintains

HAL and ADEOS as micro-kernel with an interrupt pipeline (I-pipe) introducing a separate and

high-priority execution stage for running out-of-band interrupt handlers immediately upon IRQ (In-

terrupt Request Line) receipt, which cannot be delayed by regular Linux kernel. The main difference

is that, Xenomai provides a co-kernel (Cobalt) with higher priority than Linux kernel running in par-

allel for delivering real-time services with very low latency. Luckily, Xenomai developed it with

a skin which is an emulation layer providing APIs for different operating systems. So, users only

need to link their own applications against Xenomai’s POSIX skin (special libraries and APIs).

PREEMPT-RT also has a huge community though it emerged more than a decade ago.

The reason why PREEMPT-RT is highly accepted in community is that most of features like timer,

interrupt handling, priority inheritance, are developed in a preempted patch which is pushed back

into mainline of Linux kernel, such that users only need to take advantage of POSIX real-time pro-

gramming with the standard C library. This patch converts Linux into a fully preemptible kernel

mainly by making in-kernel locking-primitives (using sleeping spinlocks) preemptible and con-

verting interrupt handlers into preemptible kernel threads rather than in hard interrupt context. In

addition, PREEMPT-RT is quite accessible since it supports nearly every version of Linux kernels

7


and most of platforms, while the first two real-time solutions are limited. But the trade off is that

both RTAI and Xenomai perform better on latency than PREEMPT-RT, which is the reason why

both approaches are acceptable in industrial applications dependent on actual requirements.

Figure 2.4: Goal of Core-Isolation (from TOSHIBA)

2.1.3 Core-Isolation Technique

Other than the mainstream approaches mentioned above, people are always looking for a

more light-weight method to reach good real-time performance on part of the platforms on which

real-time extensions are not guaranteed. In [9], people often want to implement real-time control

on mobile robots built with an embedded system without a native Linux system running on it. So

Core-Partitioning (Core Isolation) Technique is much more reasonable since multi-core CPUs be-

come available for embedded systems nowadays such that both real-time applications (low-level

controllers) and general-purpose applications (high-level algorithms) can run on the same machine

for a robot control system. And the goal of core-iso technique (Figure 2.4) is to migrate the time-

critical programs and related drivers into an isolated CPU core by appropriately configuring mech-

anisms of Linux kernel, such as CPU affinity setting and IRQ binding. To be specific, the Core-Iso

technique removes the specified CPUs from the general kernel SMP balancing and scheduler algo-

rithms, which is especially useful if we want to dedicate some CPUs for special tasks with least

unwanted interruption in a multi-core system.

To compare real-time performance of PREEMPT-RT and Core-Iso technique, I set up

the stress test with a benchmark tool ’Cyclictest’ on two separate double-core machines, both of

which are running Ubuntu system. While one of them is compiled with a preempt-patched 3.14

kernel (Figure 2.5), the other one (in hyper-threading mode) uses the native 4.15 kernel with one

8


Figure 2.5: Latency test on PREEMP-RT Figure 2.6: Latency test on Core-Iso

of CPU cores or threads (CPU3 on the plot) isolated for time-critical events (Figure 2.6). From the

result of latency test, the real-time performance of Core-Iso approach is relatively better than that

of raw PREEMPT-RT approach, since all test samples can be guaranteed to maintain their latencies

within around 50 us and most of the them can be reduced to a tiny range less than 10 us, which

is pretty distinguishable in comparison with the other three CPUs running with the native Linux

kernel. Although the PREEMPT-RT approach also shows the capability to make both CPUs fully

deterministic, we have to compromise a much larger cycle time based on the maximum latency. I

haven’t test on dual-kernel approaches, but they are both more effective than PREEMPT-RT theoret-

ically. To acquire a desired performance via PREEMPT-RT, one thing is to reconfigure Linux kernel

modules in a more proper way, which means we’ll give up some time-consuming and high-priority

built-in functionalities as trade-off, since there could be multiple factors resulting in a bad real-time

performance. Another highly effective method is to patch the preempt kernel under a core-isolated

system for a more superior real-time performance.

It is worth mentioning that building a robot control system via Simulink Real-time is

also recommended. Thanks to the convenient and complete simulation-prototyping pipeline for

engineers and researchers, one can quickly put designed controller models into a real-time simula-

tions and debug them with visualization, by running them on a dedicated target computer hardware

equipped with a real-time kernel. I’ll explicitly compare the implementations on Simulink Real-time

with a Core-Iso based motor control system in the last section.

9


2.2 EtherCAT master design and real-time motor control

In this section, I’m going to introduce two open source EtherCAT masters, namely IgH

and SOEM, and demonstrate a real-time motor control system design based on SOEM EtherCAT

master with the background of core-isolated Linux system.

2.2.1 Open EtherCAT Masters: IgH & SOEM

One thing in common between IgH and SOEM is that both solutions helps users get rid

of the low-level development directly on EtherCAT protocol, but provides them with common APIs

for real-time applications.

As is integrated into the Linux kernel, IgH shows significantly superior real-time char-

acteristics than userspace solutions owing to the ability to handle timer interrupts and NIC driver

interrupts inside real-time kernels, such as RTAI, ADEOS, PREEMPT-RT and Xenomai, etc. Also,

IgH is more powerful and integrated by providing users with auxiliary functionalities such that it

encourages users to focus on specific high-level programs while SOEM emphasizes a lightweight

and simple design of the C library. For example, IgH runs with a automatic master FSM (Finite

State Mahchine) which is a EtherCAT slave manager dynamically adapting slave’s configurations

to the new topology and responding to requests from application-layer. In addition, IgH provides a

command-line tool in user space to display detailed information about master/slave configurations

and to list SDO dictionaries and reading/writing addresses. However, it’s because IgH’s architecture

is highly correlated to Linux kernels that only part of the obsolete Linux versions are supported.

This may be an impedance for development of new products when they are developed un-

der new Linux versions or based on updated peripheral devices, some engineers and researchers are

prone to uses SOEM with good sustainability and accessibility since it’s actively maintained using

APIs in native kernels, while it’s less user-friendly than IgH which can do all PDO configurations

automatically.

SOEM (Simple Open EtherCAT master) is a C library that offers methods to send and

receive EtherCAT frames. But users are benefit from its light-weight design, since they don’t need

to bundle the userspace applications with the EtherCAT library, which make the applications it-

self light-weight but still powerful and stable. But people have to configure PDOs and SDOs

aligned with determined memory addresses in their own applications, which might cause uncer-

tainties during development. Moreover, because SOEM is very new in communities compared to

IgH, some third-party EtherCAT slaves, especially actuators, are not well compatible, this becomes

10


time-consuming when users always have to confirm an acceptable match between SOEM and these

peripheral devices.

2.2.2 SOEM-based Motor Control Method

Before introducing the advanced robot control system, I’ll start with a motor control sys-

tem as a prototype which plays a fundamental role in further development. To set up the system,

I select the Ubuntu 16.04 system optimized with Core-Iso technique as the background of SOEM-

based EtherCAT master development at bottom level, while at upper level I implement closed-loop

PV and PD controllers on a Copley direct drive DC motor. As the control input, an absolute encoder

is used to send position reference to control the motor angle synchronously. To be practical, I deploy

the system with a force feed-forward controller implemented on a double-DoF light-weight gripper,

on which a couple of high-resolution pressure sensors is mounted to feedback external force exerted

on the gripper’s fingers.

Figure 2.7: Motor control test setup

In the motor control system shown in Figure 2.7, each motor drive regarded as a slave

communicates with EtherCAT master through CoE (CANopen over EtherCAT) protocol which is

a flexible asynchronous mechanism for transferring PDOs and SDOs via mailboxes. And motor

11


activation is achieved through DSP 402 protocol profile (CANopen profile for Device and Motion

Control), with which an integrated closed-loop PV control could be achieved in CSP mode.

Figure 2.8: Motor control diagram in CSP mode

As is shown in Figure 2.8, the controller generates a trajectory and sends position in-

crements, along with velocity and current feed-forward values, to the drive by using PDOs in the

parallelograms, while actual position, velocity and torque are closed in loops to make a cascading

feedback control with the position input. In general, these PDOs are pre-mapped in a specific order

(Table 2.2 and Table 2.1) and optimized by strengthened FPGA circuits in the motor drive’s firmware

for a high-frequency execution. Knowing the information of input/output PDOs, the EtherCAT mas-

ter can communicate with motor drives by data memory alignments, which is achieved by setting

up a structure in master’s local memory and matching up each of the PDOs in slave’s FMMU.

Name Index Type AccessStatus Word 0x6041 UINT16 RO

Position Actual Value 0x6064 INT32 ROVelocity Actual Value 0x606C INT32 ROTorque Actual Value 0x6077 INT16 RO

Position Error 0x60F4 INT32 RO

Table 2.1: Cyclic position input PDOs

As the EtherCAT master should execute and monitor required tasks in multiple states at

12


Name Index Type AccessControl Word 0x6040 UINT16 RW

Target Position 0x607A INT32 RWVelocity Offset 0x60B1 INT32 RWTorque Offset 0x60B2 INT16 RW

Table 2.2: Cyclic position output PDOs

runtime, I build a automatic FSM through SOEM’s APIs with the following routine:• Initialize SOEM and bind Socket to NIC.

• Set up mailboxes for supported slaves and request all to state PRE OP.

• Identify each slave by EEPROM number and Serial number.

• Create IOmap, configure the SyncManager’s and FMMU’s link to the EtherCAT master and

the slaves.

• Do custom configuration with PDO Assign and PDO Config via PreOP to SafeOp hook before

requesting state SAFE OP.

• Check slave’s states and initialize slave’s static parameters by SDOs before entering state OP.

• Fire cyclic loop and update slaves’ states by sending/receiving PDOs.

• Request state SAFE OP and close Socket.And to guarantee a consistent real-time control loop, I set FSM in a real-time thread by

setting CPU affinity mask of the thread to an isolated CPU dedicated for the EtherCAT master’s

tasks, and raise the scheduling priority higher than that of upper-level programs.

For third-party peripheral devices like encoders and sensors without EtherCAT support,

one can create a custom PDO assignment and mapping by interfacing Beckhoff EtherCAT terminals

and configuring customized cyclic data exchange through selective PDO mapping method instead.

The mechanism is that users are allowed to use ”Rx PDO Assign” object 0x1C12 and ”Tx PDO

Assign” object 0x1C13, in which the assignments for data input (RxPDO) and data output (TxPDO)

are defined, such that users get access to the IOmap which stores the information of input PDOs,

output PDOs and their mapping. Indeed, this paves the way to large control system development,

when each slave is thought of as an independent EtherCAT module.

One of the key issues is that servo control with a sequence of way-points as input often

comes with noise and vibration, which is unacceptable since the final robot requires smooth trajec-

tories and high-quality transient characteristics for the interaction with external environment, even

with human-beings. So a second order low-pass Butterworth digital filter with a 250Hz cut-off fre-

quency is designed and implemented on the raw reference signals. The step response and practical

performance are shown by figures below.

13


Figure 2.9: Low-pass filter response for an arbitrary position reference

By setting the default PV gains to zero, we can customize a PD controller with torque

input through Torque Offset PDO, while actual motor states including position, velocity and com-

manded torque are still accessible. In this way, not only the native position controller is preserved for

tests, but the EtherCAT master support a torque control scheme, which paves the way to admittance

control with force feedback, by easily switching among states of FSM.

2.2.3 Loaded Real-time Performance of EtherCAT Master

So far, I set up the real-time motor control system by building the SOEM-based EtherCAT

master in a dedicated mini-PC running core-isolated Ubuntu system. While a latency test in the last

section only tells the real-time performance for an idle system, a loaded latency test is prepared to

examine the practical performance when motor controller is running with EtherCAT frames updat-

ing in a 2kHz loop rate. Based on the measurement (Figure 2.10), the cycle time is stable at 500 us

with 10% fluctuations and the motor control test shows a pretty consistent performance over 10,000

cycles.

2.3 Gripper Control and System Identification

To design model-based controller for the gripper system, a system identification test is

implemented. Figure 2.11 demonstrates that the double-DoF gripper is actuated by two direct-drive

14


Figure 2.10: Loaded latency test

motors. During the test, finger2 is fully backdrivable and is followed by the bundled counterpart

finger1, which is driven by a motor through hydraulic transmission. The high-resolution pressure

sensors and an auxiliary encoder mounted on the gripper are used to measure chirp torque input

(Figure 2.12) and actual position response (Figure 2.13) respectively.

The torque chirp signal is generated using the formula (2.1).

s(t) = sin[2πf1T

ln (2πf22πf1)](e

tTln (

2πf22πf1

) − 1), (2.1)

where, f1 and f2 are initial frequency and final frequency separately, T is sweep time.

With torque input and position output, the dynamics of the gripper system Figure 2.14

can be estimated through Matlab DSP toolbox. The Bode plot roughly demonstrates the frequency

response of a second order linear system with corner frequency at 10 rad/s, such that the damping

ratio of the gripper can be acquired to determine system’s transfer function.

While in practice, we can measure this system model on the fly, by a linear regression

which calculate a computable second order polynomial to represent the system’s dynamics. A

more complex system with nonlinearity could be identified through an appropriate nonlinear model,

15


Figure 2.11: Chirp test setup

16


such as neural networks. For interaction with soft environments and human-beings, a model-based

impedance controller will be introduce and implemented in later chapter.

Figure 2.12: Torque chirp input to gripper system Figure 2.13: Actual position of grippers

17


Figure 2.14: Motor system identification

18

Chapter 3

Gripper Control System Design

The synchronous EtherCAT-based control design leads to a rigid and static application

which makes the development of dynamic large-scale applications cumbersome, and it also hinders

its maintenance and further improvements. So a efficient and sustainable infrastructure is designed

to enhance the compatibility and scalability for multi-functional deployments and accessibility to

the communities.

3.1 System Infrastructure Design

3.1.1 Design by parts

Figure 3.1: Infrastructure diagram of the system

The infrastructure diagram (Figure 3.1) demonstrates that the gripper control system as a

whole is divided into three parts: hardware, control PC and ROS master. Here, the control PC is

19

CHAPTER 3. GRIPPER CONTROL SYSTEM DESIGN

running the Ubuntu 16.04 system optimized via Core-Iso technique, and ROS master could be either

as a part if control PC or another remote PC. While, a C library (RDDA) is utilized for control im-

plementations with an abstraction layer which links to SOEM as an independent library interfacing

controlled target (gripper, actuators and sensors). Under this condition, one can develop a program

running controllers in a high-priority process in an isolated CPU core, and share input/output data

through the ROS interface (a ROS node) with other non-realtime ROS processes that are efficient at

implementing high-level algorithms and data visualization.

From the perspective of users, The reason that this infrastructure design is necessary is

that, high-level decision makers are benefited from the dedicated middle-ware infrastructure, which

requires interfacing hardware under a real-time background. And oftentimes, people are extremely

strict at control systems’ stability and robustness, the motor control driver keeps low-level control

tasks away from high-level imperfections, so even high-level applications become much complex,

the system could be relatively easier to maintain.

From the view of system interactions, as we can take a scenario that a information pro-

ducer is sending information by events to a consumer, the infrastructure shows two interaction

schemes with different decoupling features. To clarify,• Space decoupling: The interacting parties do not know each other. The producers send events

on an software bus (information manager) and the consumers get these events from this bus

as well. The producers do not usually hold references to the consumers, neither do they know

how many of these consumers are participating in the interaction, and vice versa.

• Time decoupling: The interacting parties do not need to be actively participating in the inter-

action at the same time. In particular, the producers might send some event while the con-

sumer is disconnected, and conversely, the consumer might get notified about the occurrence

of some event while the original producer of the event is disconnected.

• Synchronization decoupling: Producers are not blocked while producing events, and con-

sumers can get asynchronously notified (through a callback) of the occurrence of an event

while performing some concurrent activity. The production and consumption of events do

not happen in the main flow of control of the producers and consumers, and do not therefore

happen in a synchronous manner.On control PC, the data exchange between motor control driver and ROS interface process

is based on the DSM (distributed shared-memory) paradigm (Figure 3.2), which provides a shared

memory segment (tuple space) for synchronization and communication. The distributed interaction

model provides time provides time and space decoupling, which means that the producers and

20


Figure 3.2: Shared space: producers insert data asynchronously into the shared space, while con-sumers read data synchronously

consumers linked to a space maintain anonymous with each other. The DSM model, whereas,

doesn’t support synchronization decoupling, because the producers and consumers must push or

pull data from the tuple space.

On ROS master, because the topic-based publisher/subscriber scheme support all three

couplings, ROS master and ROS interface are allowed to operate independently. While ROS in-

terface is communicating with control driver synchronously, other ROS nodes are allowed to send

and receive messages through a topic-based communication scheme, which reduces coordination,

and thus synchronization between different nodes, and makes the resulting communication infras-

tructure well adapted to distributed environments that are asynchronous by nature, This is pretty

essential for mobile robots with large-scale systems. For example, we can mount the gripper as

a part onto a robotic arm which is mounted on a remote-control mobile robot, the basic plan on

this distributed system is that gripper, arm and mobile robot can communicate through ROS topics,

while each of them is operating independently at low level.

3.1.2 Schedule analysis

As shown in the schedule flow chart (Figure 3.3), the control driver and ROS interface are

running in parallel. The control driver has a private memory space in possession of low-level data

structures aligned with EtherCAT slaves’ memory. By an updating mechanism in the control loop,

part of the data acquired through EtherCAT frames in private memory space can be synchronized

to a user-facing memory space, which is shared with ROS interface to generate ROS messages for

21


Figure 3.3: Schedule Analysis of System

high-level ROS users.

3.2 RDDA Control Library

3.2.1 Design of RDDA

The RDDA (Remote Direct Drive Actuators) library is developed as a C wrapper of

SOEM library, as it’s based on SOEM’s APIs and POSIX APIs. The UML diagram (Figure 3.4

and Figure 3.5) demonstrate a detailed composition of the RDDA lib. And users are allowed to

develop programs on both EtherCAT layer and control layer. While the former offers the access

to SOEM’s APIs and EtherCAT IOs, the control layer provides controller implementers with more

expressive IOs and related methods, and avoids knowing about EtherCAT communications.

The control loop here is thought of as a critical section, since not only data updating

needs to acquire user-friendly data, but the ROS interface synchronizes them with ROS messages.

To avoid race conditions, a mutex is requested to protect the user-friendly data at beginning of

the control loop and is released after the data is updated. Thanks to the high priority and high

working frequency of the control driver process, the control loop always hold the mutex lock before

any other process request that, such that we can confirm a consistent loop rate and never be in

deadlock. But the high-level processes always have chances to impact the stability of the control

22


Figure 3.4: UML of EtherCAT layer

Figure 3.5: UML of user-friendly layer

23


loop, because they’re competing with the control driver process to acquire the updated data, so we

can’t guarantee a robust control system when interacting with external disturbances. What is even

severe is that, high-level abnormal operations on mutex lock may cause a failure when the control

driver is requesting the mutex. This will be further discussed and resolved later when introducing

ROS interface design.

The features of RDDA lib:• Dynamic setup of EtherCAT networks and memory space allocation

• Interface to control peripheral hardware on top of EtherCAT

• Automatic identification and configuration of EtherCAT slaves

• Initialization for starting states

• Automatic transition to OP mode for control loop

• Utilities for building up control loop

• Robust mechanism to protect data acquisition for multiple processes

3.2.2 Control implementations

So, the following routine shows how to use the RDDA control driver with utility functions

listed in Table 3.1.

Algorithm 1 How to write a control program with RDDA lib1: Initialize EtherCAT networks by initEcatConfig;2: Initialize user-friendly data structure by initRdda;3: Initialize user data states by initRddaStates;4: Mark control loop start time by rdda gettime;5: Implement controller in a real-time loop:6: while not shutdown do7: Mark the starting time rdda gettime;8: Implement Controller with user-friendly data structure;9: Sync user data with EtherCAT networks by rdda update;

10: Mark the end time by rdda gettime;11: Delay for the residue time by rddaStop;12: end while13: Shutdown EtherCAT networks and release allocated memory space

3.3 ROS-interface Development via Shared Memory

As mentioned in the infrastructure design, the ROS interface is developed to synchronize

data between control driver and a group of anonymous ROS applications though a shared memory

24


Methods Comments

initEcatConfig

Set up EtherCAT NIC and state machine to request all slaves to work properly.Params:ifnameptr: NIC interface pointer. (void*)return a virtual space for EtherCAT data as a pointer.

initRddaInitialize user data and robust mutex to shared memory.return a virtual space for user data as a pointer.

initRddaStates

Initialize the motors’ IOs and stabilize motors at launch time.Params:ecatSlaves: Low-level structure used to create the EtherCAT network space.(ecat slaves*)rdda: Upper-level structure used to create the space for user-friendly dataaccessed by control and ROS. (Rdda*)

rdda update

Synchronize the EtherCAT data with user data in a control loop.Params:ecatSlaves: Low-level structure used to create the EtherCAT network space.(ecat slaves*)rdda: Upper-level structure used to create the space for user-friendly dataaccessed by control and ROS. (Rdda*)

rdda sleep

Delay a specific amount of time in nanoseconds (ns) with system timer,and calibrate DC if it exists.Params:ecatSlaves: Low-level structure used to create the EtherCAT network space.(ecat slaves*)cycletime: The time interval that will be delayed in ns. (int)

rdda gettime

Get system time in microseconds (us).Params:ecatSlaves: Low-level structure used to create the EtherCAT network space.(ecat slaves*)

rddaStop

Close EtherCAT socket and free data structure space.Params:ecatSlaves: Low-level structure used to create the EtherCAT network space.(ecat slaves*)

Table 3.1: RddaProxy Class

25


space. To be straightforward, the ROS interface should observe actual states of motors and sensors

from the shared-memory, and then publish them to a topic that high-level ROS nodes subscribe to.

Conversely, it also retrieves the reference commands by subscribing to high-level ROS nodes before

updating the real-time data in shared-memory for the control loop.

3.3.1 Shared Memory Implementations

By definition, shared memory is is a type of memory that can be shared by multiple ap-

plications or processes with the intent of providing inter-processing communication (IPC) or avoid

redundant data copies. This is efficient by avoiding using another process for data sharing. In partic-

ular, the shared memory is only allowed to be requested by control driver process which generates

user-facing data and saves them to a part of RAM which can be accessed by all the processors in

the system. As a result, the ROS interface process can operate those data with both read and write

permissions by requesting a same piece of memory segment.

In general, there are two methods to create shared memory, System V and POSIX. They

offer a slight different interface, but the basic concepts are the same. The POSIX API is easier to

use than System V API, because it learned from the shortcomings of System V, though the later

method is more widely implemented.

Here, I’ll demonstrate the basic routine to create shared memory via APIs of both meth-

ods.

System V API:− key t ftok (const char ∗path, int id)

ftok returns a key based on the path and shared memory identifier, which is usable in shmget.

This function is used to generate a unique key for shared memory here, but sometimes we can

use a general variable. For these two arguments, the path could be a user-defined path that

always exists, and id could be a random value from 1 to 255 in Unix system.

− int shmget (key t key, size t size, int shmflg)

shmget is used to create a shared memory segment named with key and return the shared

memory identifier associated with key. Through this returned value, independent processes

could visit the same shared memory indirectly. shmflg is the permission access flag.

− void ∗shmat(int shmid, const void ∗shmaddr, int shmflg)

shmat attaches the shared memory segment associated with the shared memory identifier

specified by shmid to the address space of the calling process. When we generate a shared

memory, it cannot be visited by any process, unless we use shmat function. shmid is the

26


identifier acquired from shmget. shm addr is the address that we want the shared memory

attached to, and its generally 0, so that this address can be automatically selected by system.

shmflg is default to be 0.

− int shmdt (const void ∗shmaddr)

When a process is done with the shared memory segment, we should detach the segment

specified by shmaddr from the current process space, so that other process can visit this

segment.

− int shmctl (int shmid, int cmd, struct shmidds∗buf)

When all of the process are done, we can destroy this memory segment through shmctl

function, which also provides other options to operate on the shared memory.

POSIX API:− int shm open (const char ∗name, int oflag, mode t mode)

shm open works similarly by creating or opening a POSIX shared memory object identified

by a path name which is actually a file under /dev/shm. By setting the oflag, we let control

driver create the shared memory object and only let ROS interface open that existing object.

By setting the mode t, we give object’s read-write permission to the processes, which is the

same as changing the file mask in command-line. However, the control driver needs to operate

shared memory in kernel space because the SOEM EtherCAT master requests the NIC driver.

We have to use umask to preset the file’s mask before shm open.

− int ftruncate (int fd, off t length)

The shared memory object named by path or referenced by fd CAN be truncated to a size of

precisely length bytes. This is required in control driver, since the newly allocated bytes of

shared memory object are automatically initialized to 0.

− void ∗mmap (void ∗addr, size t length, int prot, int flags, int fd, off t offset);

mmap creates a new temporary mapping in virtual memory space of the calling process. The

starting address for the new mapping is specified in addr, which is the same as the truncated

memory size.

− int shm unlink (const char ∗name)

shm unlink removes the shared memory object name, and de-allocates and destroys the data

of the associated memory segment after all processes have unmapped the object. This is only

used when the control driver process is shutdown. It will send a request to ROS interface to

unmap the shared memory object before destroying it for both processes.

27


3.3.2 Robust Mutex Mechanism

Note that, the shared memory doesn’t have synchronization for multiple processes neither,

which means that we shall use condition variable and mutex to deal with the race condition, where

one process holds the shared memory while another one is trying to visit the shared memory. And

the condition variable can let the waiting process sleep instead of spinning in a loop which wastes

CPU resources. So if the ROS interface needs to send a reference commands to the control driver,

it requests the mutex before accessing to shared data and release that mutex after updating the data.

So the ROS interface could set condition variable and sleep until the control driver updates the

shared-data and activate the ROS interface.

The mutex and condition variable are often safe to use in multithreading, but might be quite

dangerous in IPC. In multithreadingm when a process is terminated, the shared memory space re-

quested by the calling process will be destroyed and all threads running in parallel will be shutdown.

However, in IPC, if the process containing the owning thread of mutex terminates while holding the

mutex lock, the next processes that acquires the mutex may go into a deadlock waiting until another

process release the mutex, while the terminated process holds the mutex without releasing it.

In this situation, the robust mutex mechanism will give notice of that abnormal termination

by the return value EOWNERDEAD with a call to the locking function pthread mutex lock,

and the thread it protects will be marked as inconsistent. So, both control driver and ROS interface

should ensure that the state is made consistent for reuse through pthread mutex consistent. And

if either application is unable to recover the state, it should unlock the mutex without a prior call to

pthread mutex consistent, after which the mutex is marked permanently unusable.

3.3.3 ROS package design

The ROS nodes as components of high-level applications, communicate with ROS inter-

face through two topics. rdd/joint cmds and rdd/joint stats. To control the gripper, the ROS

interface retrieves data from the shared memory and publishes these data as a custom message

JointStates (Table 3.3) to rdd/joint stats. Conversely, it delivers the reference signals to the

control driver by subscribing to rdd/joint cmds which ROS nodes sends JointCommands (Ta-

ble 3.2) message to.

Users can also control the gripper through a proxy class (Table 3.4) which provides Python

interface for ROS messages and related methods, such that they can use the ROS interface as a

Python module.

28


JointCommands Commentsfloat64[] pos ref position referencefloat64[] vel sat velocity saturation (max velocity)float64[] tau sat torque saturation (max torque)

float64[] stiffness 0 Nm/rad – 20 Nm/rad

float64 freq anti aliasraw loop rate with which users publish reference commands

to interface (generally below 500 Hz)

Table 3.2: Attributes of JointCommands

JointStates CommentsHeader header Timestamp

float64[] act ref actual motor position r.p.t. motor frame (rad)float64[] act sat actual motor velocity r.p.t motor frame (rad/s)float64[] ext tau external torque measured by pressure sensor (Nm)float64[] apl tau commanded torque applied to motor (motor current) (Nm)

int64 ts nsecint64 ts sec

Timestamp copied from control driver

Table 3.3: Attributes of JointStates

Attributes Commentsact pos actual position (2×1 double)act vel actual velocity (2×1 double)ext tau external torque (2×1 double)apl tau applied torque (2×1 double)ts nsec nanoseconds part of timestam (int)ts sec seconds part of timestamp (int)

joint upper bounds fingers’ closing limit w.r.p. motor coords (2×1 double)joint lower bounds fingers’ open limit w.r.p. motor coords (2×1 double)

joint origins fingers’ origins w.r.p. motor coords (2×1 double)Methods Comments

publish joint cmds

Publish joint commands to control driver.Params:pos ref: position reference (2×1 double)vel sat: velocity saturation (2×1 double)tau sat: torque saturation (2×1 double)stiffness: stiffness of fingers (2×1 double)freq anti alias: anti-alias frequency (double)

homing Fast look for fingers’ origins.homing cmd tau Fingers scan lower/upper limits and return to origins.harmonic wave Fingers do a sinusoidal wave.

Table 3.4: RddaProxy Class

29


3.4 ROS Interface Tests: Visualization & GUI

Two tests are designed to verify the performance of ROS interface and the Proxy class. And

both of the tests are prerequisites for advanced applications that will be introduced in the next

chapter.

3.4.1 Remote Tracking

In the remote test, the control driver generates a sinusoidal wave at 2 kHz as the actual motor

position and sends them to the ROS interface which publish them at 500 Hz to a remote machine run-

ning a ROS node on a general-purpose Ubuntu system. And the signals then are streamed through

a third-party ROS package plotJuggler which is developed based on QT5.

Figure 3.6: Remote control test

Figure 3.6 shows the sinusoidal reference sent from a remote machine to the control PC

with respect to a time series. As the position signal is updated exactly at 500 Hz, the remote

communication doesn’t impact much on the real-time performance on ROS side, though we are

unable to guarantee a stable period of callback functions. And this loop rate is high enough for an

upper-level application, particularly in ROS, so the ROS interface provides users with a stable and

efficient means to control the gripper by computation-massive algorithms.

In addition, benefited from the plotJuggler, users are allowed to monitor the real-time com-

mands and actual responses such that debugging a complex program becomes easier.

30


3.4.2 Gripper control via GUI

The other test is to control the gripper by a GUI which is a ROS node developed via pyqt4.

As shown in Figure 3.7, the GUI is required to control both position and stiffness by publishing

reference position and stiffness value to the control driver. And the sent position reference and

resulted actual velocity of one of the fingers (Figure 3.8) shows a good performance of remote

control, while there is a little bit of noise in actual velocity which could be filtered in the control

driver with the knowledge of the anti-alias frequency.

Figure 3.7: Results of GUI test

Figure 3.8: Position control through ROS interface

31

Chapter 4

Force Control Implementations

In this chapter, I’m going to introduce the force control and implement an impedance con-

troller with an adaptive stiffness. To control the gripper under unknown environments, a current-

based collision detection method is designed and tested in homing routine. At last, the teleoperation

is demonstrated to verify the adaptive impedance control and performance of the control driver and

ROS interface.

4.1 Implementation of a DoB-based Impedance Controller

4.1.1 Simple Impedance Controller

The ”simple” impedance control consists of driving an intrinsically low-friction mechanism

with force- or torque-controlled actuators, and using motion feedback to increase output impedance.

This approach makes no attempt to compensate for any physical impedance (mass, friction) in the

mechanism, so the actual output impedance consists of that due to the controller plus that due to the

mechanism.

If a robot is modeled as a multi-DoF inertia retarded by damping and subject to actuator and

environmental torques (a multi-degree-of-freedom version of the model shown in the Figure 4.1),

the robot’s dynamics is as (4.1):

M(q)q + C(q, q) +G(q) = Ta + Te, (4.1)

where q is a vector of robot joint variables, M is the robot inertia matrix (which depends on

the robots pose), C denotes nonlinear inertial coupling torques (due to Coriolis and/or centrifugal

32

CHAPTER 4. FORCE CONTROL IMPLEMENTATIONS

Figure 4.1: Single DoF model (Source [2])

accelerations), G is a gravitational vector, Ta is a vector of actuator torques, and Te is a vector of

environmental torques.

The target behavior is impedance, if the behavior of a spring with stiffness matrix Kj and a

damper with damping matrix Bj is chosen, the control law is simply as (4.2),

Ta(q, q) = Kj(q0 − q) +Bj(q − q), (4.2)

where Θ0 is a virtual trajectory in robot joint space. Combining the controller impedance

with the robot dynamics, the result is as (4.3),

M(q)q + C(q, q) +G(q) +Bj q +Kjq = Bj q +Kjq + Te. (4.3)

A nonlinear counterpart of the control law is (4.4),

Ta(x0, xo, q, q) = JT [K(x0 − L(q)) +B(x0 − J(q)q)], (4.4)

which is to achieve a target impedance with constant end-effector stiffness K and damping

B. This is derived from a transformation with transpose of Jacobian: Ta = JT (Θ)Fe, where each

robot actuator acts independently on a robot joint variable.

Note that, this ”simple” impedance controller does not rely on force feedback and does not

require a force sensor. If the forces due to the robot ’s inertia and friction are sufficiently small,

33


the robot’s interaction port behavior will be close to the desired impedance. Inertial forces decline

for slower movements and vanish if the robot is at a fixed pose. As a result, a simple impedance

controller can be quite effective in some applications. Frictional forces may also decline for slower

movements, but, especially due to dry friction, need not vanish when robot stops moving. This is

one reason why, for applications requiring low impedance, low inertia and friction are desirable in

the design of interactive robots.

The features of ”Simple” impedance controller:• From a controller design viewpoint, the controller closely resembles a PD motion controller

acting on the error between actual and virtual trajectory in joint space. Given the assump-

tion outlined above (a robot modeled as a mass driven by controllable forces) the impedance

controller stiffness K and damping B correspond, respectively, to proportional and derivative

gains. The nonlinear counterpart of simple impedance controller resembles a gain-scheduled

PD motion controller in which the nonlinear transformations adjust the proportional and

derivative gains to achieve constant end-effector behavior.

• As controller mimics the behavior of a spring and damper, the robot behaves as it would with a

real spring and damper connecting it to the virtual trajectory. If the virtual trajectory specifies

a constant pose, the entire system (robot plus controller) is passive, therefore, guarantees

stable interaction with all passive environment. Regardless of the actual robot mass, damping,

and controller gains, coupled instability is completely eliminated. In addition, because the

simple impedance controller does not rely on force feedback control to shape impedance, it

is not vulnerable to the loss of passivity that can occur when structural modes interact with a

force feedback loop.Thus, although it is primitive, a simple impedance controller goes a long way toward solving

the stability problem, and its performance gets better as the inherent robot impedance is reduced. In

practice, though this implementation performs well in some applications, it has limitations. Several

factors make the controller impedance non passive, including discrete-time controller implementa-

tion and unmodeled dynamics between actuator and sensor. Under these conditions stability cannot

be guaranteed with all environments. At the same time, the creation of low-impedance hardware

can be difficult, particularly for complex geometries. Still, the approach has been quite successful,

particularly when used in conjunction with highly backdrivable designs.

34


4.1.2 Force Feedback

Force feedback is an approach to reduce apparent impedance. If a simple impedance con-

troller is applied to a one-dimensional inertial mass as shown in the figure above, that is also subject

to some nonlinear friction force Fn(x, x), and is augmented with a proportional force feedback

controller, the control law is (4.5),

Fa = K(r − x) +B(r − x) +Kf [Fe +K(r − x) +B(r − x)], (4.5)

K and B are the scalar desired stiffness and damping respectively, and r now represents the

virtual position. The force feedback term serves to minimize the deviation of the actual endpoint

force from the desired endpoint force, which looks like a damped spring characterized by K and

B connected to the virtual trajectory. The equation of motion for the uncontrolled system with

nonlinear friction is (4.6),

mx+ bx+ Fn(x, x) = Fa + Fe, (4.6)

Combining the two equations, the controlled equation of motion is as (4.7):

m

1 +Kfx+

b

1 +Kfx+

Fn(x, x)

1 +Kf+K(x− r) +B(r − x) = Fe, (4.7)

This equation shows that the introduction of proportional force feedback reduces the appar-

ent mass and friction by a factor of the force feedback gain plus one 1 + Kf , so that (in principle)

arbitrary large force gains drive the actual impedance to the desired impedance specified by the con-

troller. Friction, inertia, or any other behavior, whether linear or nonlinear, is minimized. However,

the increasing gains toward infinity almost always leads to instability. As any real robot almost

inevitably exhibits resonance, any system under force feedback becomes non-passive for a force

feedback loop gain greater than unity and is, therefore, vulnerable to coupled instability.

The physical equivalent representation has negative stiffness, mass, and damping parameters

for any force feedback gain greater than 1 (Figure 4.2). Because endpoint force feedback is not

state feedback, isolated stability is unaffected; this system remains neutrally stable as long as the

interaction force Fe is zero. However, for Kf > 1, it is not passive; it can exhibit negative visco-

elastic behavior upon contact, resulting coupled instability. Note that this gain limit is independent

of the value of the structural stiffness and damping.

35


Figure 4.2: Relation between force-feedback and non-passivity of a coupled system (Source [2])

4.1.3 Natural Admittance Control

One effective solution to the loss of passivity due to force feedback is natural admittance

control (NAC), by Newman. [13] Natural admittance control specifies a desired inertia that is close

to that of the physical system (the natural admittance) and focuses on reducing friction as much as

possible, preserving passivity. The system might also have nonlinear friction that the NAC seeks

to eliminate, that need not be modeled at all in the design of the compensator, the controller treats

such friction as a disturbance from desired port behavior and rejects it. With the substitution v =

va = x = ve, the equation of motion for the system velocity neglecting nonlinear friction is (4.8),

mv + bv = Fa + Fe. (4.8)

In Laplace domain:

v =1

ms+ b(Fa + Fe). (4.9)

A generic form for the controller is assumed, that incorporates some velocity feedback with

compensator Gv(s) and endpoint force feedback with some compensator Gf (s):

Fa = Gvv +GfFe, (4.10)

Using two equations above, the actual endpoint admittance Y (s) = v/Fe is determined:

Y (s) =Gf + 1

ms+ b−Gv, (4.11)

36


This is equated to the target port admittance. The target stiffness K and damping B are

chosen at will but the target mass is equal to the physical mass m of the system:

Y (s) = Ydes(s) =1

ms+B + Ks

, (4.12)

From (4.11) and (4.12),

Gf =(b−Gv −B)s−K

ms2 +Bs+K, (4.13)

where, a simple form of Gv can be assumed as a constant such that the compensator design

is complete.

This equation can be thought of as a force feedback ”filter” that yields the desired admittance

Ydes. Although the mass is not reduced, the ”disturbance” to the desired behavior due to friction,

b, is rejected with the feedback gain of the compensator, and its effect is smaller as the velocity

loop gain, Gv, is increased. The approach serves equally well to minimize disturbances due to

nonlinear frictional forces, e.g., dry friction. In principle, the controlled system is passive even if the

velocity gain is increased to arbitrary size, minimizing the unwanted frictional effects. In practice,

unmodeled dynamics effects limit the gain that may be used without compromising passivity, but

the technique affords significant practical improvement over simple proportional force feedback.

4.1.4 DOB-based Impedance Control

DOB (Disturbance Observer) is widely used in industrial applications for robust control sys-

tem design, where external disturbance and model uncertainty are often immeasurable but critical to

be solved. In the sense of DOB, unmodeled dynamics and parameter perturbations are considered

as a part of disturbances which are estimated and then compensated by the observer. So for the

impedance/admittance control problem of the gripper, DOB helps realize an ideal system model by

compensating the friction and hysteresis as disturbances to the control plant, such that the modeling

of system uncertainties which is time-consuming, is not required. [4]

The basic idea of DOB is illustrated by the gripper control diagram as Figure 4.3. P rep-

resents the real physical plant, P−1n is the nominal model used for controller design, Q is a stable

filter, Fref is the output force of a PV controller, Fa is the commanded force from motor, Fp is the

measured force from pressure sensors, Ff is the lumped friction disturbance, Ffb is the estimate of

the lumped disturbance.

37


Figure 4.3: Conceptual diagram of disturbance observer

If the nominal plant of the gripper impedance is (4.14),

Pn =1

ms+ b, (4.14)

and the stable filter Q is chosen to guarantee the causality of the estimate disturbance, which

means that Q(s)P−1n should be proper, the control law could be represented as (4.15),

Fa = Fref +Q(Ff + (P−1 − P−1n )V ), (4.15)

which means that the friction Ff could be compensated in this way.

If the disturbance Ff was removed, the nominal plant P−1n would be the same as the real plant

P , and the inner loop with disturbance estimation and compensation is not activated. Therefore, a

PD/PV controller with Fref as output can be designed according to the nominal plant, with the

disturbance rejection of the inner loop.

Figure 4.4 illustrates a PV controller with position input and force outside the DOB. Other

than general impedance controllers, the PV gains Pp and Vp are allowed to be tuned, for sake of a

varying stiffness as a command from high-level ROS interface, such that a grasping strategy with

adaptive stiffness under unknown environments could be realized.

38


Figure 4.4: DOB-based impedance control

4.2 Collision Detection under Unknown Environment

While the light-weight mechanical design and the deployment of direct-drive brushless mo-

tors considerably improve the backdrivability, and the DOB-based control extends the range of stiff-

ness well adapted to environments’ impedance, a collision detection approach becomes another key

factor to improve both safety and capability during interaction with unknown objects, as it reduces

severity of impacts and raises the sensitivity when contacting them.

In this section, a couple of collision detection methods are introduced, while a sensor-based

method is implemented to the gripper system to detect static obstacles, which is demonstrated in the

homing function. In addition, an energy-based approach with blindness is proposed to complement

a object detection method with motion under an invisible condition.

4.2.1 Collision detection approaches without force sensor

In general, most collision detection algorithms rely on sensor data from incremental, absolute

encoders, current sensor, joint torque sensor, instead of measuring the contact force directly.

Current sensing method is popular since it’s intuitive and easier to implement. The main

idea is to check if the motor current or the commanded torque exceeds a threshold. However, it

can’t deal with the side effects of manipulator maneuver such as inertia change, coriolis, centrifugal

force, gravity, etc, which could be canceled by newly emerged approaches based on ROB (Residual

Observer) and DOB (Disturbance Observer). [10]

39


Figure 4.5: Momentum-based residual observer (Source: [5])

As shown in Figure 4.5, p = M(q)q represents the generalized momentum of a robot, and

the equation of motion is expressed as (4.1), by using the skew-symmetric property (4.16),

M(q) = C(q, q) + CT (q, q), (4.16)

the variation of energy is,

M(q) = Ttot+ CT (q, q)q −G(q), (4.17)

To define the residual as (4.18)

σ(t) = K[E(t) −∫ t

0(qTT + σ)ds− E(0)], (4.18)

where E(t) is the total energy of the robot, and the dynamics of the residual becomes (4.19).

σ = −Kσ +KqTT, (4.19)

As the Laplace transform of equation (4.19) has a form of low-pass filter, which indicates the

40


residual σ estimates the external torque T through a low-pass filter (4.20).

σ(s)

T (s)=

K

s+K, (4.20)

This is petty close to DOB, which cascades a Q filter at the output of the observer. And

since we have the pressure sensor mounted on the gripper, we can directly measure the collision

by calculating the momentum qTT , which means the actual toque results from acceleration of the

gripper can be measured though commanded torque and then be compensated by the measured

external torque. [11]

4.2.2 Homing routine with a current-based approach

For the homing routine, the gripper should sweep out the mechanical hardstops and calibrate

the origin of the fingers. The basic idea to detect hardstops is by measuring the commanded torque,

which will suddenly rise higher than the threshold.

Figure 4.6: Hardstop is hard to detect by pressure sensor

The commanded torque (current) is more distinguishable as the indicator of collision than

the external torque (pressure) for two reasons. On the one hand, the pressure value doesn’t change

much when it comes to the rotor or transmission hardstop (Figure 4.6), so the external torque at this

hardstop is hart to distinguish from threshold. On the other hand, the magnitude of commanded

toque (green) is much higher than that of pressure due to the DOB-based admittance control (Fig-

41


Figure 4.7: Commanded torque is distinguishable

ure 4.7), and always effective for any obstacle, though it’s less sensitive to the external torque owing

to some delay.

Figure 4.8 and Figure 4.9 illustrate the basic idea of homing routine:a) Phase1: Both fingers open until they detect the lower-bounds, which will be recorded after-

wards. The fingers may not reach the bounds at the same time, so the finger first reaching the

bound will wait for the other one. In the end, both fingers should stay static waiting for the

next step;

b) Phase2: Each finger closes and detects upper-finger before returning to the lower-bound. At

last, both fingers should stay at opening positions;

c) Phase3: Both fingers close simultaneously until they collide, and the origins are measured.

Note that, the origins are relative to the motors’ coordinates, which are determined when the

control driver starts running.

4.3 Teleoperation with gloves

In the teleop test (Figure 4.10), the gripper is controlled by a 2-DoF glove as a terminal of

the ROS master, which sends the actual position values of the absolute encoders mounted on the

glove to the control driver through ROS interface, such that the gripper could mirrors the gestures.

While the yaw angle is following the incremental angle of the encoder at wrist, the opening angle is

controlled by the encoder at index finger, which reads a relative angle against thumb.

42


Figure 4.8: Homing routine

43


Figure 4.9: Flowchart of homing function

44


Moreover, the stiffness, maximum velocity and maximum torque can be saturated through

ROS messages or the Python proxy class. This reflects the compatibility and scalability of the

gripper system with an asynchronous communication between control driver and ROS master. At

the end of the day, the gripper can be mounted on a robotic arm, and controlled by the arm users,

and the actual data could also be monitored on the fly through ROS interface.

Figure 4.10: Teleoperation with exoskeleton gloves

45

Chapter 5

Conclusion and Discussion

5.1 Conclusions

The main work may be summarized as follows:

• Introduction of a basic strategy to build an appropriate real-time optimized Linux system

based on existing approaches and the systematic plan to measure the latency.

• A SOEM-based design of an EtherCAT master interfacing direct-drive brushless motors and

a variety of analog sensors.

• An experimental verification via a simple closed-loop motor control to estimate the real-time

performance of the EtherCAT master.

• An distributed robot system infrastructure design based on the deployed EtherCAT master

and ROS.

− Development of a motor control library to synthesize features from SOEM and to pro-

vide APIs and input/output interfaces for peripheral devices.

− Development of a ROS interface based on shared-memory technique and robust mutex

mechanism to synchronize user-facing data between the control driver and ROS appli-

cations.

− A demonstration of ROS applications including remote control and visualization.

• The analysis of classic force control theorems to provide fundamentals for the implementation

of DOB-based impedance control and proposal of collision detection approach.

46

CHAPTER 5. CONCLUSION AND DISCUSSION

• Design of the homing routine for the gripper system using a current-based collision detection

approach with the limitation of mechanical hardstops.

• Demonstration of the teleoperation with gripper system and an exoskeleton glove.

One of the goals of this thesis was to put forward a new infrastructure of robot control system

for force control and interaction control, when both real-time performance and scalability play an

important role. The use of SOEM paved the way to the light-weight design of the control driver and

also the compatibility to general-purpose applications. When the control driver can be developed

on the basis of an independent library linking to the EtherCAT master, it becomes easier to be

implemented on other robots with similar hardware utilized. And the ROS interface bridges the

ROS users with their self-designed control algorithms, especially in Python environment, which let

the robot designs and experiments efficient and less expensive.

Another advantage is that the distributed system design makes the remote control or teleop-

eration easier to deploy. One reason is that the control driver is only required at bottom level on an

dedicated real-time machine, and any other application could be migrated to a general PC, which

could be sufficiently powerful to run complex computations and multi-thread tasks. The other rea-

son is that the dedicated machine could be isolated or sealed into a black box and communicate with

external excites via TCP/IP protocol under ROS, such that the robot could be deployed under water

or other dangerous environments.

In addition, the gripper system is equipped with high-resolution force sensors and adjustable

stiffness, which play an essential role in tactile-sensing and grasping tasks, since it becomes capable

to deal with soft and fragile objects in a more appropriate way.

5.2 Future Works and Directions

Real-time Optimization

As mentioned in the second chapter, the control program could run in the real-time kernel

patched by PREEMPT-RT in an isolated CPU. To pursue the extreme real-time performance, one

could even use FIQ (Fast Interrupt Request) mechanism which is specific for ARM architectures.

Improvement of Infrastructure Design

The FSM routine and the user data structure should be adjusted to support the history of

input/ouput data which can be directly accessed by control implementers and ROS users without

preprocessing at high level. Oftentimes, the history data are required in high-order filter design and

47

CHAPTER 5. CONCLUSION AND DISCUSSION

recurrent algorithm design. For instance, the previous two sensor data should be recorded for a

second-order filter for impedance controller in the gripper system. Furthermore, the computation

time of the control loop should be accurately measured to dynamically adjust the delay for a con-

sistent loop rate. On ROS side, the ROS package design should be studied more. For instance, the

standard message (e.g. sensor msgs/JointState.msg) should be utilized and the ROS services should

be used for remote procedure calls that terminate quickly, such as the homing function.

Object Detection and Grasping under Unknown Environments

The current-based approach is not intelligent when the robot is moving with accelerations,

particularly for a multi-DoF robot arm, since we can’t guarantee that all of the joints are moving

with a constant speed during tracking and grasping. So a more reliable strategy should be developed

to compensate the influence of robot’s dynamics and be able to detect an unknown object with good

sensitivity. Moreover, a basic routine could be created to locate an unknown object in a determined

workspace. In comparison, the Bayesian Monte Carlo approach could be implemented to globally

localize the object under cuncertain conditions through the estimation of a probability distribution

over the work space. [14] In addition, with the high-quality force sensor of the gripper, it’s possible

to identify an unknown object in a heuristic way. For example, one can build a data set from a variety

of objects knowing their stiffness, and train a model with this data set to estimate the grasping force

and configurations. [3]

48

Bibliography

[1] Daniel Renjewski Andrew Peekema and Jonathan Hurst. Open-source real-time robot opera-

tion and control system for highly dynamic, modular machines. ASME. International Design

Engineering Technical Conferences and Computers and Information in Engineering Confer-

ence, 7A, 2017.

[2] Neville Hogan & Stephen P. Buerger. Impedance and Interaction Control. CRC Press, October

2004.

[3] Roberto Calandra, Andrew Owens, Dinesh Jayaraman, Justin Lin, Wenzhen Yuan, Jitendra

Malik, Edward H. Adelson, and Sergey Levine. More than a feeling: Learning to grasp and

regrasp using vision and touch. CoRR, abs/1805.11085, 2018.

[4] W. Chen, J. Yang, L. Guo, and S. Li. Disturbance-observer-based control and related method-

san overview. IEEE Transactions on Industrial Electronics, 63(2):1083–1095, Feb 2016.

[5] Chang-Nho Cho, Joon-Hong Kim, Sang-Duck Lee, and Jae-Bok Song. Collision detection and

reaction on 7 dof service robot arm using residual observer. Journal of Mechanical Science

and Technology, 26(4):1197–1203, Apr 2012.

[6] Byoungwook Delgado, Raimarius & Choi. Real-time servo control using ethercat master

on real-time embedded linux extensions. In International Journal of Applied Engineering

Research, pages 1179–1185, 2017.

[7] Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The

many faces of publish/subscribe. ACM Comput. Surv., 35(2):114–131, June 2003.

[8] Philipp Seiwald Tobias Berninger Arne-Christoph Hildebrandt Daniel Wahrmann &

Daniel Rixen Felix Sygulla, Robert Wittmann. An ethercat-based real-time control system

49

BIBLIOGRAPHY

architecture for humanoid robots. In 2018 IEEE 14th International Conference on Automation

Science and Engineering, pages 483–490. IEEE, 2018.

[9] Jeongnam Kang Hyeongseok Kang, Dohyeon Kim and Kanghee Kim. Real-time motion con-

trol on android platform. The Journal of Supercomputing, 72:1573–0484, 2016.

[10] B. Jung, H. R. Choi, J. C. Koo, and H. Moon. Collision detection using band designed dis-

turbance observer. In 2012 IEEE International Conference on Automation Science and Engi-

neering (CASE), pages 1080–1085, Aug 2012.

[11] A. D. Luca, A. Albu-Schaffer, S. Haddadin, and G. Hirzinger. Collision detection and safe

reaction with the dlr-iii lightweight manipulator arm. In 2006 IEEE/RSJ International Con-

ference on Intelligent Robots and Systems, pages 1623–1630, Oct 2006.

[12] Yongseon Moon, Nak Yong Ko, Kwang-Seok Lee, Youngchul Bae, and Jongkyu Park. Real-

time ethercat master implementation on xenomai for a robot system. Int. J. Fuzzy Logic and

Intelligent Systems, 9:244–248, 2009.

[13] Wyatt S. Newman and Yuandao Zhang. Stable interaction control and coulomb friction com-

pensation using natural admittance control. J. Field Robotics, 11:3–11, 1994.

[14] A. Petrovskaya and O. Khatib. Global localization of objects via touch. IEEE Transactions on

Robotics, 27(3):569–585, June 2011.

[15] Soyeon Kim & Euncheol Shin. A performance evaluation of open source-based ethercat mas-

ter systems. In 4th International Conference of Control, Dynamic Systems, and Robotics,

2017.

50

Documents

An EtherCAT-based Real-time Control System Design for a ...m...Remote-Direct-Drive 2-DOF manipulator by Zikun Yu Master of Science in Mechanical Engineering, Mechatronics Northeastern