Performance Evaluation of Real-time Bilateral ...

Performance Evaluation of Real-time BilateralTeleoperation Systems with Wired and Wireless

Network Simulation

by

Stephen Liao

A Thesis submitted to the Faculty of Graduate Studies of

The University of Manitoba

in partial fulfillment of the requirements of the degree of

MASTER OF SCIENCE

Department of Electrical and Computer Engineering

University of Manitoba

Winnipeg

Copyright © 2012 by Stephen Liao

Abstract

This thesis presents a general simulation framework used for evaluating the performance

of bilateral teleoperation systems under consistent and controllable network conditions. A

teleoperation system is where an operator uses a master device to control a slave robot

through a communication link. The communication link between the master and slave

has an important impact on the system performance. Network emulation using ns-2 has

been proposed as a way of simulating the communication link. It allows for the network

conditions to be controlled and for repeatable results. The proposed setup was used to test

the performance of a hydraulic actuator under various conditions of wired and wireless

networks. Three control schemes were evaluated using various combinations of time delay

and packet loss. The system was also tested simulating wireless communication between

the master and slave to determine the effects of transmission power and distance on the

performance of the system.

i

Acknowledgments

I would like to thank my advisor Dr. Wai-keung Fung for guiding me throughout this

project. His patience and advice have been invaluable. I would also like to thank Mr.

Yaser Maddahi for being an excellent partner in helping me with the experiments. Thanks

to Dr. Nariman Sepehri and his students for welcoming me to their laboratory and provid-

ing great conditions to work in. Thanks to the Fluid Power and Telerobotics Laboratory

for providing the code for controlling the PHANToM haptic device. Finally, thanks to my

family for supporting me as I worked to complete this thesis.

ii

Table of Contents

Abstract i

Acknowledgments ii

List of Tables vi

List of Figures vi

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 6

2.1 Teleoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.2 Delay in Teleoperation Systems . . . . . . . . . . . . . . . . . . . 10

2.1.3 Bilateral Control Schemes . . . . . . . . . . . . . . . . . . . . . . 12

2.1.4 Performance Evaluation of Teleoperation . . . . . . . . . . . . . . 14

iii

2.2 Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3 Proposed Methods 24

3.1 General Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Network Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Co-simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2.2 Sequential Simulation . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Network Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . 31

3.3.2 Delay Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.3 Packet Loss Generation . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.4 Simulation Methods . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Experimental Investigation 41

4.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Dynamics of the Hydraulic Actuator . . . . . . . . . . . . . . . . . 42

4.1.2 Dynamics of the Master Device . . . . . . . . . . . . . . . . . . . 45

4.1.3 Control Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1.4 Master and Slave Programs . . . . . . . . . . . . . . . . . . . . . . 49

4.1.5 Communication Link . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Performance Evaluation Experiments . . . . . . . . . . . . . . . . . . . . 56

iv

4.2.1 Test Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.2 Experiments with Gradually Changing Time Delay and Packet Loss 59

4.2.3 Experiments with Random Time Delay and Packet Loss . . . . . . 67

4.2.4 Experiments using Wireless Communication without Obstructions . 69

4.2.5 Experiments using Wireless Communication with Obstructions . . 73

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5 Conclusion 82

5.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A Dynamics of the Hydraulic Actuator 86

v

List of Tables

2.1 Communication links used in the four-channel architecture . . . . . . . . . 14

4.1 Parameters of the hydraulic system . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Typical values for the path loss exponent β . . . . . . . . . . . . . . . . . . 55

4.3 Typical values for the shadowing deviation σ . . . . . . . . . . . . . . . . 55

4.4 Summary of the test scenarios . . . . . . . . . . . . . . . . . . . . . . . . 58

4.5 Average peak width for scenarios T01–T03 . . . . . . . . . . . . . . . . . 64

4.6 Wireless simulation parameters . . . . . . . . . . . . . . . . . . . . . . . . 70

vi

List of Figures

2.1 General teleoperation architecture . . . . . . . . . . . . . . . . . . . . . . 8

3.1 General architecture of the benchmark testrig . . . . . . . . . . . . . . . . 25

3.2 Class diagram for connection interface . . . . . . . . . . . . . . . . . . . . 26

3.3 Co-simulation and sequential simulation . . . . . . . . . . . . . . . . . . . 28

3.4 Block diagram of the network emulator . . . . . . . . . . . . . . . . . . . 31

3.5 Protocol stack of ns-2 in emulation mode . . . . . . . . . . . . . . . . . . 32

3.6 Class diagram for modifications to the network emulator . . . . . . . . . . 34

3.7 Emulation timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.8 Class diagram of the LinkDelay class hierarchy . . . . . . . . . . . . . . . 37

4.1 Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Schematic of the hydraulic actuator . . . . . . . . . . . . . . . . . . . . . 43

4.3 Direction of motion used for the master device . . . . . . . . . . . . . . . . 45

4.4 Flowcharts for the master and slave programs . . . . . . . . . . . . . . . . 50

4.5 Communication link setup . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6 The trajectory used in the experiments . . . . . . . . . . . . . . . . . . . . 58

4.7 Delay and packet loss profiles for scenarios T01, T02 and T03. . . . . . . . 60

vii

4.8 Typical master and slave positions for scenarios T01, T02, and T03 . . . . . 61

4.9 Typical master and slave position errors for T01, T02, and T03 . . . . . . . 63

4.10 Typical forces for scenarios T01, T02, and T03 . . . . . . . . . . . . . . . 65

4.11 Typical control signals for scenarios T01, T02, and T03 . . . . . . . . . . . 66

4.12 Time delay and packet loss profiles for scenarios T04 and T05 . . . . . . . 68

4.13 Typical master and slave positions for scenarios T04 and T05 . . . . . . . . 68

4.14 Typical forces for scenarios T04 and T05 . . . . . . . . . . . . . . . . . . 69

4.15 Probability of packet reception vs. distance . . . . . . . . . . . . . . . . . 71

4.16 Time delay and packet loss profiles for scenarios T06 and T07. . . . . . . . 72


4.18 Probability of packet reception vs. distance with obstructions . . . . . . . . 74

4.19 Delay and packet loss profiles for scenarios T08 and T09 . . . . . . . . . . 76


4.21 Typical forces for scenarios T08 and T09 . . . . . . . . . . . . . . . . . . 78

A.1 Plot of the friction force . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

viii

Chapter 1

Introduction

This thesis presents a general simulation framework used for evaluating the performance

of bilateral teleoperation systems under various consistent and controllable network con-

ditions. The focus of this thesis is on the emulation of the communication link, used by

the master and slave to exchange supermedia information. The supermedia information ex-

changed between the master and slave include commands sent from the master and sensory

feedback from the remote environment captured by various sensors installed on the slave

robot such as force feedback, video feedback, and audio feedback.

Teleoperation is the control of a robot from a distance in real-time. In a teleoperation

system, a human operator uses a master device to remotely control a slave robot. The slave

robot is commanded to follow the master device and perform desired tasks through inter-

actions with the environment. Bilateral teleoperation is defined as a teleoperation system

where force feedback from the environment is transmitted from the slave to the master. The

proposed framework employs ns-2 running in emulation mode to simulate the effects of the

communication link in bilateral teleoperation systems. A benchmark testrig was developed

1

CHAPTER 1. INTRODUCTION 2

to perform experiments on a simulated hydraulic actuator system with the purpose of eval-

uating the performance of the teleoperated hydraulic actuator under a range of network

conditions using wired and wireless communication.

1.1 Motivation

The main design goal of the presented benchmark testrig is to provide a framework to

accurately simulate the communication link in a teleoperation system. Traditionally, the

performance of teleoperation systems have been measured through experiments over un-

controlled networks such as the Internet [1] or through over-simplified emulated networks

with constant time delay only [2, 3]. These traditional approaches have some limitations.

For example, when using an Internet connection as the communication link, there is no

control over the delay or packet loss of the network, and results may vary between multiple

trials due to the network conditions changing over time. An experimental setup using ns-2

as a network emulator is able to simulate network conditions while overcoming the limita-

tions. One method of employing the network emulator is by using random variables. It is

possible to either use a probability distribution to generate similar network conditions as the

Internet or to use a random variable that replays empirical data collected earlier. Another

method employed by network emulators is to generate conditions based on a predefined

network topology and network parameters. Using these methods, the network emulator

will be able to generate network conditions that are controllable by the user and repeatable

for multiple tests. This will enable experiments to be designed to evaluate different aspects

of the teleoperation system under controlled network conditions, such as the performance


of different control schemes or the performance of different operators.

The other traditional approach used in experiments has been to perform tests with a net-

work emulator that generates constant delays or gives limited control over some network

parameters such as average delay and jitter. This approach has been traditionally used be-

cause of the relatively simple analysis of teleoperation systems with constant delay and the

availability and reliability of network emulators that generate simple delay distributions.

Although this approach allows for controllable and repeatable results, the simulated com-

munication link becomes too unrealistic and it is uncertain whether the results obtained

would be applicable to real networks that have time-varying delay. The framework us-

ing ns-2 as a network emulator allows for more flexibility by simulating communication

networks based on a specific network topology. Moreover, through modifications to the

network emulation code, protocol-specific network behaviors can be added into the sim-

ulation such as adjusting the network parameters based on the current control command

and ensuring that the supermedia streams [4] are synchronized. Therefore, the framework

using ns-2 network emulation can be used to evaluate systems in a wide range of network

conditions encountered in teleoperation systems.

Network emulation is the method used to realize real-time simulation or hardware-in-

the-loop simulation of the teleoperation communication link. In a normal simulation, all of

the data that passes through the network has been originated from software. The limitation

of this approach when applied to teleoperation systems is that the human operator or the en-

vironment may not be properly represented in a pure simulation. Without input devices that

are able to capture in real-time the operator commands and render the feedback received by

the slave, the operator does not get a proper sense of the environment and may react differ-


ently in the experiments. Moreover, hardware may be needed to properly interact with the

environment for dextrous manipulation tasks like peg insertion or changing of a light bulb.

With network emulation, live data that passes through the network may be received from

another host sending network packets through the local network and afterwards, the data is

forwarded to a target host. This way, the network emulator can be connected in between

the master device and slave device such that the master, slave, and communication link

components of the teleoperation system are properly represented and are able to interact

with each other in real-time.

1.2 Approach

There are two approaches to implementing the network emulation in an experiment. The

normal method is to run the network emulator and define a network topology, having the

delay and packet loss calculated as each packet is received. Another method, which is

termed the sequential simulation approach, is to run the network simulator, having it first

calculate all of the delays, and then run experiment, using the network emulator to replay

the recorded delays and packet losses. The replayed delays can also be collected from real

networks.

Experiments were conducted to test different control schemes of a hydraulic actuator

system with force feedback. The master consists of a PHANToM Omni haptic device [5],

which obtains velocity/position input from the human operator and renders force feedback

received from the slave. The slave consists of a simulation of a 1 degree-of-freedom (DOF)

hydraulic actuator coming into contact with a stiffness dominant environment. The system


was tested using the ns-2 network emulator to emulate a range of delays and packet losses

for the network conditions. In a second set of experiments, the sequential simulation ap-

proach was used to test the performance of the system when a wireless connection is used.

The effects of the distance separating the master and slave and the transmission power of

the wireless nodes on the performance of the system were observed.

1.3 Thesis Organization

The remainder of the thesis is as follows: Chapter 2 discusses the background of tele-

operation and network simulation. Chapter 3 introduces the benchmark testrig used and

the different approaches to performing the network simulation. Chapter 4 discusses the

experiments performed. Chapter 5 ends with the conclusion.

Chapter 2

Background

This chapter provides background on teleoperation systems and network simulation, which

are two major components of this thesis.

2.1 Teleoperation

The goal of teleoperation is to allow a human operator to interact with an environment by

remotely controlling a robot. In a teleoperation system, a human operator uses a master

device to remotely control a slave robot. The slave robot is continuously commanded

to perform a desired task and interact with the environment by following the operator’s

commands sent via the master device. A bilateral teleoperation system is a specific kind

of system where force feedback from the environment is transmitted from the slave to the

master.

Figure 2.1 shows the general architecture of a teleoperation system. There are five

components interacting with each other. The overall goal is to have the human operator

6

CHAPTER 2. BACKGROUND 7

perform tasks through the system to interact with the environment as if he/she is present in

the remote environment. The master input device is operated by the human operator, which

will in turn send commands to the slave robot. The slave robot interacts with the environ-

ment, and they exchange information through the communication link, which is necessary

due to distances or physical barriers, like in micromanipulation or nanomanipulation, that

separate the master and slave sites.

The master input device sends continuous commands such as position, force, or velocity

to the slave, which reflect the commands given by the human operator. After being trans-

mitted through the communication link, the commands are received by the slave, which

then executes the received command and makes an interaction with the environment. The

environment will have some kind of reaction to slave, and the slave will send back sensory

feedback, such as the position information, force information, or video feedback captured

by various sensors installed in the slave robot. These different streams of feedback are

called supermedia, and all channels of information must be synchronized [4].

The communication network used in a teleoperation system may differ from the net-

work used in a general system. The differences are in the requirements of the network. The

requirements of the network may include minimum time delay and packet loss require-

ments and synchronization between supermedia streams from the master to the slave and

vice-versa. Furthermore, the network performance may depend on the dexterity require-

ments during progress of the task [6]. These requirements imposed by the teleoperation

system may range from soft real-time to hard real-time.

The performance of a teleoperation system is determined by how well it allows the

operator to interact with the environment and complete the desired task. For example, in


Communication Link

Remote Robot(Slave)

Human Operator

Environment

Input Device(Master)

InteractionReaction

Feedback

Feedback

Feedback

Command

Command

Command

Figure 2.1: General teleoperation architecture

telesurgery, one of the goals of robotic telesurgery may be the ability to palpate soft tissues

for tasks such as locating tumors [7]. In order to do this, the operator must be provided

with a feeling of the environment being operated on. This is measured by the stability and

transparency of the system. Stability means that the output of the system is bounded with

bounded input, which is necessary for the operator to have any feeling of the environment.

A further measure is transparency, meaning how well the master is able to reproduce the

forces of the slave interacting with the environment. A teleoperation system having good

stability and transparency will aid the operator in performing a task such as feeling the

tissue for abnormalities during surgery.


2.1.1 Applications

As one of the first robotic applications, teleoperation was used by Raymond C. Goertz in the

1940’s for handling radioactive material [8]. The first applications of teleoperations were

where the master and slave devices were mechanically coupled together, and the distances

separating them were small. With the introduction of the communication link to transmit

information between the master and slave, it became possible for the master and slave to be

separated by larger distances, however, time delays became a factor in teleoperation sys-

tem performance. In the 1960’s the concept of supervisory control was introduced to deal

with the problems of time delay [9]. This is where some level of autonomy is introduced

at the local controller of the slave robot and the operator issues higher level commands

that may be symbolic in nature. It was not until the 1990’s that methods using Lyapunov

stability analysis and network theory were developed to determine the stability of bilateral

teleoperation systems [10].

Teleoperation has a wide number of applications including space and deep sea ex-

ploration and physical therapy [11]. One of the current applications of teleoperation is

telesurgery systems [12]. These are robotic systems that are designed to aid the surgeon’s

physical abilities when performing tasks. This is accomplished by providing extra sensors

such as stereoscopic 3D views of the patient and providing a scaled version of the forces

interacting with the patient [13]. The robotic manipulators are also able to perform dex-

trous tasks, and eliminate the operator’s hand tremor. The da Vinci Surgical System is a

commonly used robotic system for performing minimally invasive surgery [14]. It consists

of four articulated arms and a surgeon’s console where the operator is seated to handle


the master controls and view a 3D stereoscopic display of the operating field. In normal

cases, the master and slave sites are located within the operating theatre, however, in re-

mote telesurgery, the master and slave site are separated by large distances. In 2001, the

first transatlantic telesurgery demonstration performed using a ZEUS system to perform a

laparoscopic cholecystectomy over a dedicated high-speed fibre-optic network using asyn-

chronous transfer mode (ATM), in which the communication delay is well estimated and

almost constant [15].

Another application of teleoperation is live-line maintenance [16, 17]. The purpose of

using teleoperation for live-line maintenance is to allow workers to perform maintenance

tasks while keeping them at a safe distance away from high voltage power lines. The

benefits for maintenance workers include reducing danger and physical hardship, resulting

in increased productivity. In current applications, the workers are kept on-site at a distance

where the bandwidth and time delay of the communication channel is not a concern [17].

They use an interface to control a robot that performs maintenance tasks on the power lines.

The experience of the human operator is valuable in difficult and delicate tasks.

2.1.2 Delay in Teleoperation Systems

A problem in encountered in bilateral teleoperation systems is the problem of having in-

complete knowledge of the communication delay. The delay in teleoperation systems is

time-varying in most networks and it may even be random, as in the Internet. In general,

the effect of time delay is to destabilize a system. This is because a controller designed to

react immediately to errors will not respond appropriately when the system has a delayed


reaction [18]. The communication link introduces delays in the signals that are sent be-

tween the master and slave. The delay from communication networks can be divided into

three main categories: propagation delay, transmission delay, and queueing delay [19]. The

propagation delay is the time needed for a bit to travel from the source to destination and is

limited by the speed of light. The transmission delay is the time required for the network

to transmit the given data and is limited by the network bandwidth. The queueing delay is

the time that the data has to wait in queues before it is transmitted, and is limited by the

network traffic.

In large networks such as the Internet, the time delay is random. In fact, the probability

distribution of the delay in the Internet is not exactly known. Some of the reasons for this

are the changes in network traffic and usage over time, changes in the routing of packets

over time, and the additional delay caused by network protocols [20]. Since the delay

is inserted into the closed loop that is formed between the master and slave, the effect

of the delay is to destabilize the system [21]. The randomness of the delay complicates

the analysis and control of the system, however, a number of control schemes have been

proposed to compensate for the variable time delay.

It is important for the communication link to have consistent and controllable conditions

when evaluating the performance of teleoperation systems. For example, since the dynamic

routing of the Internet may cause routes to change within a matter of seconds [22], it is

possible for these changes to reflect upon the results of different runs of an experiment.

Clearly, the network characteristics must be consistent in order to perform experiments that

compare the performance of various control schemes or the skill level of operators.


2.1.3 Bilateral Control Schemes

The control schemes in bilateral teleoperation are designed to ensure the system’s stability

and transparency. The control scheme is an important factor in determining the perfor-

mance of the system. Different control schemes are designed to work for bilateral teleop-

eration and to compensate for the time-varying delays introduced by the communication

link.

Force Reflection, Position Error, and Hybrid Control Schemes

Three basic control schemes are the force reflection, position error, and hybrid control

schemes. In the force reflection (FR) control scheme [23], position commands are trans-

mitted from the master to the slave and the slave sends force feedback to the master. Force

feedback improves the operator’s performance because it helps him/her to avoid applying

excessive forces, to estimate mass or friction of objects, and to provide information about

the environment [24].

In the position error (PE) control scheme [25], the force feedback sent to the master

depends on the error in position between the master and slave. The position error feedback

helps to inform the operator of errors in position tracking instead of giving the operator a

feeling of the interactions between the slave and the environment. The advantage of this is

that the cost of implementing force sensors on the slave is eliminated [25].

The hybrid (HB) control scheme [26] is a combination of the force reflection and posi-

tion error control schemes. In this case, the force feedback is proportional to the force of

the slave interacting with the environment and the position error between the master and


slave. Therefore, this control scheme is able to provide the operator with the advantages of

both the force reflection and the position error control schemes.

Arcara and Melchiorri [27] found that the force reflection and position error control

schemes are stable under constant time delay depending on the selection of the controller

parameters. The hybrid control scheme was found to be stable for constant time delays

through experiments in [26]. The experiments in this thesis will test to see whether the

control schemes remain stable with time-varying delay and packet loss.

Four-Channel Architecture

A model architecture for a bilateral teleoperation system is the four-channel architecture

introduced by Lawrence [28]. The four-channel architecture consists of a master and slave

that transmit velocity and force between each other in four channels. The four channels are

the force and velocity sent from the master to the slave and the force and velocity sent from

the slave to the master. Many teleoperation control architectures transmit information that

can be categorized as a subset of the four channels. One such simplification of the four-

channel architecture is the position-position architecture [29], where there are two channels

transmitting position and the channels transmitting force are not used. Another architecture

is the position-force architecture [30], where force is not transmitted from the master to the

slave and position is not transmitted from the slave to the master. Table 2.1 summarizes the

communication channels used in these control architectures.


Table 2.1: Communication links used in the four-channel architecture. The four channelsare labelled C1–C4 and the direction that information is transmitted is specified. The chan-nels used by the position-position architecture and the position-force architecture are alsospecified.

Channel Direction Position-Position Position-ForceVelocity Channel C1 master to slave used used

Force Channel C2 slave to master not used usedForce Channel C3 master to slave not used not used

Velocity Channel C4 slave to master used not used

Other Control Schemes

The four-channel architecture was originally designed to compensate for constant time de-

lays. Other sophisticated control schemes have been designed to compensate for variable

time delays in bilateral teleoperation. These include the scattering transformation [31],

wave variables [32], H∞ robust control [33], shared compliant control [34], and wave vari-

ables with prediction [1]. Another control method designed for teleoperation systems with

variable delay is event-based control [35].

Control schemes such as the scattering transformation and wave variables rely on pas-

sivity theory to prove that the system is stable. Passivity theory works on the concept of

energy. A passive system is one that only consumes energy and does not create any new

energy. Thus, by proving that a system is passive, it is also proven that the system is stable.

The event-based control method is proven to be stable through Lyapunov stability theory,

which also proves that the system does not create any energy [36].

2.1.4 Performance Evaluation of Teleoperation

In order to judge how well a teleoperation system works, measurements are needed that

rate the performance of the system. The difficulty with coming up with such measurements


is that the human operator and the environment are factors that can be unknown or unpre-

dictable. Two indicators for the performance of teleoperation systems are the stability and

transparency.

Stability refers to whether a system can maintain a bounded output for a given bounded

input. Stability is essential for any teleoperation system, but another desired characteristic

is the ability for the master and slave to provide a faithful transmission of signals, such that

the operator feels as if he/she is present at the remote site. This feeling is referred to as

telepresence. In order to achieve telepresence, measures of a system’s transparency were

introduced, which indicate how well the slave is able to follow the commands issued by

the master and how well the master is able to get force feedback from the environment

transmitted by the slave. Using the two-port network representation, the transparency is

defined as the ratio of the environment impedance to the impedance of the master, where

perfect transparency is achieved when the ratio is unity, meaning that the position and force

information is seemlessly transmitted [28].

In a bilateral teleoperation system, a way to measure the transparency is to evaulate the

position tracking and force tracking of the system. Position tracking refers to how well

the slave robot is able to follow the position of the master device when the operator is

controlling it. Force tracking refers to how well the master robot is able to reproduce the

interacting forces of the slave robot with the environment. If the system exhibits good posi-

tion tracking and force tracking, telepresence will be achieved and the human operator will

have a feeling that he is directly interacting with the environment. Thus, remote dextrous

manipulation tasks, such as telesurgery, can be achieved.


2.2 Network Simulation

There are three different methods for evaluating the performance of computer networks.

They are through mathematical analysis, numerical simulation, and experiments. Each of

these methods have their own advantages and disadvantages.

Mathematical analysis involves using mathematical models that represent the commu-

nication network. The statistics of the system are calculated based on the model used.

Examples of mathematical models include queueing theory models, Markov models, and

Petri nets [37]. The disadvantage of using mathematical models is that when the network

involves many interconnected nodes, the analytical solutions become very complex or even

intractable [38]. The experimental approach is the most accurate method for producing

the conditions that occur in practice, however, experiments may be too costly or time con-

suming to implement. Numerical simulation is a good alternative to the experimental and

mathematical approaches. Numerical simulations allow for systems to be modelled that

cannot practically be modelled with experiments or with mathematical analysis. It yields

results that can be verified and repeated and allows for a wide variety of networks to be

tested.

Floyd and Paxson [22] explain some of the advantages and disadvantages in using sim-

ulation to model complex networks such as the Internet. The difficulty when creating a

simulation of a network such as the Internet is that there is a lot of heterogeneity. This is

due to some factors such as constantly changing topology of the Internet and the dynamic

routing that may cause paths to change in the span of days or seconds. There does not exist

a set of simulation scenarios that can fully evaluate the performance of a system over a


network such as the Internet [22].

There are many different network simulators available to researchers. They can be cat-

egorized as either time-based or discrete event-based and either packet-level or flow-level.

In time-based simulations, the simulation keeps track of the current time and increments the

time for each time step, checking to see if any events have occurred. In discrete event-based

simulations, the time is also tracked simulation, but the simulation time is not advanced in

regular increments. Instead, time advances forward to when the next event occurs. Many

network simulators are discrete-event simulators. However, because the time does not reg-

ularly advance, the discrete-event simulation has to be modified for network emulation in

real-time applications.

The category of packet-level and flow-level simulators refer to the level of detail used

in the simulation to model the network. Packet-level simulators base their events off the

reception of singular packets, whereas flow-level simulators use models such as the fluid-

flow model to approximate the low level details of the communication network [39, 40].

With packet-level simulators, the transmission of each packet through the network protocol

stack is modeled. In flow-level simulations, packets are grouped into flows, which are all of

the packets belonging to the same connection. The advantage of flow-level simulations are

that they require less memory and CPU usage, and therefore larger networks can be simu-

lated. However, flow-level simulations are only an approximation, and in general they are

not as accurate as packet-level simulations. Noticeably absent from flow-level simulations

are application-specific data, meaning that the actual data transmitted by the network appli-

cation is not a part of the simulation, and thus they cannot achieve network emulation. The

next section describes three common network simulators available to researchers: OPNET,


GTNetS and ns-2.

OPNET

OPNET Modeler [41] is a commercial network simulation tool. It can be used for flow

analysis to model the steady-state behavior of a network or for discrete event simulation,

where the transmission of packets is simulated. Network scenarios can be specified man-

ually or automatically generated through the GUI interface. Furthermore, there are many

features that are built into modules, which implement the behavior of subnetworks, nodes,

and links. In addition to the core modules that are provided with OPNET Modeler, addi-

tional modules written in C++ can be added to the simulator.

One of the additional modules for OPNET is the System-in-the-Loop (SITL) module

[42], which allows the network simulation to be connected to network hardware or software

via Ethernet or wireless LAN. The simulation must be configured with Gateway nodes,

which will transform received packets into simulated packets and also create real network

traffic to send through the network.

GTNetS

The Georgia Tech Network Simulator (GTNetS) is a network simulation environment de-

signed for large-scale simulations [43]. It is a packet-level simulator where the transmi-

sision of each packet is modelled, and it attempts to closely follow the design of actual

network protocol stacks in practice. The design of GTNetS is also focused around dis-

tributed simulation and scalability. In a GTNetS simulation, part of the network might be

simulated on one computer and another connected part might be simulated on another com-


puter. They are connected together through Remote Links [43], which are links that allow

the simulation information to be transferred seamlessly among simulation parts that may

be on other computers.

GTNetS uses a protocol graph that is similar in design to the open system interconnec-

tion (OSI) protocol stack model [44]. Each layer is handled by a specific subroutine that

processes the packet headers and addresses that are specific to that protocol layer. Once

a packet is ready to be received by the application, a port map will forward the packet to

the appropriate destination. The port map mimics the functions of port on a real network

and allows for multiple applications to operate simultaneously on the same host. After pro-

cessing, the task of sending the packet out is delegated to a network interface object. The

network interface object keeps track of whether the link is busy or not, the packet queue,

and the associated link with the propagation delay and link bandwidth properties associated

with it.

GTNetS was also designed with object-oriented programming (OOP) in mind. Similar

to the OPNET simulator, the simulation program is designed such that different modules

can be inserted for the protocols and other aspects of the network simulation such as queues,

routing protocols, etc. One drawback of GTNetS is that currently, there is no implemen-

tation of network emulation. For teleoperation experiments that involve hardware-in-the-

loop, e.g., input from the operator that is obtained from a haptic device or a real slave robot,

GTNetS is unsuitable.


ns-2

The Network Simulator Version 2 (ns-2) is a simulation tool used to study the behavior of

communication networks [45]. It is an open source simulation program that was developed

as part of the Virtual InterNetwork Testbed (VINT) project to provide researchers with

a standard tool to design and analyze Internet protocols [46]. ns-2 is a widely-used tool

among researchers [44]. According to a review of Mobile Ad Hoc Network (MANET)

research [47], ns-2 was used in over 40% of the network simulation studies.

Similar to other packet-level simulators, ns-2 models many of the layers of the protocol

stack. All of the objects have references added to the simulation object, which is used to

control the overall progress of the simulation. Similar to GTNetS, there are classes that

handle each layer of the protocol stack. Using ns-2, the user has the option of adding

application data to the transmitting packets or removing it from the simulation. The rea-

soning for this is that in many applications, the specific application data does not need to

be modelled in order to simulate the characteristics of the network.

ns-2 uses a two-language architecture. The core components are written using C++

and the configurable parameters as well as addons are written in the scripting language

Object oriented Toolkit Language (OTcl). The advantage of using the OTcl language for

configuration is that the program does not need to be recompiled each time the simulation

scenarios are modified. However, when designing modifications to ns-2, extra work is

required to make implementations accessible through both the C++ and OTcl interfaces.

The advantages of using ns-2 are that it is a widely-used network simulator that is open-

source and includes extensive documentation. There is a lot of flexibility for new protocols


and new functionality to be written into the simulation program as desired. With ns-2,

many of the details of the protocol stack are implemented in the simulation, with some as-

pects of the physical layer and application layers left missing. ns-2 supports many different

protocols and also supports the simulation of both wired and wireless networks. One of

the disadvantages of using ns-2 is that due to the complexity of creating new classes to fit

within the program structure, implementing new protocols to test can be a time consuming

task. This is in contrast to other network simulators such as GloMoSim, where the imple-

mentation of new protocols is easier [48]. The protocol has to be implemented two times:

once for the network simulator and once for the real implementation.

Currently, the sucessor to ns-2 called ns-3 is under heavy development [49]. ns-3 is a

complete rewrite of the ns-2 code that does not provide backward compatibility. ns-3 uses

C++ at the core, with Python as the optional scripting language. Since ns-3 is a relatively

new network simulator, it currently does not have as many modules and documentation as

ns-2. Some of the planned goals of ns-3 include designing the simulator for scalability

using approaches similar to GTNetS and providing a sockets interface for applications to

send data through the simulator [49].

ns-2 has been chosen as the platform for network emulation in the proposed simulation

framework. The reason for choosing ns-2 over alternatives such as GTNetS and ns-3 is the

flexibility and extensibility of ns-2. Although OPNET is a viable alternative that provides

modules allowing hardware to be connected to the simulation, open source software such

as ns-2 is less expensive and provides more flexibility, since users have access to all of

the code. ns-2 is a widely-used simulator, and it provides the user with documentation

and the ability to extend any aspect of the simulation. This includes the ability to add


new protocols or behaviors to the simulation. ns-2 also features an emulation mode, which

allows it to function as a network emulator. Some of the disadvantages of ns-2 include the

complexity of designing for its dual-language architecture and its lack scalability compared

to simulators such as GTNetS, however, these disadvantages are not significant drawbacks

using the proposed approaches. In future work, ns-3 may be selected as the simulation

platform because of the improvements planned over ns-2.

2.3 Related Work

Researchers have performed a number of experiments and simulations for Internet-based

teleoperation [4, 50]. In [4], teleoperation experiments were performed between operators

in the United States and the remote site located in Hong Kong. In [51], experiments were

performed using event-based control and simulated communication delays generated from

a probability distribution with pre-set mean and standard deviation. Experiments in [52]

used a simple network emulator with a specified delay and packet drop percentage to test a

passive control scheme. Other experiments using network emulation have been performed

using constant time delays [53] and time delays that were generated from measurements

over the Internet [54].

Rodríguez-Seda, Lee, and Spong [55] compared different control architectures by us-

ing a Markov-model based network simulation tool. Zarei-nia et al. [56] compared the

performance of various control schemes for a teleoperated hydraulic actuator system. This

work was extended by Maddahi et al. [26], who tested the hydraulic actuator system under

constant time delays generated by a network emulator. Esfandiari et al. [57] also compared


the performance of a hydraulic actuator system with constant communication delay and

deformable environments.

2.4 Summary

In this chapter, some background and related work about teleoperation systems have been

introduced. The definitions of a bilateral teleoperation system were reviewed, showing

the major components that make up the system. Two applications of teleoperation are

telesurgery systems, and live-line maintenance. In these cases, the use of teleoperation

give benefits to the operator and in the ability to perform the tasks. The different con-

trol architectures were briefly discussed, using the four-channel architecture as a model

architecture for bilateral teleoperation. Moreover, some different control schemes that are

employed to compensate for time-varying delays in teleoperation were introduced. In the

second half of the chapter, network simulation was described. The numerical simulation

approach was compared to other approaches for performance evaluation such as mathe-

matical analysis and experimental approaches. Lastly, two different simulation packages,

GTNetS and ns-2 were overviewed. In the next chapter, ns-2 will be further discussed,

specifically, the methods used to perform teleoperation simulations.

Chapter 3

Proposed Methods

This chapter explains the methods used to set up the proposed benchmark testrig for a

bilateral teleoperation system under various communication delays and losses.

3.1 General Framework

Figure 3.1 shows a block diagram of the general simulation framework for teleoperation

systems. In this setup, the modular design allows for different modules to be plugged into

each of the four components. For example, either a force-feedback joystick or a multi-DOF

haptic device could be plugged in as the master device, the slave robot could be a robotic

manipulator, a mobile robot, a simulated robot, or a virtual avatar. The network emulator

could be implemented by a physical connection or any network emulation software such as

ns-2, WANem [58], and so on.

The information sent between components could be related to the system dynamics

such as position, velocity, and force information, or it could be other types of feedback

24

CHAPTER 3. PROPOSED METHODS 25

EnvironmentSlaveNetworkEmulatorMaster Device

Figure 3.1: General architecture of the benchmark testrig. Dashed lines indicate the UDPconnection interfaces.

such as video and audio feedback. Each of the components may be implemented in ei-

ther hardware or software and also, the connections between the components may vary. In

the case that two connected components of the testrig are implemented within the same

program, such as the case when the slave and environment are both implemented in one

simulation, the links between the components are programmatic interfaces. In the case that

the components are implemented by two different pieces of software, or implemented in

hardware, the two connected components will communicate to each other through User

Datagram Protocol (UDP) socket connections. UDP is chosen as the communications pro-

tocol over Transmission Control Protocol (TCP) because the lack of retransmissions and

rate control can give it a higher and more constant throughput [52].

In all cases, the interface between the components should follow the same structure so

that the programs do not need to be modified to communicate with a specific module. It

should also be noted that the different components may be running in their own event loops.

For example, the program for the master device may require a loop that updates the force

at rates as high as 20 kHz [59] to properly render the haptic feedback, whereas the network

emulator may be running at a much slower rate.

Figure 3.2 shows the class diagram for the connection interface. The Connection

interface has two key methods: send and receive. The send method is used to transmit


data between components and the receive method is used to check the receiving buffer to

see if any data has been received. Both methods are nonblocking in nature, meaning that

invoking these methods will not cause the program loop to wait until the operation is com-

pleted. The Connection interface has two implementations: a program connection and

a UDP connection. ProgramConnection is used as a programmatic implementation

of the Connection interface in the case that two components of the experimental setup

are implemented within the same program. The SocketConnection is another class

that implements the Connection interface. This class acts as an adapter of the Windows

Socket API (Winsock) [60]. It uses the nonblocking Winsock UDP commands sendto

and recvfrom to send and receive information between different components of the ex-

perimental setup that may be implemented in hardware or software. Other implementations

may be added, which would allow the framework to operate on other platforms.

1 1

« interface »Connection

+ send(bu�er, length : int)+ receive(bu�er, length : int)


ProgramConnection


SocketConnection

+ sendto()+ recvfrom()

Winsock

Figure 3.2: Class diagram for connection interface


In the following sections, different implementations of the testrig will be discussed.

In the first section, approaches that are focused on the simulation, i.e., where all of the

components of Figure 3.1 are modeled in software, will be discussed. These approaches are

important because they offer the advantages that simulation offers and they are important

to understanding how the experimental testrig with hardware-in-the-loop is setup. In the

next section, network emulation will be introduced as a way to perform hardware-in-the-

loop simulations, i.e., where part of the components are implemented in hardware, for

teleoperation systems. This will lead to the experiments performed using a haptic device

and hydraulic actuator simulation.

3.2 Network Simulation

This section discusses two different approaches that are used to perform simulation of a

teleoperation system where all of the components are implemented in software. In this

section, the terminology “system dynamics” will refer to the dynamics of the undelayed

teleoperation system, i.e., when the communication link used provides perfect transmis-

sion without delay or loss. The different approaches to simulations come from the fact

that the dynamics of the system without any delays and the simulation of the communica-

tion channel have traditionally been implemented in separate software packages. The first

method, termed co-simulation, is where the dynamics of the teleoperation system and the

network are simulated simultaneously. The other method, called sequential simulation, is

where the system dynamics and the communication network are simulated in two different

steps.


3.2.1 Co-simulation

Co-simulation, introduced in [61] for networked control systems, is a method where the

system dynamics and the communication link are simulated in one step. The advantages

of this approach are that it can accurately model many of the effects of teleoperation such

as synchronization of data streams and the transmission of packets between master and

slave in a closed loop. Figure 3.3a shows the steps taken by the co-simulation approach.

It consists of running two separate modules simultaneously: a module for the network

simulation and a module for the system dynamics simulation.

Start

Finish

NetworkSimulation

DynamicsSimulation

generate delay/loss

update system

Simulation Program

(a) Illustration of the co-simulation approach

NetworkSimulation

Finish

Start

generate trace file

generate system output

ODESolver

(b) Illustration of the sequential simulation ap-proach

Figure 3.3: Co-simulation and sequential simulation

During each loop of the program, execution switches between the network simulation

and the dynamics simulation. The function of the dynamics simulation is to compute the

next state and output of the master based on the state and the inputs received at the current

time instant. Similarly, the next state and output of the slave is calculated. Once the out-

puts of the master and slave are calculated, the setpoints are ready to be transmitted through

the communication link. At this point, the network simulation would be used to calculate


the delay and packet loss that result from transmitting the information through the com-

munication link. In the next time instant, another loop of the dynamics simulation is run

again, with the delayed inputs and the updated state. This cycle of the program continues

throughout the execution of the simulation, with a loop of the dynamics simulation and the

network simulation running at each time instant.

The components of the simulation are implemented as follows. The system dynam-

ics are calculated using an ordinary differential equation (ODE) solver such as the built-in

solver for MATLAB [62], Octave [63], and so on, which are linked into the simulation

program. An extension to ns-2 such as the Agent/Plant extension [64] could be used to

facilitate the connection between the simulated network and the simulated system dynam-

ics. However, to simulate a teleoperation system, this extension would need to be modified

to be able to incorporate the exchange of real information between the master and slave,

synchronization between data streams, and other characteristics of teleoperation systems.

3.2.2 Sequential Simulation

An alternative approach to using the co-simulation method is to use two separate simulation

programs, and run them sequentially. This concept was applied by Pérennou et al. in devel-

oping the W-NINE wireless network emulation platform [65]. In this approach, illustrated

in Figure 3.3b, the network is first simulated by running a network simulation program.

The program simulates the exchange of control information and sensory feedback for the

entire course of the experiment and outputs a tracefile containing the resulting delays and

packet losses. It should be noted however, that the packets sent through the simulator are


“fake”, in that they do not contain the actual control information. Afterwards, the delays

and losses are replayed in the dynamics simulation.

The advantage of the sequential simulation approach is that it is easier to design and

implement. The system dynamics simulation can be used in combination with existing

network simulation software, and the software does not need to be specifically modified to

work together. Instead of trying to integrate all aspects of the system into one simulation

program, the focus can be put on the design of each part separately. However, the accuracy

of the simulation is reduced because realistically, the communication network and the con-

trol system do not operate independently. For example, a protocol for a networked control

system may be designed such that the plant sends position data and video feedback to the

controller. In normal cases, a low bit rate video feed is streamed, but for high dexterity

manipulation tasks, a higher bit rate is required. In this case, the network traffic would be

dependent on the current state of the system and dexterity requirement of the task [6]. If the

network simulation is designed as a separate component, the network’s dependency upon

the control commands and the system behavior may not be accurately represented in the

simulation.

3.3 Network Emulation

Network emulation, which is a way to perform hardware-in-the-loop simulations of tele-

operation systems, involves adding delays and packet losses to actual network traffic ac-

cording to a simulation scenario in real time. The ns-2 simulator can be set to network

emulation mode [66, 67], in which the real-time scheduler is used and different classes


make up the ns-2 protocol stack. Figure 3.4 shows the block diagram of the different com-

ponents of the network emulator, and how they are connected with the master and slave.

There are generally three components that perform operations within the network emula-

tor: packet capture for receiving incoming data, the simulated network, which is used to

calculate the characteristic time delays and packet losses of the communication channel,

and packet forwarding, which forwards the packets to their original destination. In ns-2,

all of the components are implemented in software using a software architecture different

from that used in the normal simulation mode.

Network Emulator

master slave

PacketCapture

PacketCapture

SimulatedNetwork

SimulatedNetwork

PacketForwarding

PacketForwarding

Figure 3.4: Block diagram of the network emulator and the components connecting masterand slave

3.3.1 Software Architecture

In order to run ns-2 under network emulation mode, the simulation scripts need to be ad-

justed so that the network emulation classes are used in place of the classes normally used

in ns-2 simulations. Figure 3.5 shows the software components of the network emulator.

Unlike the normal simulations where separate classes are used to generate application layer

and transport layer data, the ns-2 simulator under emulation mode captures the data from

incoming packets and injects them into the simulation. Once the data from the captured


packets have entered the simulation, they can be appropriately dropped or delayed before

being forwarded out to their intended destination.

Packet ForwardingApplication Layer

Tap AgentTransport Layer

NS-2Network & Link Layer

Packet CaptureApplication Layer

Tap AgentTransport Layer



Slave Program(UDP Connection)

Master Program(UDP Connection)

Figure 3.5: Protocol stack of ns-2 in in emulation mode for data sent from the master tothe slave. Shaded boxes indicate the components that are part of ns-2. The solid lines anddashed lines indicate physical and logical connections in the simulation, respectively.

ns-2 uses the Berkeley Packet Filter (BPF) kernel agent to capture data-link layer frames

[68]. This means that all of the protocol header information and data up to the link layer

is captured. The packet filter is represented by ns-2 network objects, which fill in for the

application layer and transport layer objects while in emulation mode. The captured data

is then injected into the simulation by the attached Tap Agents, which introduce simulation

packets containing the live data as their payload. The live data are the packets containing

commands sent from the master to the slave and the force feedback, video feedback, or

other feedback streams sent from the slave to the master.

Once the packets with live data are introduced into the simulation, they travel through

the network topology, which is defined by the user through ns-2 scripts as normal. The

destination of the live packets is another network object, which will forward an actual data

packet to the destination with the calculated delay. To accomplish this process, ns-2 uses

a real-time scheduler, which will wait for the scheduled time before dispatching events in

the simulation.


Modifications to the Network Emulator

Figure 3.6 shows the class diagram of the ns-2 emulation code used for the simulation

framework. Depicted is the Network class hierarchy, which is associated with each

TapAgent. The Network class provides an interface through which the TapAgent ac-

cesses the network interface of the host computer. The main methods of access are send

and recv, which allow for data within a specified buffer to be sent to and received from

the network, respectively. The IPNetwork class is used specifically for sending pack-

ets through an IP-based network and the PcapNetwork is the class used specifically for

capturing data from the network using a BPF filter.

The main change is the addition of a new ProtocolTapAgent class that inherits

from the existing TapAgent class. The purpose of the modifications is to provide func-

tionality that may be specific to the protocol or the application. The new Tap Agent is used

to process the data within each packet after the packet capture process has been completed.

The Tap Agent has handlers associated with it, which are able to analyze the received

data and process it depending on the protocol or application being simulated. For exam-

ple, a handler can be programmed to adjust the parameters of the simulation based on the

contained packet data or encapsulate the received packet with a different protocol header.

When the data is received by the recvpkt method of the ProtocolTapAgent, the

associated ProtocolHandler instances are invoked through the receive callback

method. Users are able to determine the response of the simulation to received data by

programming different behaviors for the receive callback method.


1

1

1

*

Network

+ send(bu�er, length : int)+ recv(bu�er, length : int)

- send_socket

+ send(bu�er, length : int)

IPNetwork

- bpf_program

+ recv(bu�er, length : int)

PcapNetwork

+ recvpkt()

ProtocolTapAgent

+ sendpkt(packet)+ recvpkt()

TapAgent

+ receive()

ProtocolHandler

Figure 3.6: Class diagram for modifications to the network emulator

3.3.2 Delay Generation

The network emulator generates delays for packets simply by storing the received packets

for a calculated time before forwarding them to the next target. Figure 3.7 shows a timing

diagram for typical communication between the master, slave, and network emulator. In

this scenario, the master and the slave both transmit a packet destined to the network emu-

lator at time t1. Because the three hosts are all connected through a real network, there is a

delay dnet that the packets take to be transmitted over the network to the network emulator.

Once the network emulator has received a packet from the master addressed to it, it will

modify the source and destination addresses so that the packet can be forwarded from the

network emulator to the slave. Similarly for a packet received from the slave, the source


and destination addresses are modified so that the packet is addressed from the network

emulator to the slave. Also, the network emulator will calculate the delays d1 and d2 that

the packets should be delayed by. After the calculated delay time d1 has elapsed, the packet

originally sent from the master will be sent to the slave at time t4. The packet originally

sent from the slave will have a calculated delay of d2 and then it will be sent by the network

emulator to the master at time t2. At time t5, the packet originally sent by the master

reaches the slave with a total delay of dtm. At time t3, the packet originally sent by the

slave will reach the master for a total delay of dts.

t1

t2

t3

t4

t5

dts

dtm d1

d2

dnet

Master NetworkEmulator Slave

Figure 3.7: Emulation timing diagram of the generated delays for typical transmissionbetween the master and slave. The large solid arrows indicate transmission from the slaveto the master and the large dashed arrows indicate transmission from the master to the slave.

From the previous discussion, the only delays that are desirable are the delays d1 and

d2 that are incurred intentionally by the network emulator. The delay associated with send-

ing the packet through the actual network dnet is undesired because it cannot easily be

controlled. However, when the computers are connected through a LAN and there is no

additional traffic over the real network, the delay dnet can be kept to a neglible amount.

There are two methods that can be used for calculating the delay times d1 and d2: by using


a simulation topology or by using random variables.

Defining a Simulation Topology A network topology can be defined through the simu-

lation, and the delay experienced by the transmission of packets through the network can

be calculated. The topology is set up by specifying nodes and the links between them.

Under normal circumstances, the delay experienced by a packet has three contributions:

the propagation delay, the transmission delay, and the queueing delay [19]. All three of

these delays can be changed through the links specified by the user. However, by default

the propagation delay is constant and the transmission delay and queueing delay are not

directly controllable by the user.

Delay based on Random Variables The delay can also be calculated as the value of a

random variable. This is useful when trying to model the communication link as a ran-

dom variable [69, 70] or in cases where the delay should be calculated based on empiri-

cal results. This requires a modification to the ns-2 code. As depicted in Figure 3.8, a

VarLinkDelay class was added, which inherits from the existing LinkDelay and over-

rides the recvmethod. The VarLinkDelay class has an associated RandomVariable,

which is used to generate the random propagation delay.

3.3.3 Packet Loss Generation

Packet losses refer to packets that are dropped by the router due to causes such as conges-

tion or errors detected in the packet. The network emulator is able to emulate the packet

losses by withholding the forwarded packets from the receiver. In an ns-2 simulation, error


1 *

RandomVariable

+ value() : double + recv()

VarLinkDelay

+ recv()

LinkDelay

Figure 3.8: Class diagram of the LinkDelay class hierarchy

modules can be added to links and the emulated packet loss can be specified as a percent-

age in two different ways: randomly selected dropped packets and periodically selected

dropped packets.

Randomly Selected Dropped Packets Using randomly selected dropped packets, a per-

centage of the received packets is dropped, and the specific packets that are dropped are

determined by a random number generator. The network emulator does this using the fol-

lowing steps. First, a random number is chosen from a random number generator with a

uniform distribution, i.e., a number in the range of [0, 1) is chosen. Next, the number is

compared to the threshold percentage of packets that should be received. For example,

if the desired packet loss is 5%, the random number is compared to 0.05. If the random

number is below the threshold, the packet is dropped. Otherwise, the packet is kept.

Periodically Selected Dropped Packets With periodically selected packets, a fixed per-

centage of the packets are dropped. Specifically, the first packets within a constant period


of time are always dropped. For example, if the desired packet loss is 5%, and the period

is 1 second, all packets arriving within the first 200 ms will be dropped. This example

illustrates the impact of the period upon the nature of the packet loss. Setting the period

to a long duration would cause all packets to be dropped for a long period of time and

could affect the stability of the teleoperation system, whereas a short period might cause

the results to be unexpectedly good.

In summary, network emulators provide two different methods for creating packet losses.

The first method is randomly selected packets, where the packet loss is based on a random

number generator. The second method is to use periodic packet loss, where the order of

packets that are dropped is fixed, however, an extra parameter, the period, is introduced.

the main differences between the two methods is that the random method does not require

an extra period parameter, but the actual packet loss percentage may vary from the desired

percentage.

3.3.4 Simulation Methods

As introduced in Section 3.2 regarding network simulation, there are two approaches to

simulating a teleoperation system: co-simulation and sequential simulation. These ap-

proaches also apply to network emulation.

The co-simulation approach means that all the components of the teleoperation system

are running simultaneously. When the network emulator receives a packet, it must calculate

the current time delay and packet loss based on the simulation parameters and forward the

resulting packet onwards. The limitation to this approach is that the computation time for


each packet may be too burdensome for the network emulator in real-time simulation. If

the simulation scenario is too complex and time consuming to calculate, the packets will

be delayed longer than desired.

The sequential simulation approach when applied to network emulation means that the

results of the network simulation have been precomputed offline using fake packet data.

Once the results of the network simulation has been recorded, the resulting time delays and

packet losses are replayed by the network emulator during the actual experiment. In this

way, the computation time required to calculate the results of the network simulation is no

longer an issue. However, as discussed previously, the accuracy of the simulation in some

cases may not be as good as that of co-simulation.

The co-simulation approach should be used when protocol behavior that is specific to

an application is required. For example, the application may adjust its transmission rate

depending on the online task dexterity requirement of the current tasks [6]. When the

slave is performing a dextrous task, the transmission rate for force feedback should be

increased. In this case, the co-simulation approach should be used to accurately model the

system [71]. The sequential simulation approach should be used in cases where it is not

practical to adopt the co-simulation approach. For example, when simulating a large-scale

network with thousands of nodes, if the computation time is a concern as in the case with

real-time experiments, the sequential simulation approach should be adopted so that the

simulation of the network is carried out in a separate offline step.

Wireless Network Emulation The simulation of wireless networks in ns-2 requires that

additional parameters and classes be used in the simulation scripts. The wireless link layer,


routing protocol, and radio propagation model must be configured in ns-2. Due to the

way that the wireless simulations schedule events, they do not work with the real-time

scheduler. Consequently, wireless simulations do not work under emulation mode [72].

To circumvent this problem, the sequential simulation approach can be taken, where the

wireless simulation is ran in a separate offline step and the results are used by the network

emulator during runs of the experiment.

3.4 Summary

This chapter explained the methods used in designing a benchmark testrig for performance

evaluation of a bilateral teleoperation system. The general architecture of the benchmark

testrig was introduced, emphasizing that each of the components are replaceable with dif-

ferent modules. Then two methods of for performing network simulation for bilateral tele-

operation systems are introduced. Using the co-simulation approach, the system dynamics

and the network simulation are ran simultaneously. In the sequential simulation approach,

each simulation is run separately, and the results of the network simulation are used as

inputs into the system dynamics simulation. The final section of the chapter introduces

network emulation, which is used to connect the network simulator to hardware compo-

nents. The software architecture of ns-2 emulation mode was introduced and the methods

for time delay and packet loss generation were explained. In the next chapter, the bench-

mark testrig will be used to test the performance of a teleoperated hydraulic actuator system

under various network conditions.

Chapter 4

Experimental Investigation

This chapter describes the experiments performed to test a 1 DOF hydraulic actuator under

various network conditions. In Section 4.1, the experimental setup is described including

the dynamics of the system, the control schemes used, and the workings of the master,

slave, and network emulator programs. In Section 4.2, the experiments are explained and

the typical results are shown. Section 4.3 ends the chapter with some concluding remarks

on the results of the experiments.

4.1 Experimental Setup

The experimental setup consists of a hydraulic actuator simulator for the slave, a PHAN-

ToM Omni haptic device for the master, and the network emulator ns-2 running in emu-

lation mode to simulate the communication channel. Figure 4.1 shows a diagram of the

experimental setup.

The three computers used in the experimental setup are the master, slave, and network

41

CHAPTER 4. EXPERIMENTAL INVESTIGATION 42

xm

xs

Operator Haptic Device

Master Net. Em. Slave

Actuator Environment

Fh

xm

xm Fm

Fm, xm

F ∗s , x∗s

F ∗m, x∗m

Fs, xs

xs u

xs

Fe

Figure 4.1: Experimental setup

emulator. The master is connected to a haptic device that obtains position/velocity input

from the user and renders the force feedback. The slave computer runs the simulation

program of the hydraulic actuator. The network emulator is used to simulate the various

conditions of the communication channel.

4.1.1 Dynamics of the Hydraulic Actuator

Figure 4.2 shows the schematic of the hydraulic actuator that is simulated in the experi-

ments. It consists of an actuator, a servo valve, and a stiffness dominant environment. The

servo valve works to control the position of the hydraulic actuator by changing the pressure

of the fluid inside the chamber of the actuator. The hydraulic actuator is used to interact

with the environment, which is modelled by a spring. See Appendix A for details of the

simulation model of the dynamics of the hydraulic actuator.


Figure 4.2: Schematic of the hydraulic actuator

State Space Model

An equivalent state space model was formed by defining the state ~x based on the position

of the actuator xs, the velocity of the actuator xs, the pressures P1 and P2 of the actuator

chambers, the valve spool position xsp, and the valve spool velocity xsp:

~x =

[x1 x2 x3 x4 x5 x6

]T(4.1)

=

[xs xs P1 P2 xsp xsp

]T, (4.2)


resulting in the state space model:

x1 = x2

x2 = 1ms{A(x3 − x4)− dx2 − ksx1 − Ff}

x3 = βhAx1+V1

(Q1 − Ax2)

x4 = βhA(L−x1)+V2

(−Q2 + Ax2)

x5 = x6

x6 = −2ζvωvx6 − ω2vx5 + kvω

2vu

. (4.3)

The parameters used in the hydraulic actuator simulation are shown in Table 4.1. The

quantities Q1 and Q2 are flows whose equations are listed in Appendix A. The parameters

were obtained in previous work by An and Sepehri [73] through measurements and the

manufacturer’s specifications.

Table 4.1: Parameters of the hydraulic system

Parameter Symbol ValueSupply Pressure Ps 17.2 MPa (2500 psi)Tank Pressure Pr 0

Mass of Piston and Rod ms 12.3 kgViscous Damping Coefficient d 250 Ns/m

Actuator Stroke L 0.609 mPiston Area A 6.33× 10−4 m2

Volume of Connecting Lines V1, V2 8.87× 10−5 m3

Valve Orifice Area Gradient w 0.0207 m2/mValve Spool Position Gain kv 4.06× 10−5 m/VValve Natural Frequency ωv 175 Hz

Valve Damping Ratio ζv 0.5Fluid Bulk Modulus βh 689 MPa

The state space equations were used for describing the dynamics of the slave actuator.

The fourth order Runge-Kutta method was used as the numerical integration routine to


solve the state space model in the simulation.

4.1.2 Dynamics of the Master Device

The master consists of a haptic device that the human operator interacts with. In these

experiments, the PHANToM Omni haptic device [5] was used. The PHANToM Omni hap-

tic device is a six degree-of-freedom haptic device developed by SensAble Technologies.

Since the hydraulic actuator system being tested has only one degree-of-freedom, the posi-

tion and force of the haptic device is only used in a single direction, xm, as shown in Figure

4.3.

xm

Figure 4.3: Direction of motion used for the master device

The dynamics of this device are modelled as:

mmxm + kdxm + khxm = Fh + Fm + Fb, (4.4)

where xm is the position of the master, Fh is the force applied by the human operator,

and Fm is the force generated by the haptic device in the xm direction. mm represents

the combined inertia of the haptic device and operator’s arm. kd is the coefficient for

the damping caused by the haptic device and operator. Fb is the friction force caused by


backdriving the device and is smaller than 0.26 N for the PHANToM Omni [74]. The

control of the PHANToM Omni haptic device is implemented by the drivers provided by

SensAble Technologies, which are exposed to user programs through the OpenHaptics

Toolkit [75].

4.1.3 Control Schemes

The experiments are designed to test the performance of three different control schemes

under various network conditions. The control schemes are the force reflection (FR) [23],

position error (PE) [25], and hybrid (HB) architectures [26]. These control schemes were

selected because of their relative ease of implementation and their proven use in teleoper-

ation systems with constant delay. The parameters of the controllers were manually tuned

so that they perform well in compatible fashion under free motion with zero delay and zero

packet losses from the network emulator. Due to extra delay from the network and from the

processing delays of the master and slave programs, the actual time delay that packets expe-

rienced was at minimum 100 ms, which was obtained by measuring the delay between the

master and slave positions when they were connected directly through the local network.

Force Reflection (FR) Scheme

Under the force reflection scheme, the force that the human operator experiences is similar

to the force of the slave interacting with the environment. This means that for an interaction

force Fe at the slave site, the master will experience a force F FRm that is proportional to it.

The control signal uFR at the slave site is adjusted so that it is proportional to the error

between the position of the slave and the received position of the master. The FR control


scheme can be categorized as a position-force control architecture (see Section 2.1.3) since

the master is transmitting position and the slave is sending force feedback.

F FRm = HFR

c F ∗e (4.5)

uFR = KFRc (x∗m − xs) (4.6)

HFRc and KFR

C are controller gains. In Equation (4.5), the distinction is made between Fe

and F ∗e , since the environment force has to be transmitted from the slave to the master.

In Equation (4.6), the symbol x∗m is used to indicate that the master position has been

transmitted from the master to the slave. The superscript “*” denotes that the quantity has

been transmitted through the communication channel and has therefore been delayed.

Position Error (PE) Scheme

Using the position error scheme, the force that the human operator experiences is pro-

portional to the error in position between the master and slave. This is an example of

a position-position control architecture, where the master is transmitting position and the

slave is also transmitting position. In this case, although the force that the operator feels

does not reflect the force of the slave interacting with the environment, the force gives the

operator a feeling of the error that occurs between the position of the master and the slave.

A general advantage of using the position error control scheme is that the cost of imple-

menting force sensors on the slave is eliminated [25]. Using the PE control scheme, the


master force F PEm and the control input uPE are given by the following equations:

F PEm = GPE

c (xm − x∗s), (4.7)

uPE = KPEc (x∗m − xs), (4.8)

where GPEc and KPE

c are controller gains and the superscript “*” denotes that the signal

has been delayed by the communication channel.

Hybrid (HB) Scheme

This control scheme is the combination of the force reflection (FR) control scheme and the

position error (PE) control scheme.

FHBm = HHB

c F ∗e +GHBc (xm − x∗s), (4.9)

uHB = KHBc (x∗m − xs), (4.10)

where HHBc , GHB

c , and KHBc are controller gains and the superscript “*” denotes that the

signal has been delayed by the communication channel.

In this case, the force felt by the operator is proportional to the error in position between

the master and the slave and the feedback force from the environment. Since both position

and force are transmitted by the slave, the hybrid control scheme cannot be categorized as

a position-position architecture or a position-force architecture.


4.1.4 Master and Slave Programs

The purpose of the master program is to interact with the human operator through the

PHANToM Omni haptic device and to relay the commands to the slave. It also receives the

feedback force from the slave and renders the force to the human operator. The purpose

of the slave program is to simulate the dynamics of the slave, sending the slave position

and/or force feedback and also receiving the commands from the master. Figure 4.4 shows

the flowcharts for the master and slave programs.

The master and slave programs use UDP socket connections to communicate with each

other. After an initial handshaking procedure where the master and slave send out ready

signals, the slave enters the loop where the position, velocity, and force are continuously

calculated based on the dynamics of the hydraulic actuator being simulated. The program

contains three different control schemes, which are position error (PE), force reflection

(FR), and hybrid (HB), and the control scheme used is selected by the user. The constants

for the controller gains, the actuator parameters, the valve parameters, and the characteris-

tics of the environment are also set within this program at compile time.

Running on the master computer, the master program is reading the position and veloc-

ity and outputting the force through a callback function. Once the new values have been

read, they are saved and the main loop of the master program continues. In the loop, the

position, force, and velocity of the slave is received through a non-blocking call and the

master position, velocity, and force are sent to the slave computer.


Start

Get positionof haptic deviceand render force

Send command to slave

Apply master control law

Receive input from slave

Experimentis complete?

End

Yes

No

(a) Master program

Start

Selectcontrol scheme

Receive master command

Apply control law

Send position,velocity, and force

to master

Experimentis complete?

End

Yes

No

(b) Slave program

Figure 4.4: Flowcharts for the master and slave programs


4.1.5 Communication Link

In the experiment, there is one computer dedicated to running the network emulator, which

models the communication link. The setup showing the connection of the network emula-

tor, master computer, and slave is shown in Figure 4.5. All computers are connected to each

other through an Ethernet hub. In this setup, both the master and the slave are configured to

have all packets sent to the network emulator instead of each other. The network emulator

is able to delay or drop the packets sent to it before forwarding them to the target host.

Network Hub

Master SlaveNetwork Emulator

Figure 4.5: Communication link setup. Arrows show the flow of packets during transmis-sion from the master device to the slave actuator. Packet transmission from the slave tomaster follows the same path but in reverse direction.

A number of time delay and packet loss profiles have been specified for the experiments.

These profiles are a specification of the desired time delays and packet losses generated by

the network emulator at specific times. The delay profile was generated by the network em-

ulator using random variables as explained in Section 3.3.2. The packet loss profiles were

generated using randomly selected dropped packets as explained in Section 3.3.3. Since the

master and slave programs have a different time reference than the network emulator, some

adjustments must be made to make the master, slave, and network emulator start running


at the same time. To accomplish this, an application-specific handler was programmed to

check the packets for the handshaking protocol used by the master and slave. Once the

initial handshake has been detected by the network emulator, the time delay and packet

loss profiles are generated.

Due to timing errors and computational load, the actual delay generated by the network

emulator may differ from the desired delays calculated during the simulation. The error

in the delay time produced by the network emulator is referred to as the slop factor [67].

In order to test the accuracy of the ns-2 scheduler during the experiment, ping packets

were sent between the master computer and network emulator. It was found that the error

in the delays generated by the network emulator were less than 5 ms, however, the real

accuracy of the emulator varies depending on the computational load of the processor while

the experiment is running. Since the extra delays generated erroneously by the network

emulator are small compared to the processing delay of the master and slave programs, it

was deemed satisfactory for the proposed experiments.

Wireless Experiments

A separate set of experiments were performed to simulate a wireless connection being used

for the communication link. In general, a wireless communication channel introduces new

factors into the system that have to be considered [76]:

• The received signal strength must be great enough so that the receiver can detect the

signal over noise.

• Signals can be reflected by objects such that multiple copies of the signal are received


after various delays (this effect is called multipath propagation).

The purpose of these experiments is to determine how the teleoperation system performs

when the master and slave are wirelessly connected, which is used in applications such as

live-line maintenance. The experiments are designed to determine the effect of two fac-

tors on system performance when a wireless communication channel is used: the distance

between the master and slave and the effect of transmission power.

ns-2 provides a few different models for modeling wireless communication. A study

conducted by Ivanov, Herms, and Lukas [72] showed that ns-2 wireless simulation can

accurately reflect the characteristics of a real environment provided that it is a static en-

vironment and that the simple obstruction model holds true. Since some of the future

applications such as live-line maintenance, which is performed in a rural environment, are

likely to fall within these conditions, the simulation results are able to give an indication

about the performance of the system in the field. Some of the inaccuracies that occur be-

tween wireless simulation and the actual experiments is the automatic data rate selection of

wireless cards and the processing delays of the operating system [77]. These inaccuracies

are due to the simplification of the ns-2 wireless model.

In the wireless experiments, the simulation consists of a master node and a slave node

that communicate with each other as they are separated by various distances. The three

different control schemes (FR, PE, and HB) are tested using the wireless communication

channel. The simulation of wireless networks is provided by ns-2 using the IEEE 802.11

standards, which is a set of standards used for wireless local area networks (WLANs) [78].

Different versions of the 802.11 standard include 802.11a, 802.11b, 802.11g, and 802.11n,


but many of the protocol specifications for these versions, such as the number of multi-input

multi-output (MIMO) streams and the modulation method are not considered by the ns-2

simulation. ns-2 focuses on modeling the Medium Access Control (MAC) layer protocol of

the 802.11 standards. Therefore, the wireless simulation in general, applies to all variants

of 802.11 standards.

In an ns-2 wireless simulation, the wireless parameters that need to be specified are the

radio propagation model, the MAC layer protocol, and the ad hoc routing protocol. For

these experiments, we mainly focus on testing what the effects of the radio propagation

model has on the system, since this model can have a dramatic effect on the simulation

results [79].

ns-2 allows different models to be specified for the radio propagation model. Each of

the models may have different accuracies in certain situations. For these experiments, the

ns-2 shadowing model was chosen as the radio propagation model, which is a probabiliistic

model used to model multipath propagation effects of radio waves. The shadowing model

was chosen for its simplicity and ability to model a wide range of environments by adjusting

parameters that control the amount of fading the signals experience. The shadowing model

uses a reference power Pr that is calculated at a distance d0 as follows:

Pr(d0) =PtGtGrλ

2

(4π)2d20l

, (4.11)

where Pt is the transmission power, Gt is the transmitting antenna gain, Gr is the receiving

antenna gain, λ is the wavelength of the radio signal, and l is the system loss constant.

Equation (4.11) is only applicable for distances that are shorter than what is used in practice


and within the far-field of the transmitting antenna [80]. For the experiments, d0 was set to

1 m, which is a value typically used for low-gain antennas for frequencies of 1–2 GHz [80].

The ns-2 shadowing model calculates the received power at a distance d relative to the

reference power Pr(d0). This ratio is expressed in decibels as follows:

[Pr(d)

Pr(d0)

]dB

= −10β logd

d0

+XdB, (4.12)

where β is the path loss exponent, XdB is a log-normal random variable with zero mean

and standard deviation σ. The parameter σ is called the shadowing deviation. Table 4.2

shows the typical values for β and Table 4.3 shows the typical values for σ.

Table 4.2: Typical values for the path loss exponent β

Category Environment Value

OutdoorFree space 2

Shadowed urban area 2.7–5

IndoorLine of sight 1.6–1.8Obstructed 4–6

Table 4.3: Typical values for the shadowing deviation σ

Environment ValueOutdoor 4–12

Office, hard partition 7Office, soft partition 9.6Factory, line-of-sight 3–6Factory, obstructed 6.8

In addition to the physical layer parameters, there are a number of MAC layer pa-

rameters that have an effect on the wireless simulations. Among these are the parame-

ters of the distributed coordination function (DCF), which is the implementation used by

the IEEE 802.11 standards for carrier sense multiple access with collision avoidance (CS-


MA/CA) [81]. Three parameters of interest are the minimum contention window size, max-

imum contention window size, and the number of retries allowed. There is also the option

of setting the 802.11 RTS/CTS handshaking protocol on or off, which is a setting designed

to prevent the hidden node problem in wireless communications. Since the amount of re-

transmissions should be limited in teleoperation applications, the short retry limit, which

is the number of retransmissions allowed for RTS/CTS messages and the long retry limit,

which is the number of retransmissions for data packets, should be set to appropriately low

values.

As discussed in Section 3.3.4, ns-2 wireless simulations do not work under network

emulation mode. For these experiments, the wireless simulations were performed in two

sequential steps. In the first step, the simulation is performed offline and the resulting delays

and packet losses are recorded. As an approximation, the average values of the delay and

packet losses are recorded every 200 ms. In the second step, the recorded delays and packet

losses are played back during the experiment by using the network emulator [71].

4.2 Performance Evaluation Experiments

In this section, the results of the experiments are discussed. Results are evaluated by qual-

itatively analyzing the response of the system to see if the results are acceptable [82, 83].

Also, the position errors for the first set of experiments are quantitatively evaluated to ver-

ify our findings. To ensure that the results are comparable, the operator tried to repeat the

same motions and follow the same trajectory for each test. However, due to the factors of

human performance, deviations from the desired trajectories are unavoidable.


In the first set of experiments, the performance of the force reflection (FR), position

error (PE), and hybrid (HB) control schemes under a range of gradually changing time

delays and packet losses are compared. In the second set of experiments, the performance

of the three control schemes are compared using randomly changing time delay and packet

loss. The final experiments are to test the performance of the hybrid control scheme using

wireless communication. The effect of distance, transmission power, and obstacles in the

environment are investigated.

4.2.1 Test Procedures

As previously shown in Figure 4.1, the hydraulic actuator benchmark testrig was setup, con-

sisting of a master computer controlling a haptic device, a computer running the network

emulation software, and a slave computer running the hydraulic actuator and environment

simulation. Once the master program, the slave program, and the network emulator have

started and the programs have begun to communicate with each other, the human operator

uses the haptic device to attempt to move in a predefined trajectory.

In the experiments, the operator was made to move the haptic device following the

trajectory shown in Figure 4.6. The operator starts within free motion, pulling the actuator

to 0.08 m. At approximately 2 seconds, the operator will push on the actuator, causing it

to come into contact with the spring at 0.1 m, and then push on the spring until 0.13 m has

been reached.

A total of nine different test scenarios, labelled T01–T09, will be analyzed in the pro-

ceeding sections. Each of the nine test scenarios are designed to test one of the network


Free Motion

Time (sec)40

0.1

0.08

0.13 Constrained MotionEnvironment

Posi

tion

(m)

hydraulic actuator

virtual spring

Figure 4.6: The trajectory used in the experiments

variables affecting the simulations. The test scenarios performed are summarized in Table

4.4.

Table 4.4: Summary of the test scenarios

Category Test Summary

Gradual VariationsT01 Baseline testT02 Varying Time DelayT03 Varying Packet Loss

Random VariationsT04 Varying Time DelayT05 Varying Packet Loss

WirelessT06 Baseline testT07 Increased Distance

Wireless with obstructionsT08 Baseline testT09 Increased Transmission Power

Evaluation of System Performance

For all of the tests, the response of the master was compared with the response of the slave.

This was done qualitatively by observing how well the positions and force signals were

tracked at the master and slave sites respectively. The results are also qualitatively analyzed

to determine at what point the position and force tracking are no longer acceptable.


4.2.2 Experiments with Gradually Changing Time Delay and Packet

Loss

For the first set of experiments, the performance of the system was tested under different

combinations of delays and packet losses. Three different test scenarios were investigated,

each using a different profile of the delay and packet loss. The delays and losses used in

the experiments are shown in Figure 4.7. Scenario T01 uses no time delays or packet losses

generated by the network emulator, and acts as a baseline test to compare other results with.

Scenario T02 is a delay profile that is gradually increasing from zero delay to 500 ms delay

at 5 seconds, and then gradually decreasing back to zero in another 5 seconds. In scenario

T03, the packet loss is slowly varied from 0% to 50%, however, some fluctuations occur

because the packet loss has been generated by using random variables.

The purpose of scenarios T02–T03 is to test the system under a wide range of delays

and also to see the the effects on the system when the delay is gradually varying with

time. Although the designed profiles for the delay and loss do not accurately reflect the

network conditions encountered in practice, they were used to see how the response of

system changes while these extreme conditions are gradually changing over time.

Figure 4.8 shows the typical position tracking results for the scenarios T01, T02, and

T03. From the comparison of the baseline scenario T01 and the varying delay scenario

T02, the slave signals are delayed versions of the master signals and the responses are sta-

ble. Through comparison of the responses of the baseline T01 and the varying packet loss

scenario T03, it is noticed that the response of the slave actuator remains stable, however,

some oscillations occur as the packet loss increases. It was also noticed that significant


0

0.25

0.5

Del

ay(s

)

0 2 4 6 8 10Time (s)

(a) Delays for T01

0

0.5

1

Pack

etL

oss

Rat

io

0 2 4 6 8 10Time (s)

(b) Packet Losses for T01

0

0.25

0.5

Del

ay(s

)

0 2 4 6 8 10Time (s)

(c) Delays for T02

0

0.5

1

Pack

etL

oss

Rat

io

0 2 4 6 8 10Time (s)

(d) Packet Losses for T02

0

0.25

0.5

Del

ay(s

)

0 2 4 6 8 10Time (s)

(e) Delays for T03

0

0.5

1

Pack

etL

oss

Rat

io

0 2 4 6 8 10Time (s)

tFR tPE tHB

(f) Packet Losses for T03

Figure 4.7: Delay and packet loss profiles for scenarios T01, T02 and T03.

oscillations begin at different packet loss percentages for the three control schemes. The

times where oscillations occur have been marked as tHB, tFR, and tPE for the hybrid (HB),

force reflection (FR), and position error (PE) control schemes respectively. These times

have also been marked on Figure 4.7f, which shows the corresponding packet loss percent-

age.

Figure 4.9 shows the typical position errors between the master and the slave. The

position error is calculated on the slave side as |x∗m − xs|. In all cases, the position error


0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

(a) T01, HB

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

(b) T02, HB

0 2 4 6 8 10Time (s)

0 2 4 6 8 10Time (s)

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

tHBtHB

(c) T03, HB

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

(d) T01, FR

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

(e) T02, FR

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

tFRtFR

(f) T03, FR

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

(g) T01, PE

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

(h) T02, PE

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 2 4 6 8 10Time (s)

tPEtPE

(i) T03, PE

Figure 4.8: Typical master and slave positions for scenarios T01, T02, and T03 using theHB, FR, and PE control schemes. The horizontal line marks the location of the springenvironment. The dashed line indicates the position of the master device xm; the solid lineindicates the position of the slave xs.


varies due to the trajectory used by the human operator. When the position of the master

device is slowly changing, the slave does not need to adjust the position by a large amount to

track the master, and the position error is small. When the position of the master changes

rapidly, the slave must also change position rapidly to track the master, and the tracking

performance is affected by time delay and packet loss. In the results of scenario T01 with

no time delay or packet loss, the position error does not exceed 3 mm and the position

tracking performance of all three control schemes is very good. The results of scenario

T02 are shown in Figures 4.9a, 4.9c, and 4.9e with the results of scenario T01 included for

comparison. With time-varying delay introduced in scenario T02, it is observed that the

position error increases with time delay and that the maximum position error is about 60

mm for all three control schemes. The results of T03 are shown in Figures 4.9b, 4.9d, and

4.9f. In the results of T03 with varying packet loss, it is observed that the position errors

have increased from the case of T01 and that the position errors do not exceed 30 mm.

To quantitatively compare the three control schemes by their position tracking perfor-

mance, the average peak width for each of the results was calculated, as shown in Table

4.5. The average peak width indicates the duration of time significant position tracking

error occurs. In all test scenarios, the HB control scheme had the smallest peak widths. In

conclusion, the hybrid control scheme (HB) appeared to have better performance in terms

of position tracking than the FR and PE control schemes in the midst of time-varying delay

and packet loss.

The force responses for scenarios T01, T02, and T03 are shown in Figure 4.10. The

results of the tests using the position error (PE) control scheme have been excluded from

the graphs. The reason for this exclusion is that the force felt by the operator under the PE


10

40

70

Posi

tion

Err

or(m

m)

0 2 4 6 8 10Time (s)

(a) T02, HB

10

40

70

Posi

tion

Err

or(m

m)

0 2 4 6 8 10Time (s)

(b) T03, HB

10

40

70

Posi

tion

Err

or(m

m)

0 2 4 6 8 10Time (s)

(c) T02, FR

10

40

70

Posi

tion

Err

or(m

m)

0 2 4 6 8 10Time (s)

(d) T03, FR

10

40

70

Posi

tion

Err

or(m

m)

0 2 4 6 8 10Time (s)

(e) T02, PE

10

40

70

Posi

tion

Err

or(m

m)

0 2 4 6 8 10Time (s)

(f) T03, PE

Figure 4.9: Typical position errors between the master and slave for scenarios T02, andT03 using the HB, FR, and PE control schemes. Position error of scenario T01 is shownby the grey dashed line for comparison.

control scheme only reflects the position error, and does not accurately reflect the environ-

ment interaction force. Therefore, the PE control scheme is not suitable for comparison


Table 4.5: Average peak width for scenarios T01–T03

Test Scenario Control Scheme Avg. Peak Width (s)

T01FR 0.746PE 0.729HB 0.618

T02FR 0.802PE 0.856HB 0.782

T03FR 0.317PE 0.266HB 0.250

purposes [26]. The results in Figure 4.10 indicate that the system is able to reproduce the

contact forces from the environment with high fidelity. There are some small fluctuations

present, however, they appear to be small in magnitude.

Figure 4.11 shows the typical control signals for the scenarios T01, T02 and T03 and the

HB, FR, and PE control schemes. In general, the control signals of all control schemes were

found to be within the regular operating range and not saturated. By comparing the results

of scenario T01 with T02 and the results of T01 with T03, it is observed that the control

signals have larger fluctuations and larger magnitudes in the presence of time-varying delay

and packet loss.


−100

300

700

1100

1500

Forc

e(N

)

0 1.6 3.2 4.8 6.4 8Time (s)

(a) T01, HB

−100

300

700

1100

1500

Forc

e(N

)

0 1.6 3.2 4.8 6.4 8Time (s)

(b) T02, HB

−100

300

700

1100

1500

Forc

e(N

)

0 1.6 3.2 4.8 6.4 8Time (s)

(c) T03, HB

−100

300

700

1100

1500

Forc

e(N

)

0 1.6 3.2 4.8 6.4 8Time (s)

(d) T01, FR

−100

300

700

1100

1500

Forc

e(N

)

0 1.6 3.2 4.8 6.4 8Time (s)

(e) T02, FR

−100

300

700

1100

1500

Forc

e(N

)

0 1.6 3.2 4.8 6.4 8Time (s)

(f) T03, FR

Figure 4.10: Typical forces for scenarios T01, T02, and T03 using the HB and FR controlschemes. The dashed line incidates the force produced by the haptic device; the solid lineindicates the force produced by the hydraulic actuator.


−1

−0.6

−0.2

0.2

0.6

1C

ontr

olSi

gnal

(V)

0 2 4 6 8 10Time (s)

(a) T01, HB

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)0 2 4 6 8 10

Time (s)

(b) T02, HB

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(c) T03, HB

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(d) T01, FR

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(e) T02, FR

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(f) T03, FR

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(g) T01, PE

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(h) T02, PE

−1

−0.6

−0.2

0.2

0.6

1

Con

trol

Sign

al(V

)

0 2 4 6 8 10Time (s)

(i) T03, PE

Figure 4.11: Typical control signals for scenarios T01, T02, and T03.


4.2.3 Experiments with Random Time Delay and Packet Loss

Two additional tests were performed with the HB control scheme, which involved randomly

varying time delays and packet losses. The tests focus on the HB control scheme, which

was found to have the best results based on the results of test scenarios T01–T03. Figure

4.12 shows the delay and packet loss profiles for the two test scenarios T04 and T05. The

two test scenarios are designed such that various amounts of random delay and packet loss

were introduced by the communication channel. In T04, the delay is set to be similar to a

piecewise-constant function, which changes its value every 10 seconds up to 40 seconds.

The packet loss was set to vary around 40%. In T05, the delay fluctuates but remains

around the value of 250 ms. The packet loss is a piecewise-constant function that increases

up to 30 % every 10 seconds.

The purpose of scenarios T04 and T05 is to test the system using network conditions

that have random variations. The randomness added to the delay and loss profiles may

better reflect the nature of real networks. Moreover, a range of values of time delay and

packet loss were tested to see if any of these effects affect the performance of the system.

Figure 4.13 shows the results of T04 and T05 for the HB control scheme. The results

show that the slave position closely follows the master’s position, even in the presence of

random time delays or packet losses. Although the time delays and packet losses have

some random fluctuations, they are within the acceptable ranges as previously tested in

the earlier tests T01–T03. Similar conclusions can be made observing the force responses

shown in Figure 4.14. Therefore, the results show that the controller is stable and with

good position tracking results as expected. These results were consistent with further tests


0

0.35

0.7

Del

ay(s

)

0 8 16 24 32 40Time (s)

(a) Time Delays for T04

0

0.5

1

Pack

etL

oss

Rat

io

0 8 16 24 32 40Time (s)


0

0.35

0.7

Del

ay(s

)

0 8 16 24 32 40Time (s)

(c) Time Delays for T05

0

0.5

1

P ack

etL

oss

Rat

io

0 8 16 24 32 40Time (s)


Figure 4.12: Time delay and packet loss profiles for scenarios T04 and T05

performed using combinations of random delay and packet loss.

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 8 16 24 32 40Time (s)

(a) T04, HB

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 8 16 24 32 40Time (s)

(b) T05, HB

Figure 4.13: Typical master and slave positions for scenarios T04 and T05, using the HBcontrol scheme. The horizontal line marks the location of the spring environment. Thedashed line indicates the position of the master device xm; the solid line indicates theposition of the slave xs.


600

1400

2200

Forc

e(N

)

0 8 16 24 32 40Time (s)

(a) T04, HB

600

1400

2200

Forc

e(N

)

0 8 16 24 32 40Time (s)

(b) T05, HB

Figure 4.14: Typical forces for scenarios T04 and T05 using the HB control scheme. Thedashed line incidates the force produced by the haptic device; the solid line indicates theforce produced by the hydraulic actuator.

4.2.4 Experiments using Wireless Communication without Obstruc-

tions

The wireless experiments were previously discussed in Section 4.1.5. Table 4.6 lists the

values used for the wireless simulation. It should be noted that the transmission power

and the received power threshold are both parameters that can be changed to any values,

as long as they are reasonable values under the limitations of the 802.11 standard and the

physical hardware. Specifically, the 802.11 standards limit the transmission power to 100

mW [84] and the router has a minimum sensitivity of -87 dBm for 802.11b. The parameters

chosen for the experiments conform to the 802.11 b, g, and n standards and are within the

limitations of the Linksys E2500 router, a commercially available wireless router that had

been previously used for field experiments [85]. The parameters β and σ were chosen to

reflect an outdoor environment without obstructions. The transmission power used was

15 dBm and the receiver sensitivity was set to -83 dBm. The received power threshold is


-64.2 dBm, which would allow 90% of the transmitted packets to be received correctly at

a distance of 100 meters. These settings are reasonable for the equipment used in live-line

maintenance, where the practical distance separating the master and slave may range up to

50 meters.

Table 4.6: Wireless simulation parameters

Parameter ValuePath loss Exponent β 2.0

Shadowing deviation σ 4.0Reference distance d0 1 m

Transmitting antenna gain Gt 2.0 dbiReceiving antenna gain Gr 2.0 dbi

Transmission power 15 dBmCarrier sense threshold -83 dBm

Received power threshold -64.2 dBmChannel bandwidth 11 Mbit/s

Contention window size 1–31Short retry limit 2Long retry limit 1

Packet size 50 bitsPacket interval 2 ms

Based on these parameters, the probability that a packet sent will be received when the

nodes are separated by a distance d can be determined. Figure 4.15 shows the theoretical

probability that the packet will be received given the node distance d. The actual packet

losses in the simulation are different from theoretical values because the retransmissions

used by the MAC layer protocol are not taken into account.

As mentioned previous in Section 4.1.5, the MAC layer protocol has a number of pa-

rameters that have an effect on the simulation. In these experiments, the RTS/CTS mech-

anism was enabled and the retry settings were set to small values, which would result in

short delay times that are desirable in teleoperation systems. The short retry limit was set


0.2

0.4

0.6

0.8

1

Prob

abili

ty0 40 80 120 160 200

Distance (m)

Figure 4.15: Probability of packet reception vs. distance between the master and slave,in wireless channel. The parameters were adjusted such that the probability of packetreception at a distance of 100 m is 0.90.

to 2 while the long retry was set to 1.

Two different test scenarios were investigated, T06 and T07. Scenarios T06 and T07

are used to test the performance of the HB control scheme only, since the HB scheme was

found to have the best performance results in the previous scenarios. Scenario T06 used

the wireless simulation with the distance of 100 m separating the master and slave nodes.

Scenario T07 used the wireless simulation with the distance increased to 125 m. Due to the

relatively short distances separating the master and slave in the simulation, the propagation

delay can be thought of as negligible. The main contributions of the delay are therefore the

queueing delay and transmission delay. In this simulation, the delays were found to be less

than 1 ms, since no additional wireless traffic or network traffic was added to the network

scenario and the wireless channel usage remains below the capacity during the entire run

of the simulation. Therefore, the biggest effect of the wireless channel is the effect of the

packet loss. The resulting delay and packet loss from running the wireless simulations are

shown in Figure 4.16.

Figures 4.16a and 4.16c show the time delays for scenarios T06 and T07 respectively.


0

0.2

0.4

0.6

0.8

1

Del

ay(m

s)

0 4 8 12 16 20Time (s)

(a) Delays for T06

0

0.35

0.7

Pack

etL

oss

Rat

io

0 4 8 12 16 20Time (s)


0

0.2

0.4

0.6

0.8

1

Del

ay(m

s)

0 4 8 12 16 20Time (s)

(c) Delays for T07

0

0.35

0.7

Pack

etL

oss

Rat

io

0 4 8 12 16 20Time (s)


Figure 4.16: Time delay and packet loss profiles for scenarios T06 and T07.

As expected, the value of the delay is very small, and will have a negligible effect on

the performance of the system. Figures 4.16b and 4.16d show the packet losses of the

simulation. The packet losses have occured when the received power is below the threshold

required by the wireless receiver and the allowed number of retranmissions for a data packet

or RTS/CTS packet has been exceeded. For the typical results of T06, the average packet

loss is 22% and scenario T07, the average packet loss has increased to 36%. It should

be emphasized that the resulting delays and packet losses are random due to the random

power received in wireless communications. Further runs of the wireless simulation results

in similar delay and loss profiles.

Figure 4.17 shows the position response for T06 and T07. In these tests, since the packet

losses did not exceed 50%, the system remained stable for the duration of the experiment


0.06

0.09

0.12

0.15

Posi

tion

(m)

0 4 8 12 16 20Time (s)

(a) T06, HB

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 4 8 12 16 20Time (s)

(b) T07, HB

Figure 4.17: Typical master and slave positions for scenarios T06 and T07 using the HBcontrol scheme. The horizontal line marks the location of the spring environment. Thedashed line indicates the position of the master device xm; the solid line indicates theposition of the slave xs. Points where noticeable error occurs is marked on the graph ofT07.

and also exhibited acceptable tracking results. It was also observed that the results T06

with d = 100 m show better position tracking performance than the results of T07 with d

= 125 m. The noticeable points of error have been marked on the graph of Figure 4.17b.

From further experiments, the maximum distance that the system maintained acceptable

performance was found to be 135 m.

4.2.5 Experiments using Wireless Communication with Obstructions

In the next set of experiments, the communication channel simulated is wireless communi-

cation in an environment that has obstructions. Obstructions are any objects in the environ-

ment that will cause radio waves to be scattered, and thereby causes multipath propagation

effects, where multiple waves are received by the receiver [76]. For example, man-made

structures such as buildings or metal posts can cause multipath propagation effects. The ex-

periments will test the effects of the system under obstructions using different transmission


powers.

To reflect an environment containing obstructions, the parameter β has been adjusted to

a larger value of 3.5. The effect of this parameter is to decrease the range at which the wire-

less transmission can operate effectively. For the tests with obstructions, the ranges under

investigation have been decreased to 50 m and 55 m. For scenario T08, the transmission

power has been kept at 15 dBm and for scenario T09, the transmission power has been in-

creased to 18 dBm, which could be realized in practical applications by using higher power

antennas. Figure 4.18 shows the probabilities for receiving a packet at different distances.

In the case of low power transmission (15 dBm), the probability of receiving a packet is

90% when the distance between the master and slave is 50 m. Increasing the transmission

power results in a packet receive probability of 97% at a distance of 50 m.

0

0.2

0.4

0.6

0.8

1

Prob

abili

ty

0 30 60 90 120Distance (m)

Low Power (T08)High Power (T09)

Figure 4.18: Probability of packet reception vs. distance between the master and slave, inwireless channel with obstructions.

The resulting time delays and packet losses for scenarios T08 and T09 are shown in

Figure 4.19. For all of the experiments ran under the scenarios of T08 and T09, the delay

was found to be less than 1 ms. Although the delay has slightly improved between the

results of T08 and T09, this small amount of delay does not have significant impact on


the performance of the system. For scenario T08, at a distance of 50 m, the packet loss

randomly varies but stays around the value of 20%. When the distance is increased to 55

m, the packet loss increases accordingly to around 35%.

Figures 4.20a and 4.20c show the position responses of the tests in scenario T08. The

force response plots are also shown in Figure 4.21. Comparing the results between the cases

with distances of 50 m and 55 m, the position tracking error and the force tracking error is

larger for greater distances. Points where the position tracking error between the results of

T08 and T09 has increased are marked on the Figures 4.20a and 4.20c. At distance larger

than 55 m, the errors are further increased and at 60 m, the system no longer has acceptable

tracking properties.

Figures 4.20b and 4.20d show the position responses for the scenario of high trans-

mission power. It is noticed that the response is stable in all cases and the performance

of the system in terms of position tracking and force tracking has improved. From these

results, we can conclude that the master device and slave can be connected through an

802.11 wireless LAN to perform an outdoor teleoperation task with a hydraulic actuator

system. Depending on the conditions of the environment, e.g., the amount of obstructions

that affect the wireless transmission, the setup will be able to operate at distances of 50

m or greater. To improve the performance of the system, the wireless transmission power

can be increased. However, the system performance will always decrease with increasing

distance at the same rate.


0

0.2

0.4

0.6

0.8

1

Del

ay(m

s)

0 4 8 12 16 20Time (s)

(a) Delays T08, 50 m

0

0.1

0.2

0.3

0.4

0.5

Pack

etL

oss

Rat

io

0 4 8 12 16 20Time (s)

(b) Packet Loss T08, 50 m

0

0.2

0.4

0.6

0.8

1

Del

ay(m

s)

0 4 8 12 16 20Time (s)

(c) Delays T08, 55 m

0

0.1

0.2

0.3

0.4

0.5

Pack

etL

oss

Rat

io

0 4 8 12 16 20Time (s)

(d) Packet Losses T08, 55 m

0

0.2

0.4

0.6

0.8

1

Del

ay(m

s)

0 4 8 12 16 20Time (s)

(e) Delays T09, 50 m

0

0.1

0.2

0.3

0.4

0.5

Pack

etL

oss

Rat

io

0 4 8 12 16 20Time (s)

(f) Packet Losses T09, 50 m

0

0.2

0.4

0.6

0.8

1

Del

ay(m

s)

0 4 8 12 16 20Time (s)

(g) Delays T09, 55 m

0

0.1

0.2

0.3

0.4

0.5

P ack

etL

oss

Rat

io

0 4 8 12 16 20Time (s)

(h) Packet Losses T09, 55 m

Figure 4.19: Delay and packet loss profiles for experiments simulating a wireless channelwith obstructions. Scenario T08 uses low transmission power and T09 uses high transmis-sion power.


0.06

0.09

0.12

0.15

Posi

tion

(m)

0 4 8 12 16 20Time (s)

(a) T08, 50 m

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 4 8 12 16 20Time (s)

(b) T09, 50 m

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 4 8 12 16 20Time (s)

(c) T08, 55 m

0.06

0.09

0.12

0.15

Posi

tion

(m)

0 4 8 12 16 20Time (s)

(d) T09, 55 m

Figure 4.20: Typical master and slave positions for scenarios T08 and T09, using the HBcontrol scheme. The horizontal line marks the location of the spring environment. Thedashed line indicates the position of the master device xm; the solid line indicates theposition of the slave xs. Points where there is considerable tracking error in scenario T08have been marked on the graphs.


200

800

1400

F orc

e(N

)

0 4 8 12 16 20Time (s)

(a) T08, 50 m

200

800

1400

F orc

e(N

)0 4 8 12 16 20

Time (s)

(b) T09, 50 m

200

800

1400

F orc

e(N

)

0 4 8 12 16 20Time (s)

(c) T08, 55 m

200

800

1400

Forc

e(N

)

0 4 8 12 16 20Time (s)

(d) T09, 55 m

Figure 4.21: Typical forces for scenarios T08 and T09 using the HB control scheme. Thedashed line incidates the force produced by the haptic device; the solid line indicates theforce produced by the hydraulic actuator.


4.3 Summary

The results of Section 4.2 indicate that the time delays and packet losses of the communi-

cation link have a significant impact on the performance of the hydraulic actuator teleop-

eration system under investigation. The performance of this system was evaluated using

two criteria: the position tracking of the slave actuator and the force tracking of the master

haptic device. As demonstrated by the experiments performed with the benchmark testrig,

increased time delays and packet loss tend to increase the tracking errors. This was tested

using three control schemes: the position error (PE), force reflection (FR), and hybrid (HB)

control schemes. It was also tested using a range of time delays and packet losses, which

were controlled by the network emulator acting as the communication link in the experi-

ment. In all cases, the performance of the system in terms of position tracking and force

tracking accuracy degraded as the time delays and packet losses increased.

In the first three test scenarios, T01, T02, and T03, the time delays and packet losses

were gradually varied through a range of values. Scenario T01 was used as a baseline for

comparison, with zero time delay and packet loss. The scenario T02 caused the delays

to vary between a wide range of values while scenario T03 caused the packet loss to vary

between a range of values. These three test scenarios were performed using the PE, FR, and

HB control schemes. It was found that for all control schemes, the system is stable under

the given conditions but the system’s position tracking and force tracking performance

decreases as the time delay and packet losses are increased. It was also found that the HB

control scheme performed slightly better than the PE and FR control schemes.

In the next set of test scenarios, the time delay and packet loss profiles were designed


to incorporate randomness. In scenario T04, the time delay was set to be a piecewise

constant function with randomness added and in scenario T05, the packet loss was set to be

piecewise constant, also with randomness added. The performance of the system could be

tested with different values of the delay and packet loss and with random variations added.

The results showed once again that the system could maintain stability, but the tracking

errors were increased with larger values of time delay and packet loss.

The third set of experiments T06 and T07 involved simulation of wireless communi-

cation. Experiments were performed simulating a wireless communication channel at two

distances, 100 m and 125 m. The results showed that the position tracking performance

and the force tracking performance were both degraded at larger distances. The fourth set

of experiments, T08 and T09, tested a wireless communication channel with obstructions.

In scenario T08, a low transmission power was used. Due to the obstructions, the param-

eters of the wireless transmission model have changed and the system is unable to operate

effectively at the same distances. It was found that the performance of the system is accept-

able at 50 m and is capable of operating up to about 55 m. By increasing the transmission

power in T09, the performance of the system and the range at which it could operate at was

improved.

As observed in the experiments, time delays caused by the communication link do not

allow the exchange of information between the master and slave to occur in a timely fash-

ion. The presence of time delay causes the hydraulic actuator to have a delayed response

to the commands sent by the master. This delay has the effect of increasing the tracking

errors, and may make it more difficult for the human operator to control the system. For

example, it is possible due to a delayed response that the operator perceives a fictitious


force of the environment when the slave hydraulic actuator is not actually in contact with

the environment. Pure time delays do not appear to cause oscillations in the hydraulic ac-

tuator system, which was also observed in the experiments performed in [26]. Packet loss

appears to decrease the position tracking and force tracking qualities by causing the system

to become more oscillatory. It was found that the packet loss can cause the performance to

degrade, however, the response will not be delayed as in the previous case.

In general, the results of the experiments have shown that the hybrid (HB) controller

gives the best results in the presence of time delay and packet loss. In applications where

only position tracking is desired and force tracking is unnecessary, the position error (PE)

control scheme is also recommended because it is simpler and less costly to implement

than the other control schemes.

Experiments were also carried out using simulation scenarios where the master and

slave were wirelessly connected with/without obstructions in the environment. It was found

that the system had satisfactory results in the environments with and without obstructions.

By increasing the wireless transmission power within the limits of the IEEE 802.11 stan-

dard, the performance of the system could be improved.

Chapter 5

Conclusion

This thesis presented a general framework for evaluating the performance of bilateral tele-

operation systems under various network conditions in a consistent and controllable fash-

ion. The testrig uses ns-2 as a network emulator, which allows for the communication link

of the teleoperation system to be simulated. The simulation approach to modelling the com-

munication link allows for network conditions to be consistent and controlled throughout

multiple tests, since all parameters of the simulation can be specified. ns-2 running under

emulation mode was proposed as a way of simulating the communication link. Network

emulation allows for the network conditions to be controlled and for repeatable results. The

advantages of using ns-2 are the well-documented flexibility that allows for the structure

of the simulator to be modified and for new protocols to be defined when the program is

running in simulation and emulation mode. It also allows for the time delays and packet

losses to be specified in a variety of ways.

The proposed setup was used to test the performance of a hydraulic actuator under

various network conditions. The performance of three control schemes was first evaluated

82

CHAPTER 5. CONCLUSION 83

by using gradually changing time delay and packet loss, with the goal of testing the system

under a wide range of possible time delay and packet loss values. Another set of tests were

used to test the performance of the system under randomly changing delays. The final two

sets of experiments were designed to test the system when wireless communication was

used, and the effects of distance and transmission power were investigated. The results

showed that the system’s position tracking and force tracking performance deteriorated

with increasing time delays and packet losees. The system was also tested using simulating

wireless communication between the master and slave.

5.1 Contributions

The contributions of this work was to propose a way to test teleoperation systems using a

network emulator. Network emulation has been used in previous works, however, it had

not been applied to teleoperation systems as a benchmark design for evaluating the system

performance under complex and time-varying network conditions. Two methods of using

network emulation have been proposed, co-simulation and sequential simulation. The pro-

posed use of ns-2 as a network emulator allows for specific repeatable network conditions

to be specified. Extensive experiments were conducted to test different control schemes of

a hydraulic actuator system with force feedback. This is an extension of the work done

by Maddahi et al. [26], which tested the hydraulic actuator system under constant time

delays. In the second set of experiments, the sequential simulation approach was used to

test the performance of the system when a wireless connection is used. The effect of dis-

tance between the master and slave and the transmission power of the wireless nodes on


the performance of the system was observed.

5.2 Future Work

In the experiments conducted, the slave robot was a simulation of a hydraulic actuator. The

simulation program only reflects an idealized model of the system, and the actual actuator

may behave slightly differently. Thanks to the modular design of the proposed framework,

future work is to modify the experimental setup with a real hydraulic actuator or hydraulic

manipulator acting as the slave. The performance evaluation of a hydraulic manipulator

using wireless communication could be useful in applications to live-line maintenance.

Other future work could be to evaluate the skill level of human operators. Using the

simulation framework, operators are asked to perform a task under various network condi-

tions. The skill level of the operators could be evaluated with performance measurements

such as the task completion time.

The experiments also tested the system under a range of time delays and packet losses,

however, these conditions may not completely reflect the conditions encountered in prac-

tical applications. The future work would be to extend the tests to include more realistic

network topologies and traffic scenarios.

With the software components added to the network emulator as described in Section

3.3.1, new protocols can be tested using the network emulator. Although the current bench-

mark setup uses UDP connections as the interface, the simulation can inject packets of a

new custom protocol into the simulation as packets are received. This allows for differ-

ent protocols to be tested without changing the interface of the benchmark setup. Future


work would be to design and test network protocols that would enhance the performance

of bilateral teleoperation systems in the face of time varying delays and packet losses.

Appendix A

Dynamics of the Hydraulic Actuator

The schematic of the simulated hydraulic actuator is depicted in Figure 4.2. The servo

valve is able to control the flow of fluid based on the control input u. The control input

causes a valve spool displacement xsp. The dynamics between the input voltage and the

valve spool displacement is modelled as a linear second-order system:

xsp + 2ζvωvxsp + ω2vxsp = kvω

2vu. (A.1)

The constant parameters of the second-order model are the valve spoon position gain kv,

the natural frequency ωv, and the damping ratio ζv.

The valve spool displacement xsp causes flows Q1 and Q2 into and out of the actuator.

The model of the actuator is an ideal critical centre servo valve. The equations for the flows

Q1 and Q2 are respectively given by:

Q1 = Kvwxsp

√Ps − Pr

2+ sgn(xsp)

(Ps + Pr

2− P1

), (A.2)

86

APPENDIX A. DYNAMICS OF THE HYDRAULIC ACTUATOR 87

Q2 = Kvwxsp

√Ps − Pr

2+ sgn(xsp)

(P2 −

Ps + Pr2

), (A.3)

where Kv is the valve flow gain, w is the width of the port cut into the valve brushing, Ps

is the supply pressure, Pr is the tank pressure, and P1 and P2 are the hydraulic pressures

in the two actuator chambers. Equations (A.2) and (A.3) use the sign function, which is

defined as:

sgn(x) =

+1, x > 0

0, x = 0

−1, x < 0

. (A.4)

Based on the flows Q1 and Q2, the rate of change of the pressures P1 and P2 are respec-

tively given by:

P1 =βh

Axs + V1

(Q1 − Axs) , (A.5)

P2 =βh

A(L− xs) + V2

(−Q2 + Axs) . (A.6)

A is the annulus area of the piston. V1 and V2 are the volumes of the fluid within the lines

connecting the servovalve and actuator. The constant L is the actuator stroke and βh is the

fluid bulk modulus. xs and xs are the displacement and velocity of the hydraulic actuator

respectively.


The equation of motion for the hydraulic actuator is given by:

APL = msxs + dxs + Fl + Ff , (A.7)

where PL = P1 − P2 is the differential or load pressure, ms is the inertia of the moving

part of the actuator, and xs is the acceleration of the piston. d is a damping coefficient

that describes the combined effects of the viscous friction among the pistol, the cylinder

walls, and the damping of the load. The friction force Ff and the force from the spring

environment Fl will be discussed in the next section.

Environment and Friction Forces

The environment is modelled as a linear spring. There are two cases: one for free motion

and one for constrained motion. When the actuator is not yet in contact with the spring, the

system is in free motion and the contact force is zero. Once the actuator has reached the

spring, the system is in constrained motion and the contact force from the spring appears.

Thus, for a spring located at xspring, the contact force Fl is given by:

Fl =

0, xs < xspring

ksxs xs ≥ xspring

. (A.8)

In our experiments, xspring is 0.1 m.

The force Ff accounts for the dry friction between the piston and cylinder walls. It

is a function of the velocity xs and also depends on a threshold velocity vth. Ff is given


by [86]:

Ff =

513.2 + 1219.1xs, xs > 0.0696

1015.4− 5996.6xs, vth ≤ xs ≤ 0.0696

985.42, 0 ≤ xs < vth, Fu ≥ 985.42

Fu, 0 ≤ xs < vth, Fu < 985.42

Fu, 0 > xs > −vth, Fu > −726.97

−726.97, 0 > xs > −vth, Fu ≤ −726.97

−739.7− 2545.4xs, −0.0805 ≤ xs ≤ −vth

−426.9 + 1339.4xs, xs < −0.0805

, (A.9)

where Fu = A(P1 − P2) − Fl. The threshold velocity vth is a parameter of the friction

model and is normally a small value. vth was set to 0.005 m/s during the simulation. Figure

A.1 shows a plot of the friction force obtained from running the experiment. The friction

force varies linearly with the veloctiy at low speeds. When the magnitude of the velocity

reaches a certain amount, the friction force becomes constant due to the force Fu becoming

greater than 985.42 N for positive velocities or less than -726.97 N for negative velocities.


−900−600−300

0

300

600

900

Fric

tion

Forc

eFf

(N)

−0.1 −0.04 0.02 0.08 0.14Velocity x (m/s)

Figure A.1: Plot of the friction force

References

[1] S. Munir and W. J. Book, “Internet based teleoperation using wave variables with

prediction,” in Proc. 2001 IEEE/ASME International Conference on Advanced Intel-

ligent Mechatronics, vol. 1, 2001, pp. 43–50.

[2] D. Lee and M. W. Spong, “Passive bilateral teleoperation with constant time delay,”

IEEE Transactions on Robotics, vol. 22, no. 2, pp. 269–281, Apr. 2006.

[3] H. Kim and J. H. Ryu, “A study on the effect of haptic to video time-delay on tele-

operation and a comment for improving the performance,” in 2011 11th International

Conference on Control, Automation and Systems (ICCAS), Oct. 2011, pp. 1329–1332.

[4] I. Elhajj, N. Xi, W. K. Fung, Y. H. Liu, W. Li, T. Kaga, and T. Fukuda, “Supermedia in

Internet-based Telerobotic Operations,” Management of Multimedia on the Internet,

pp. 359–372, 2001.

[5] A. J. Silva, O. A. D. Ramirez, V. P. Vega, and J. P. O. Oliver, “PHANToM OMNI

haptic device: Kinematic and manipulability,” in Proc. 2009 Electronics, Robotics

and Automotive Mechanics Conference (CERMA’09). IEEE, 2009, pp. 193–198.

91

REFERENCES 92

[6] W. K. Fung, N. Xi, W. Lo, B. Song, Y. Sun, Y. H. Liu, and I. H. Elhajj, “Task driven

dynamic QoS based bandwidth allocation for real-time teleoperation via the Internet,”

in Proc. 2003 IEEE/RSJ International Conference on Intelligent Robots and Systems

(IROS 2003), vol. 2, Las Vegas, Nevada, Oct. 2003, pp. 1094–1099.

[7] A. Sherman, M. C. Çavusoglu, and F. Tendick, “Comparison of teleoperator control

architectures for palpation task,” in Proc. ASME Symposium on Haptic Interfaces for

Virtual Environments and Teleoperator Systems, 2000.

[8] B. Siciliano and O. Khatib, Eds., Springer Handbook of Robotics. Berlin, Heidel-

berg: Springer, 2008.

[9] T. B. Sheridan, Telerobotics, Automation, and Human Supervisory Control. The

MIT Press, 1992.

[10] P. F. Hokayem and M. W. Spong, “Bilateral teleoperation: An historical survey,” Au-

tomatica, vol. 42, no. 12, pp. 2035–2057, 2006.

[11] A. Goradia, N. Xi, and I. Elhajj, “Internet Based Robots: Applications, Impacts, Chal-

lenges and Future Directions,” in Proc. 2005 IEEE Workshop on Advanced Robotics

and its Social Impacts, 2005, pp. 73–78.

[12] P. Kazanzides, G. Fichtinger, G. D. Hager, A. M. Okamura, L. L. Whitcomb, and

R. H. Taylor, “Surgical and interventional robotics - core concepts, technology, and

design,” IEEE Robotics & Automation Magazine, vol. 15, no. 2, pp. 122–130, Jun.

2008.

REFERENCES 93

[13] M. Ferre, R. Aracil, and M. Sánchez-Urán, “Stereoscopic human interfaces,” IEEE

Robotics & Automation Magazine, vol. 15, no. 4, pp. 50–57, 2008.

[14] L. W. Sun, F. Van Meer, Y. Bailly, and C. K. Yeung, “Design and development of

a da Vinci surgical system simulator,” in Proc. 2007 International Conference on

Mechatronics and Automation (ICMA 2007), Aug. 2007, pp. 1050–1055.

[15] J. Marescaux, J. Leroy, M. Gagner, F. Rubino, D. Mutter, M. Vix, S. E. Butner, and

M. K. Smith, “Transatlantic robot-assisted telesurgery,” Nature, vol. 413, no. 6854,

pp. 379–380, 2001.

[16] K. Zarei-nia, N. Sepehri, T. Olson, and W. Mueller, “Haptic-enabled control of hy-

draulic manipulators applied to power line maintenance: Concept & implementation,”

in Proc. 2010 1st International Conference on Applied Robotics for the Power Indus-

try (CARPI). IEEE, 2010, pp. 1–6.

[17] M. Boyer, “Systems integration in telerobotics: Case study: Maintenance of electric

power lines,” in Proc. 1996 IEEE International Conference on Robotics and Automa-

tion, vol. 2, Apr. 1996, pp. 1042–1047.

[18] Q. C. Zhong, Robust Control of Time-delay Systems. Springer London, 2006.

[19] L. L. Peterson and B. S. Davie, Computer Networks: a Systems Approach. Morgan

Kaufmann Publishers Inc., 2000.

[20] S. Yang, X. Chen, L. Tan, and L. Yang, “Time delay and data loss compensation for

Internet-based process control systems,” Transactions of the Institute of Measurement

and Control, vol. 27, no. 2, pp. 103–118, 2005.

REFERENCES 94

[21] R. Oboe and P. Fiorini, “Issues on Internet-based teleoperation,” 1997.

[22] S. Floyd and V. Paxson, “Difficulties in simulating the Internet,” IEEE/ACM Transac-

tions on Networking, vol. 9, no. 4, pp. 392–403, Aug. 2001.

[23] R. W. Daniel and P. R. McAree, “Fundamental limits of performance for force reflect-

ing teleoperation,” The International Journal of Robotics Research, vol. 17, no. 8, pp.

811–830, 1998.

[24] W. R. Ferrell, “Delayed force feedback,” Human Factors: The Journal of the Human

Factors and Ergonomics Society, vol. 8, no. 5, pp. 449–455, 1966.

[25] I. Polushin, P. X. Liu, C. Lung, and G. D. On, “Position-error based schemes for

bilateral teleoperation with time delay: Theory and experiments,” in Proc. 2006 IEEE

International Conference on Mechatronics and Automation, Jun. 2006, pp. 312–317.

[26] Y. Maddahi, R. Rahman, W. K. Fung, and N. Sepehri, “Effect of network quality

on performance of bilateral teleoperated hydraulic actuators: A comparative study,”

Control and Intelligent Systems, to appear.

[27] P. Arcara and C. Melchiorri, “Control schemes for teleoperation with time delay: A

comparative study,” Robotics and Autonomous Systems, vol. 38, no. 1, pp. 49–64,

2002.

[28] D. A. Lawrence, “Stability and transparency in bilateral teleoperation,” in Proc. 31st

IEEE Conference on Decision and Control, 1992, vol. 3, Tucson, Arizona, Dec. 1992,

pp. 2649–2655.

REFERENCES 95

[29] ——, “Designing teleoperator architectures for transparency,” in Proc. 1992 IEEE

International Conference on Robotics and Automation, vol. 2, May 1992, pp. 1406–

1411.

[30] M. Wulandari and D. S. Kwon, “Stability analysis of scaled force-position control

architecture with sensor noise,” in Proc. 2009 International Conference on Advanced

Robotics (ICAR 2009), Jun. 2009, pp. 1–6.

[31] R. J. Anderson and M. W. Spong, “Bilateral control of teleoperators with time delay,”

IEEE Transactions on Automatic Control, vol. 34, no. 5, pp. 494–501, May 1989.

[32] G. Niemeyer and J. J. E. Slotine, “Stable adaptive teleoperation,” in Proc. 1990 Amer-

ican Control Conference, May 1990, pp. 1186–1191.

[33] G. M. H. Leung, B. A. Francis, and J. Apkarian, “Bilateral controller for teleoperators

with time delay via mu-synthesis,” IEEE Transactions on Robotics and Automation,

vol. 11, no. 1, pp. 105–116, Feb. 1995.

[34] W. S. Kim, B. Hannaford, and A. K. Fejczy, “Force-reflection and shared compli-

ant control in operating telemanipulators with time delay,” IEEE Transactions on

Robotics and Automation, vol. 8, no. 2, pp. 176–185, Apr. 1992.

[35] T. Tarn and N. Xi, Event-Based Planning and Control for Robotic Systems: Theory

and Implementation. Springer-verlag New York, Inc., 1998.

[36] N. Xi and T. Tarn, “Stability analysis of non-time referenced internet-based teler-

obotic systems,” Robotics and Autonomous Systems, vol. 32, no. 2, pp. 173–178,

2000.

REFERENCES 96

[37] D. Tusch, Performance Analysis of Network Architectures. Springer, 2006.

[38] U. Bhat, An Introduction to Queueing Theory: Modeling and Analysis in Application.

Birkhauser Boston, 2008.

[39] T. Kleiberg, B. Fu, F. Kuipers, P. Van Mieghem, S. Avallone, and B. Quoitin, “De-

SiNe: a flow-level QoS simulator of networks,” in Proc. 1st International Conference

on Simulation Tools and Techniques for Communications, Networks and Systems &

Workshops. ICST (Institute for Computer Sciences, Social-Informatics and Telecom-

munications Engineering), 2008, p. 10.

[40] H. Ohsaki, J. Ujiie, and M. Imase, “On scalable modeling of TCP congestion control

mechanism for large-scale IP networks,” in Proc. 2005 Symposium on Applications

and the Internet (SAINT ’05), Jan. 2005, pp. 361–368.

[41] X. Chang, “Network simulations with OPNET,” in Proc. 1999 Winter Simulation Con-

ference, vol. 1. IEEE, 1999, pp. 307–314.

[42] M. Fras, J. Mohorko, and Z. Cucej, “Real time “system-in-the-loop” simulation of

tactical networks,” in 16th International Conference on Software, Telecommunica-

tions and Computer Networks (SoftCOM 2008). IEEE, 2008, pp. 105–108.

[43] G. F. Riley, “The Georgia Tech network simulator,” in Proc. ACM SIGCOMM Work-

shop on Models, Methods and Tools for Reproducible Network Research, ser. MoMe-

Tools ’03. New York, NY, USA: ACM, 2003, pp. 5–12.

[44] R. M. Fujimoto, K. S. Perumalla, and G. F. Riley, Network Simulation. Morgan &

Claypool Publishers, 2007.

REFERENCES 97

[45] T. Issariyakul and E. Hossain, Introduction to Network Simulator NS2. Springer,

2009.

[46] L. Breslau, D. Estrin, K. Fall, S. Floyd, J. Heidemann, A. Helmy, P. Huang, S. Mc-

Canne, K. Varadhan, Y. Xu, and H. Yu, “Advances in network simulation,” Computer,

vol. 33, no. 5, pp. 59–67, May 2000.

[47] S. Kurkowski, T. Camp, and M. Colagrosso, “MANET simulation studies: the incred-

ibles,” SIGMOBILE Mobile Computing and Communications Review, vol. 9, no. 4,

pp. 50–61, Oct. 2005.

[48] J. Flynn, H. Tewari, and D. O’Mahony, “A real-time emulation system for ad hoc

networks,” in Proc. Communication Networks and Distributed Systems Modeling and

Simulation Conference, 2002.

[49] T. R. Henderson, S. Roy, S. Floyd, and G. F. Riley, “ns-3 project goals,” in Proc. 2006

workshop on ns-2: the IP network simulator. ACM, 2006, p. 13.

[50] S. Munir and W. J. Book, “Control techniques and programming issues for time de-

layed Internet based teleoperation,” Journal of Dynamic Systems, Measurement, and

Control, vol. 125, no. 2, pp. 205–214, 2003.

[51] Y. Liu, A. Goradia, Y. Xue, and N. Xi, “Event based methodology for supermedia

enhanced teleoperation,” in Proc. 2006 IEEE International Conference on Robotics

and Biomimetics (ROBIO ’06), Dec. 2006, pp. 67–72.

REFERENCES 98

[52] C. Zhang and K. T. Chong, “Passive bilateral teleoperation via the Internet,” in Proc.

SICE-ICASE International Joint Conference 2006, Bexco, Busan, Korea, Oct. 2006,

pp. 3072–3078.

[53] S. Hirche and M. Buss, “Study of teleoperation using realtime communication net-

work emulation,” in Proc. 2003 IEEE/ASME International Conference on Advanced

Intelligent Mechatronics (AIM 2003), vol. 1, Jul. 2003, pp. 586–591.

[54] M. Díaz-Cacho, A. Fernández, M. Garcia, and A. Barreiro, “Internet emulation sys-

tem for UDP-based teleoperation,” in Proc. 16th Mediterranean Conference on Con-

trol and Automation, Jun. 2008, pp. 1417–1422.

[55] E. J. Rodríguez-Seda, D. Lee, and M. W. Spong, “Experimental comparison study

of control architectures for bilateral teleoperators,” IEEE Transactions on Robotics,

vol. 25, no. 6, pp. 1304–1318, Dec. 2009.

[56] K. Zarei-nia, A. Y. Goharrizi, N. Sepehri, and W. K. Fung, “Experimental evaluation

of bilateral control schemes applied to hydraulic actuators: A comparative study,”

Transactions of the Canadian Society for Mechanical Engineering, vol. 33, no. 3, p.

377, 2009.

[57] M. Esfandiari, K. Zarei-nia, W. K. Fung, and N. Sepehri, “Performance evaluation

of three schemes applied to bilateral control of a hydraulic actuator interacting with

deformable environments,” in Proc. 2010 IEEE International Conference on Robotics

and Biomimetics (ROBIO 2010). IEEE, 2010, pp. 1148–1153.

REFERENCES 99

[58] H. K. Kalitay and M. K. Nambiarz, “Designing WANem: A wide area network emu-

lator tool,” in Proc. 2011 Third International Conference on Communication Systems

and Networks (COMSNETS). IEEE, 2011, pp. 1–4.

[59] T. A. Kern, Ed., Engineering Haptic Devices: A Beginner’s Guide for Engineers.

Springer Berlin Heidelberg, 2009.

[60] C. Petzold, Programming Windows®. Microsoft Press, 2010.

[61] M. S. Branicky, V. Liberatore, and S. M. Phillips, “Networked control system co-

simulation for co-design,” in Proc. 2003 American Control Conference, vol. 4. IEEE,

2003, pp. 3341–3346.

[62] G. F. Franklin, D. J. Powell, and M. L. Workman, Digital Control of Dynamic Systems.

Prentice Hall, 1997.

[63] A. S. Hodel, R. B. Tenison, D. A. Clem, and J. E. Ingram, “The Octave control

systems toolbox: a MATLAB-like CACSD environment,” in Proc. 1996 IEEE In-

ternational Symposium on Computer-Aided Control System Design, Sep. 1996, pp.

386–391.

[64] V. Liberatore, “Network Control Systems,” World Wide Web, December, 2002.

[Online]. Available: http://vorlon.case.edu/~vxl11/NetBots/ncs.pdf

[65] T. Pérennou, E. Conchon, L. Dairaine, and M. Diaz, “Two-stage wireless network

emulation,” in Broadband Satellite Comunication Systems and the Challenges of

Mobility, ser. IFIP International Federation for Information Processing, T. Gayraud,

http://vorlon.case.edu/~vxl11/NetBots/ncs.pdf

REFERENCES 100

M. Mazzella, F. Boavida, E. Monteiro, and J. Orvalho, Eds. Springer Boston, 2005,

vol. 169, pp. 181–190.

[66] D. Mahrenholz and S. Ivanov, “Real-time network emulation with ns-2,” in Proc.

Eighth IEEE International Symposium on Distributed Simulation and Real-Time Ap-

plications 2004 (DS-RT 2004), Oct. 2004, pp. 29–36.

[67] K. Fall, “Network emulation in the Vint/NS simulator,” in Proc. 4th IEEE Symposium

on Computers and Communications. IEEE, 1999, pp. 244–250.

[68] S. McCanne and V. Jacobson, “The BSD Packet Filter: A New Architecture for User-

Level Packet Capture,” in Proc. USENIX Winter 1993 Conference. USENIX Asso-

ciation, Jan. 1993, pp. 2–2.

[69] D. Chen, X. Fu, W. Ding, H. Li, N. Xi, and Y. Wang, “Shifted gamma distribution

and long-range prediction of round trip timedelay for Internet-based teleoperation,”

in Proc. 2008 IEEE International Conference on Robotics and Biomimetics (ROBIO

2008), Feb. 2009, pp. 1261–1266.

[70] S. Kim, J. Y. Lee, and D. K. Sung, “A shifted gamma distribution model for long-

range dependent Internet traffic,” Communications Letters, IEEE, vol. 7, no. 3, pp.

124–126, Mar. 2003.

[71] S. Liao and W. K. Fung, “On network simulation for performance evaluation of real-

time Internet-based teleoperation,” in Proc. 2011 IEEE International Conference on

Robotics and Biomimetics (ROBIO 2011), Dec. 2011, pp. 750–755.

REFERENCES 101

[72] S. Ivanov, A. Herms, and G. Lukas, “Experimental validation of the ns-2 wireless

model using simulation, emulation, and real network,” in Proc. 2007 ITG-GTI Con-

ference on Communication in Distributed Systems, 2007, pp. 1–12.

[73] L. An and N. Sepehri, “Leakage fault detection in hydraulic actuators subject to un-

known external loading,” International Journal of Fluid Power, vol. 9, no. 2, pp.

15–25, 2008.

[74] M. H. Zadeh, D. Wang, and E. Kubica, “Factors affecting the perception-based com-

pression of haptic data,” Advances in Haptics, 2010.

[75] OpenHaptics Toolkit - Programmer’s Guide, 2005.

[76] W. Stallings, Wireless Communications & Networks, 2nd ed. Pearson Prentice Hall,

2005.

[77] D. Kotz, C. Newport, R. S. Gray, J. Liu, Y. Yuan, and C. Elliott, “Experimental evalua-

tion of wireless simulation assumptions,” in Proc. 7th ACM International Symposium

on Modeling, Analysis and Simulation of Wireless and Mobile Systems. ACM, 2004,

pp. 78–82.

[78] D. Vassis, G. Kormentzas, A. Rouskas, and I. Maglogiannis, “The IEEE 802.11g

standard for high data rate WLANs,” IEEE Network, vol. 19, no. 3, pp. 21–26, May–

June 2005.

[79] I. K. Eltahir, “The impact of different radio propagation models for mobile ad hoc net-

works (MANET) in urban area environment,” in Proc. 2nd International Conference

REFERENCES 102

on Wireless Broadband and Ultra Wideband Communications (AusWireless 2007).

IEEE, 2007, pp. 30–30.

[80] T. S. Rappaport, Wireless Communications - Principles and Practice. Prentice Hall,

1996.

[81] K. Xu, M. Gerla, and S. Bae, “How effective is the IEEE 802.11 RTS/CTS handshake

in ad hoc networks,” in Proc. 2002 IEEE Global Telecommunications Conference

(GLOBECOM’02), vol. 1. IEEE, 2002, pp. 72–76.

[82] G. Sankaranarayanan and B. Hannaford, “Experimental comparison of Internet haptic

collaboration with time-delay compensation techniques,” in Proc. IEEE International

Conference on Robotics and Automation, 2008. (ICRA 2008), May 2008, pp. 206–

211.

[83] S. Sirouspour and A. Shahdi, “Model predictive control for transparent teleoperation

under communication time delay,” IEEE Transactions on Robotics, vol. 22, no. 6, pp.

1131–1145, Dec. 2006.

[84] B. Radunovic, D. Gunawardena, P. Key, A. Proutiere, N. Singh, V. Balan, and G. De-

jean, “Rethinking indoor wireless mesh design: Low power, low frequency, full-

duplex,” in Proc. 2010 Fifth IEEE Workshop on Wireless Mesh Networks (WIMESH

2010), Jun. 2010, pp. 1–6.

[85] Linksys E-Series Routers User Guide, Aug. 2012, hardware manual.

[86] L. Márton, S. Fodor, and N. Sepehri, “A practical method for friction identification in

hydraulic actuators,” Mechatronics, vol. 21, no. 1, pp. 350–356, 2011.

Performance Evaluation of Real-time Bilateral ...

Documents

Transcript of Performance Evaluation of Real-time Bilateral ...