YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: Implementation of Radio Communication and Multi-Hop Data Forwarding

ALBERT-LUDWIGS-UNIVERSITYOF FREIBURG

DEPARTMENT OF COMPUTER SCIENCE

Implementation of Radio Communication and Multi-hopData Forwarding in Player/Stage Robot Simulator

Bachelor’s ThesisTo obtain the grade Bachelor of Science presented by

Michael Sebastian Schroder

at

Computer Networks and TelematicsProfessor: Prof. Dr. Christian Schindelhauer

Advisor: M.Eng. Chia Ching Ooi

July 2007

Page 2: Implementation of Radio Communication and Multi-Hop Data Forwarding

Assertion

I hereby avouch that the presented work was written by myself using solely

the resources mentioned. All pieces that I paraphrased or quoted literally have

been labeled accordingly. This Bachelor’s thesis was neither used in total nor in

extraction for any other work.

Freiburg, July 31, 2007

Page 3: Implementation of Radio Communication and Multi-Hop Data Forwarding

Abstract

Over the few past decades the scientific robotic community has been concerned

with the dominating competencies of mechanics, control theory and electronics.

In recent years, and particularly with the extensive availability of wireless commu-

nication devices, more attention has been drawn to communications. Questions

about the efficient and coordinated accomplishments of certain tasks by a team of

autonomous mobile robots are now one exploratory focus.

Likewise, over the years there has been significant progress in the field of robot

simulators. Modern simulators do not only visualise robots in their particular envi-

ronment, but provide sophisticated algorithms for localisation, path-planning and

mapping, among others. One that is widely used is the Player/Stage robot simu-

lator. The objective of this work is to extend this simulator towards a simulation

environment in which mobile robots are enabled to communicate with each other

with respect to their current radio connectivity. A model that simulates a wireless

network device and focuses on the propagation of radio waves is implemented, as

well as a simple data forwarding mechanism, which facilitates client programs.

“You see, wire telegraph is a kind of a very,very long cat. You pull his tail in New Yorkand his head is meowing in Los Angeles. Doyou understand this? And radio operates ex-actly the same way: you send signals here,they receive them there. The only differenceis that there is no cat.”

Albert Einstein

1

1Unsourced citation, attributed to Einstein

Page 4: Implementation of Radio Communication and Multi-Hop Data Forwarding

Zusammenfassung

In den letzten Jahrzehnten wurde die Wissenschaft der Robotik maßgeblich durch

Mechanik, Kontrolltheorie und Elektronik dominiert. In letzter Zeit und vor allem

durch die weitreichende Verfugbarkeit drahtloser Netzwerke, wurde der Kommu-

nikation zwischen mobilen Robotern immer mehr Beachtung geschenkt. Fra-

gen nach der effizienten und koordinierten Bewaltigung bestimmter Aufgaben,

durch ein Team mobiler autonomer Roboter, bilden heute einen Schwerpunkt der

Robotik.

Ebenfalls gab es in den letzten Jahren weitreichende Entwicklungen auf dem Gebiet

der Robot-Simulatoren. Moderne Simulatoren ermoglichen nicht nur die Visual-

isierung der Roboter in ihrer jeweiligen Umgebung sondern stellen weitgehende Al-

gorithmen, wie etwa zur Lokalisierung, Pfadplanung oder Kartographierung bereit.

Ein sehr bekannter und bewahrter Robotsimulator ist das Player/Stage-System.

Ziel dieser Arbeit ist es diese Simulationsumgebung derart zu erweitern, dass mo-

bile autonome Roboter in der Lage sind, unter Berucksichtigung ihrer gegenwartigen

drahtlosen Verbindungsinformationen, zu kommunizieren. Ein Modul wird imple-

mentiert, welches unter besonderer Beachtung der Ausbreitung von Radiowellen

eine drahtlose Netzwerkschnittstelle simuliert. Weiterhin wird ein Plug-in Treiber

fur Player entwickelt, der grundlegende Forwarding-Funktionalitat bietet und das

Schreiben von Robot-Kontroll-Programmen vereinfacht.

Page 5: Implementation of Radio Communication and Multi-Hop Data Forwarding

Acknowledgements

I want to thank M.Eng. Chia Ching Ooi for her supervision, guidance and useful

suggestions that helped a lot in writing this thesis.

Special thanks go to my father who supported me throughout my studies and

always encourages me on my future career plans.

Page 6: Implementation of Radio Communication and Multi-Hop Data Forwarding

List of Figures

1.1 Wireless ad-hoc networking overview . . . . . . . . . . . . . . . . . 2

2.1 Example: Player server on ActivMedia robot . . . . . . . . . . . . 8

2.2 Example configuration file . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Pioneer 2dx robot in Stage simulation . . . . . . . . . . . . . . . . . 10

2.4 Robot configuration in Stage worldfile . . . . . . . . . . . . . . . . . 12

2.5 Player/Stage simulation overview . . . . . . . . . . . . . . . . . . . 13

3.1 Overview of radio device . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Stage worldfile properties for simple radio propagation model . . . . 20

3.4 Stage worldfile properties for free space model . . . . . . . . . . . . 21

3.5 Worldfile properties for ITU indoor model . . . . . . . . . . . . . . 22

3.6 Worldfile properties for Log Distance Path Loss Model . . . . . . . 24

3.7 Worldfile properties for Simple Raytracing model . . . . . . . . . . 25

3.8 Connectivity visualisation by Simple Raytracing model . . . . . . . 26

4.1 Structure of communication plug-in driver . . . . . . . . . . . . . . 28

4.2 Configuration for communication driver . . . . . . . . . . . . . . . . 30

4.3 Robot discovers injured person . . . . . . . . . . . . . . . . . . . . . 31

4.4 Robot forwards ’fallback’ message . . . . . . . . . . . . . . . . . . . 32

4.5 Message received by all nodes . . . . . . . . . . . . . . . . . . . . . 32

Page 7: Implementation of Radio Communication and Multi-Hop Data Forwarding

List of Tables

2.1 Comparison between Stage and Gazebo . . . . . . . . . . . . . . . . 7

2.2 Available device models in Stage . . . . . . . . . . . . . . . . . . . 11

3.1 Link budget to determine connectivity . . . . . . . . . . . . . . . . 16

3.2 Methods by Radio Communication Module . . . . . . . . . . . . . . 18

C.1 Power loss coefficients . . . . . . . . . . . . . . . . . . . . . . . . . 45

C.2 Floor penetration loss factor . . . . . . . . . . . . . . . . . . . . . . 45

Page 8: Implementation of Radio Communication and Multi-Hop Data Forwarding

Contents

1 Introduction 1

1.1 Wireless Networking Background . . . . . . . . . . . . . . . . . . . 2

1.2 Network Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Robot Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.6 Structure of thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 The Player/Stage Robot Simulator 7

2.1 The Robot Server Player . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Devices, Interfaces, Drivers . . . . . . . . . . . . . . . . . . . 9

2.1.2 Configuration files . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Device Simulator Stage . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Device models . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Stage worldfile . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.3 Player and Stage . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Radio Communication Module for Stage 14

3.1 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Radio Propagation . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Radio Communication Module . . . . . . . . . . . . . . . . . 17

3.2.2 Player Interface . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3 Radio Communication in Player . . . . . . . . . . . . . . . . 19

3.3 Implemented Radio Propagation Models . . . . . . . . . . . . . . . 19

Page 9: Implementation of Radio Communication and Multi-Hop Data Forwarding

CONTENTS viii

3.3.1 Simple Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2 Free Space Model . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.3 ITU Indoor Path Loss Model . . . . . . . . . . . . . . . . . 22

3.3.4 Log Distance Path Loss Model . . . . . . . . . . . . . . . . . 23

3.3.5 Simple Raytrace Model . . . . . . . . . . . . . . . . . . . . . 24

4 Radio Communication Plug-in Driver for Player 27

4.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.3 Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Conclusion 34

5.1 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Appendices 39

A Configuration files 39

B Player Client Programs 42

C Coefficients for Radio Propagation models 45

Page 10: Implementation of Radio Communication and Multi-Hop Data Forwarding

1. Introduction

A team of mobile robots approaches carefully, yet in a coordinated manner, the

border of a crater and analyses the near environment. In a rescue scenario, mul-

tiple robots scour through a hazardous area in search of victims. A group of

autonomous UAVs (Unmanned Aerial Vehicle) observes and tracks down a suspi-

cious target in a reconnaissance mission.

In all of the above scenarios, the coordination of robots is of vital importance in

order to accomplish a certain task efficiently. While coordination takes place on a

higher and more abstract level, one essential competency of a group of autonomous

mobile robots is the ability to communicate. A hardwired infrastructure for mobile

robots is conceivably unsuitable. Due to the advancements of radio communica-

tion technology in recent years, researchers often equip their robots with wireless

network devices. It is common that a team of robots forms a so-called ad-hoc

network.

“An ad hoc network is a (possibly mobile) collection of communica-

tions devices (nodes) that wish to communicate, but have no fixed

infrastructure available, and have no pre-determined organization of

available links. Individual nodes are responsible for dynamically dis-

covering which other nodes they can directly communicate with. A key

assumption is that not all nodes can directly communicate with each

other, so nodes are required to relay packets on behalf of other nodes

in order to deliver data across the network”[RR02].

Communication, however, cannot always be guaranteed since robots may move in

unknown and adversarial environments.

Page 11: Implementation of Radio Communication and Multi-Hop Data Forwarding

1. Introduction 2

1.1 Wireless Networking Background

A wireless local area network (WLAN) is a data transmission system between

multiple devices using radio communication. According to the IEEE 802.11 speci-

fication [IEE], first published in 1997, these networks operate in two modes. First,

the ’infrastructure mode’ provides some kind of base station to which other nodes

connect. However, more importantly for inter-robot communication, is the ’ad-hoc

mode’. In contrast to the first, there is no base station available, as a result nodes

are responsible to configure and route data among themselves. With regard to

the OSI Reference Model IEEE 802.11, like the other 802 standards, specifies the

physical as well as the data link layer (i.e. the lower two layers of the OSI Model).

Figure 1.1 depicts an ad-hoc network consisting of four nodes according to IEEE

802.11. The lower four layers of the OSI Model are visualised for node ’A’, focusing

on ad-hoc networking and are further explained in the following section.

Figure 1.1: Wireless ad-hoc networking overview

Page 12: Implementation of Radio Communication and Multi-Hop Data Forwarding

1. Introduction 3

The physical layer provides the means of transmitting bits using radio signals.

According to IEEE 802.11, frequencies around 2.4 GHz or 5 GHz are used. The

standard initially specified two spread-spectrum radio techniques, DSSS (Direct

Sequence Spread Spectrum) and FHSS (Frequency Hopping Spread Spectrum),

which increase resistance to natural interference as well as reliability. Over the

years several amendments [I99a, I99b] and extensions were introduced leading to

higher data rates and wider ranges.

The data link layer consists of two sublayers, Logical Link Control (LLC) and

Media Access Control (MAC). The LLC sublayer distributes received data packets

to their requested protocols running on the third layer, or handles data down to

the MAC layer. While LLC is basically the same as in the other 802 LAN systems,

enabling wired and wireless networks to exchange data easily, the MAC layer is

different, though its purpose (i.e. to keep tabs on the medium) is the same. Since

it is not possible to observe the wireless medium while one is sending data or

detecting a hidden sender, CSMA/CD (Carrier Sense Multiple Access/Collision

Avoidance) [IEE] is deployed in order to minimize simultaneous transmissions.

To route data from node A to node D in the above ad-hoc network, some kind

of routing protocol needs to be employed since node D is far out of A’s radio

range. To accomplish this, various protocols like AODV (Ad-hoc On-demand Dis-

tance Vector Routing) [PBRD03] or DSR (Dynamic Source Routing) have been

proposed. These protocols constitute the network layer. Through segmentation

and error control, the transport layer provides reliable data transmission be-

tween end-users in a network.

As a result, for the purpose of simulating a wireless device, it is important to

keep this layered structure in mind and additionally envision the need of proper

radio propagation models to reproduce reasonable inter-node connectivity.

Page 13: Implementation of Radio Communication and Multi-Hop Data Forwarding

1. Introduction 4

1.2 Network Simulators

With the unprecedented growth of the Internet, as well as the recent growth of

mobile networks, researchers have developed tools to simulate the behavior of such

networks under certain conditions. Most simulators, including the widely used NS-

2 [NS], implement a large number of network types, protocols and traffic models.

Typically these network simulators cover a variety of different layer implementa-

tions and provide valuable insights on how the network functions. For instance,

NS-2 comprises support for mobile networks, providing a variety of routing pro-

tocols based on three different radio wave propagation models, which in turn are

responsible in calculating signal attenuation. With regard to mobile robots, it is

possible to implement certain mobility models which are executed by individual

networked nodes. However, most network simulators lack a sophisticated path-

plan module and provide rather simple mobility behaviours [NS, BTA+99].

1.3 Robot Simulators

Due to the fact that real robots are quite expensive, they are mostly unaffordable

for individuals and even for some institutions. The use of robot simulators instead

poses a promising resource, since the real environment can be modeled in great

detail. Modern robot simulators [Vau06, ML] allow users to write their own robot

control programs and later display the outcome in a simulation run. Significant re-

search was carried out on these simulators leading to extensive software-packages,

often providing sophisticated algorithms for localization, path-planning and map-

ping [KS07]. Aside from the fact that a researcher does not need to own a robot,

simulators have further advantages, including multi-robot scenarios with tens or

hundreds of robots, rapid controller prototyping or working with novel sensor mod-

els that have not yet been developed [GVH03]. Although robot simulators model

detailed environments and provide the means to controll individual robots, they

lack sophisticated radio device simulation.

Page 14: Implementation of Radio Communication and Multi-Hop Data Forwarding

1. Introduction 5

1.4 Motivation

Communication between teammates is also essential in simulation. Needless to say,

this can be achieved much easier in comparison to real life scenarios. Nevertheless,

adequate simulation of network devices, including link connectivity, constitutes an

elementary foundation of a robot simulator in order to obtain simulation results

that are comparable to outcomes in real life [UA04]. The Player/Stage robot

simulator is a popular and commonly used simulator. Its development started at

the USC Robotics Research Lab in 1999 and is now open-source. Besides numerous

features of the Player/Stage system, including various sensor and actuator models

as well as well thought-out algorithms for SLAM (Simultaneous Localization and

Mapping), the current release lacks a sophisticated radio communication module

which enables nodes (i.e. simulated robots) to exchange data taking into account

their current link connectivity.

1.5 Objective

The overall objective of this thesis is to provide an easy-to-use radio communication

module for the Player/Stage robot simulator, including several radio propagation

models, which can be selected by the user to accommodate for prevailing environ-

mental conditions. Aside from a neat visualisation of the current radio device’s

state, the module should seamlessly integrate into the existing Player/Stage sys-

tem, ensuring high re-usability. In addition to the radio communication module,

a plug-in driver for Player is implemented. The aim of this plug-in driver is to

facilitate client programming, hiding the ongoing communication steps inside the

driver, just like in a very simple protocol. This driver is rather than a usable

routing protocol, a proof-of-concept for later routing protocol implementations.

1.6 Structure of thesis

A short introductory is first given to the Player/Stage system, dealing with con-

figuration, messaging and client programming, among others. The robot server

Page 15: Implementation of Radio Communication and Multi-Hop Data Forwarding

1. Introduction 6

Player and the simulator Stage are explained to an extent that makes it easy

to understand the subsequent work. Chapter 3 describes the implementation of

the new radio communication module in detail. Each radio propagation model

is explained and examples for their usage are given. Chapter 4 deals with the

communication plug-in driver and its capabilities as well as its limitations. The

thesis ends with a conclusion and a section on future works.

Page 16: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator

The development for the Player/Stage robot simulator started in 1999 at the USC

Robotics Research Lab to tackle the need for interfacing and simulation for MRS

(Multi-Robot Systems) [GVH03]. Basically, the project consists of three funda-

mental parts. First of all, the network server ’Player’ which typically runs on the

robot itself, listening for commands from its current client programs, which in

turn are connected to the server over some kind of IP network. Furthermore, the

software ’Stage’ serves as a two-dimensional simulator for mobile robots. It acts

as a plug-in to ’Player’ and feigns sensors and actuators to the devices controlled

by the robot server. A user writes its robot control code as a client to the Player

server. According to experience a client can hardly tell the difference between the

real robot devices and their simulated Stage equivalents [Vau06]. The third soft-

ware package is also a simulator called Gazebo. Contrary to Stage, which serves

as a low-fidelity device simulator appropriate for tens or even hundreds of devices,

Gazebo is a three-dimensional multi-robot simulator for outdoor environments.

Gazebo simulates a relatively small number of robots with high fidelity. In the

following section, the combination of Player and Stage is explained in more detail.

“All the world’s a stage,And all the men and women merely players”

William Shakespeare, As You Like It

Stage Gazebodimensionality 2D 3Dfidelity low highpopulation 10s-100s max.10

Table 2.1: Comparison between Stage and Gazebo

Page 17: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator 8

2.1 The Robot Server Player

The robot network server Player can be seen as a hardware abstraction layer

(HAL) for robotic devices [Vau06, CMG05]. As already mentioned above, it typi-

cally runs on the robot itself and hides the actual complexity of the robots hardware

by drawing in an additional layer. This layer specifies generic concepts as inter-

faces, such as position2d, laser or sonar. The underlying driver, which supports

the corresponding interface, is then responsible for interacting with a certain kind

of hardware. In this manner it is possible to interact with entirely different under-

lying devices through a generic interface. For instance, the Hokuyo URG scanning

laser range-finder, as well as the SICK LMS 200 [Vau06], both adhere to the laser

interface, making it easy for robot programmers to develop re-usable robot control

code. Figure 2.1 schematically displays Player running on an ActivMedia robot

using the p2os driver to control its position [Vau06]. If you want to control a

different kind of robot, you would use its corresponding driver.

Figure 2.1: Example: Player server on ActivMedia robot

Page 18: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator 9

2.1.1 Devices, Interfaces, Drivers

Player is often referred to as a device server. A device always consists of an

interface and its corresponding driver. A client communicates with Player by ex-

changing messages over a TCP socket. Following this approach it is possible to

write control code in any language that comprises socket support. Up to now, there

are client libraries in C, C++, Tcl, Python, Java and LISP. Furthermore, there is

no device-locking implemented, enabling multiple clients to connect to the server

to read and write data [GVH03]. Additionally, Player comprises abstract drivers

that do not receive data directly from hardware, but rather from other drivers.

This approach allows programmers to integrate their advanced algorithms very

easily, leading to high re-usability. A popular example is a driver that implements

adaptive Monte Carlo localization (MCL). Other drivers are vfh (vector field his-

togram navigation), wavefront (path planner) or nd (nearness diagram navigation)

[Vau06].

2.1.2 Configuration files

At startup, Player needs to know what kind of devices will come forth in order

to provide access for client programs. This is achieved by means of a simple

configuration file that specifies all desired devices for which drivers need to be

instantiated. Figure 2.2 shows how to map a SICK LMS200 laser device to Player.

Player will instantiate the ’sicklms200’ driver physically connected to the hardware

driver

(

name "sicklms200"

provides ["laser:0"]

port "/dev/ttyS0"

)

Figure 2.2: Example configuration file

device over the serial port ’/dev/ttyS0’. It provides a laser device under the address

’laser:0’. An address is of the form ’key:host:robot:interface:index’. In the above

example no key is declared, host and robot are implicitly defined as ’localhost’ and

Page 19: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator 10

’6665’. The robot field stands for the intended port, while in the above case ’laser’

is the interface. The index is added in case multiple interfaces on the same robot

are needed. A more detailed example can be found in Appendix A.

2.2 Device Simulator Stage

Stage, currently available in Version 2.03, is the two-dimensional device simula-

tor targeted at large population of robots. It was designed to focus and sustain

research on multi-robot systems by providing fairly computationally cheap device

models. Although Stage is usable as a stand-alone simulation library, its ordinary

use is together with Player. Synced with Players’ configuration file, as well as

its own so-called worldfile [2.2.2], it creates a virtual world populated by robots.

Figure 3.3 shows a robot sensing its environment. The left window displays the

robots sensor configuration in the Stage world while in the right window the pro-

gram ’PlayerViewer’ sketches the actual sensor data. It displays Sonar and Laser

data.

Figure 2.3: Pioneer 2dx robot in Stage simulation

Page 20: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator 11

2.2.1 Device models

Stage provides a number of device models, including sonar, laser rangefinder,

fiducial detector and, most importantly, a robot base with odometry. Typically,

models are quite general and need to be adapted in order to reflect the real de-

vices’ properties. Every device model can be accessed through Players’ interfaces

[Vau06][GVH03]. Table 3.2 gives an overview about the currently implemented

devices. There is no radio communication device available in Stage.

Device model Descriptionblobfinder color-blob-finding vision devicebumper binary touch sensorsfiducial fiducial-detecting devicegripper two-fingered gripper devicelaser scanning laser rangefinderposition mobile robot baseptz pan-tilt-zoom camera headranger sonar/ infra-red rangefinderspeech draws a message bubble

Table 2.2: Available device models in Stage

2.2.2 Stage worldfile

Similarly to Player, Stage requires a configuration file named ’worldfile’ that is

mainly responsible for describing devices and the world itself. In this file the

user sets device properties, specifies map-size and resolution, as well as simulation

intervals. It needs to be written in correspondence to the Player configuration

file. Additionally, a few lines are needed in Players’ config-file in order to advise

the program to execute a Stage simulation run. More detailed information can

be found in the Appendix. Figure 2.4 gives an example of a robots’ description.

The Pioneer robot named ’susanna’ is initially situated in the coordinate systems

origin and possesses a laser device, which is further configured. The field of view

(fov) adds up to 180 degrees with a sample size of 180 rays.

Page 21: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator 12

pioneer2dx

(

name "susanna"

pose [0 0 0]

laser(

samples 180

range_min 0.0

range_max 8.0

fov 180.0

)

)

Figure 2.4: Robot configuration in Stage worldfile

2.2.3 Player and Stage

If Player and Stage are executed in conjunction with one another, the robot server

does not need to load hardware-specific drivers since there is no real hardware that

needs to be controlled. Instead, Stage, in the form of a C library called ’libstage’,

is executed as a plug-in. Subsequently, devices are instantiated as required by

Players’ configuration file and configured further in Stages’ worldfile. All devices

are placed in the virtual world and due to the fact that the very same interfaces are

used, they can be controlled through ordinary robot control programs. Therefore,

robot control programs mostly work without modifications on real hardware as

well as in a simulation.

Figure 2.5 displays three simulated devices. A robot control program connects in

the usual way over a TCP socket to the Player server using the very same interfaces.

Instead of drivers, the libstageplugin is used to simulate the virtual world and all

devices. Robot control code, for example motor commands, are executed on the

simulated device and are visualised by Stages’ graphical user interface shown in

Figure 2.3.

Page 22: Implementation of Radio Communication and Multi-Hop Data Forwarding

2. The Player/Stage Robot Simulator 13

Figure 2.5: Player/Stage simulation overview

Page 23: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage

The main objective of this thesis is to provide a radio communication module for

Stage. Due to the dominance of wireless networks according to IEEE 802.11 and

the extensive use of this technology on real robots, the radio communication mod-

ule is designed in the style of WLANs.

One important property of this module should be that it is easily deployable, en-

suring high re-usability. Besides an easy configuration, the module should simulate

a variety of parameters including IP and MAC addresses, ESSID, as well as phys-

ical constraints like transmitter power, receiver sensitivity and signal attenuation.

However, the simulation will be more abstract in contrast to reality and always be

a compromise to keep complexity within a limit. The following section discusses

that in greater detail.

3.1 Preliminaries

Stage is a low-fidelity device simulator and it should be kept that way. Therefore,

the aim is not to simulate a wireless device with great fidelity but rather simulate

important properties. First of all, in contrast to reality, the modeled Stage device

will neither be used to send nor receive data since data exchange between Player

client programs can be achieved through communication between TCP sockets or

through already implemented Player interfaces. The focus lies on simulating the

connectivity of individual nodes while specifying key properties that are important

for higher layers, for instance the routing layer.

For example, an accurate implementation and simulation of DSSS, FHSS or any

other modulation technique, as well as CSMA/CA is out of scope of the presented

work. However, it is of great significance to model the propagation of radio waves

Page 24: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 15

to determine which node is reachable and which is not.

Figure 3.1: Overview of radio device

In style of Figure 1.1, Figure 3.1 depicts a wireless ad-hoc network consisting of

three nodes. The radio device simulates properties that can be used to implement

routing protocols on top of it. As indicated in the figure, node A does not get

a connection to node C due to an obstacle blocking the radio signals. Modeling

adequate radio propagation is one focus of the implementation.

3.1.1 Radio Propagation

Radio Propagation describes the behaviour of radio waves transmitted from one

point to another. The diffusion of all electromagnetic waves in free space is pro-

portional to the inverse square of the distance to the originating source [Rap01].

However, the propagation of all electromagnetic waves is exposed to environmental

influences that can affect their behaviour significantly. For example ionospheric

Page 25: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 16

conditions, determined by the activity of our sun, affect high frequency (HF) radio

wave propagation [Jon]. Materials and the architecture of a building influence the

behaviour of ultra high frequency (UHF) waves, which are mainly used for wireless

LAN. Generally, radio waves at different frequencies behave differently and, due

to the environmental influences, it is difficult to predict their propagation.

Nevertheless, by virtue of the unprecedented growth of wireless applications, a

variety of propagation models have been developed that usually describe the radio

waves behaviour as a function of frequency, distance and other parameters [Rap01].

While these models can be distinguished in indoor and outdoor models, they all

obey the ’link budget’ to determine if a connection is possible or not.

Link budget

The link budget [LB0] is an accounting scheme to sum up all effects that a radio

signal is exposed to, starting from its transmitter until it reaches the receiver.

Basically all factors are considered in their logarithmic scale, beginning with the

transmitters output power over various losses and gains to the receivers sensitivity.

While most parameters, like antenna gain or receiver sensitivity, are given by the

Transmit + transmitter output power TxP (dBm)+ transmitter antenna gain TxG (dBi)- transmitter cable loss TxL (dB)

Propagation - path loss PL (dB)

Reception + receiver antenna gain (dBi)- receiver cable loss RxL (dB)+ receiver sensitivity RX (dBm)

Total +/-

Table 3.1: Link budget to determine connectivity

manufacturer of a particular wireless device, the path loss, i.e. the attenuation of

a radio signal, has to be calculated through a radio propagation model that fits

the environmental conditions. If the link budget given by Table 3.1 is positive,

Page 26: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 17

then a link between transmitter and receiver can be established.

3.2 Implementation

As depicted in Figure 3.2, the implementation of the radio communication module

substantially comprises four parts. First, the model file in Stage is responsible for

the devices’ simulation itself, such as calculating all data including connectivity

to other nodes. This data is propagated through a Player interface to the Player

robot server. A device proxy on the Player side processes incoming data, which is

then accessible through a client proxy in order to read link information in Player

client program.

Figure 3.2: Implementation overview

3.2.1 Radio Communication Module

The radio communication module for Stage should provide the same flexibility

and configuration scheme as other modules, like laser, ranger, bumper or position.

Therefore, it is reasonable to abide by the structure, which is given by these

modules. The radio communication module implemented in C, just like Stage,

must therefore provide the following methods briefly summarised in Table 3.2. The

initialization function init is called when the model is created to set up all required

Page 27: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 18

Method Descriptioninit set default properties, add menu items for renderingload called after init and reads properties from worldfilestartup called when first subscriber subscribesupdate account for change of the virtual worldshutdown called when last subscriber unsubscribes and resets propertiesrender data visualise connectivityrender cfg display communication rangeunrender data clear data visualisationunrender cfg clear config visualisation

Table 3.2: Methods by Radio Communication Module

callbacks and initialize default values for the models properties. It also creates

menu items for the GUI, which can be used to toggle the data visualisation on and

off during a simulation. Right after init the loading function load is called, which

reads the worldfile and sets the specified parameters accordingly. For example, the

simulated IP and MAC addresses, as well as the ESSID, can be specified in the

worldfile and overwrite the default values set by init. User programs subscribe to

the radio device in order to receive data. The startup method can be used to set up

other properties, e.g. the devices power consumption. In contrast, the shutdown

function is invoked when the last subscriber unsubscribes from the radio device. It

cleans up any rendered data from the GUI and resets the power consumption. The

most important method is the update method, which is responsible for reflecting

the current worlds’ state, which is the actual link information for every device.

Methods like render data or render cfg visualise current link information as well

as current configuration settings, i.e. the actual wireless range. The corresponding

unrender -methods take care to clean up all rendered data.

3.2.2 Player Interface

The Player Interface serves as a bridge to Player. All generated data by Stage that

comprise device-related and link-specific data is collected and formatted according

to the data structure used by Player. Subsequently, after this conversion, a message

is created and sent to all interested parties, which includes the Player WiFi driver.

Page 28: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 19

The message itself is formatted according to XDR (eXternal Data Representation)

[Vau06], which is a data description standard. Player conveniently comes with a

library that provides functions to translate message structs to XDR and vice versa.

3.2.3 Radio Communication in Player

As depicted in Figure 3.2, all incoming WiFi data on the Player side is processed

by a WiFi device proxy, written in C. The devices’ data structures are updated

with the newly available data. After this process, all link information is available

to client programs that are connected to the Player server and maintain a WiFi

client proxy object. Since most client programs are written using C++, the im-

plementation contains additional methods written for the C++ client library to

facilitate reading link information. An example of how to use these methods can

be found in Appendix B.

3.3 Implemented Radio Propagation Models

In recent years, a variety of radio propagation models have been developed [Rap01].

Since radio signals of different frequencies are exposed to very different environ-

mental constraints, models are often focused on a certain domain. Outdoor models

try to predict the radio wave propagation in cities, urban or rural areas, or they

forecast depending on vegetation or environmental effects (like rain). Indoor mod-

els focus more on architectural conditions to approximate path loss, i.e. the signals

attenuation inside a building.

Although Stage is, according to the developers, an indoor simulator, [GVH03] it

would be unreasonable to only implement indoor models. The current implemen-

tation of the radio communication module provides five different radio propagation

models, ranging from the very basic ’simple’ model to a ’raytrace’ model, which

takes the surrounding area into consideration. The user has to know which model

fits best to accommodate the robots’ environment. Independent of the used radio

propagation module, the user can define IP and MAC addresses, as well as the

ESSID (Extended Service Set Identifier), which stands for the name of the net-

work. The following subsections describe every model in detail and give examples

Page 29: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 20

of how to use them.

3.3.1 Simple Model

The simple model is, as the name suggests, a very basic model. Apart from address

specification the user solely has to specify the models’ name and the communica-

tion range. The defined value serves as a radius in metres around the device. A

connection to other radio devices within range can be established. Since this is a

binary model only determining if a node is within range, no signal strength values

are calculated. This model can be used if it is not important to accommodate

to the exact environmental settings, or if the user simply does not know how to

determine the parameters of other more complicated models. Figure 3.3 shows

how to set the model properties in a Stage worldfile.

wifi

(

# network properties

ip "192.168.0.1"

essid "test network"

# radio propagation model

model "simple"

range 5

)

Figure 3.3: Stage worldfile properties for simple radio propagation model

3.3.2 Free Space Model

The free space model is basically an outdoor model which describes the signals’

attenuation on a line-of-sight path under idealized conditions, i.e. effects like

reflection or diffraction do not occur. The assumption of an isotropic transmitter

in conjunction with an unobstructed room leads to the following formula, which

is called Friis transmission equation [Sha05] in reference to the Danish researcher

Harald T. Friis.

PathLoss =( λ

4πd

)2

Page 30: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 21

Basically, the transmission power is spread over the surface of an increasing sphere.

Keeping in mind that d is the distance from the transmitter and λ = cf, while f is

the frequency and c denotes the speed of light, the formula can be resolved in the

logarithmic decibel scale as follows:

PathLoss(dB) = −10 ∗ log10

( c

4πdf

)2

= −20 ∗ log10

( 3

4π ∗ 10

)+ 20 ∗ log10(d) + 20 ∗ log10(f)

= +32.44 + 20 ∗ log10(d) + 20 ∗ log10(f) (3.1)

Equation 3.1 is used in the implementation. In order to calculate the path loss,

the distance has to be inserted in kilometres, while the frequency is specified in

MHz. It is obvious that this equation can only be used if the distance is greater

than a certain value d0 in order to get reasonable results. If the receiver is situated

in the far field, i.e. d > d0, the formula is valid. Since the robots themselves take

up some space, the wireless devices will never come too close to each other so that

we don’t have to worry about the near field.

This model can be used in scenarios where the robots act in an unobstructed

area. The user has to specify frequency, radiated transmitter power in mW and,

additionally, the receivers’ sensitivity in dBm. If these properties are not defined

in the worldfile, reasonable default values are inserted. Figure 3.4 shows how to

use the free space model.

wifi

(

# network properties

ip "192.168.0.1"

# radio propagation model

model "friis"

power 30

frequency 2450

sensitivity -80

)

Figure 3.4: Stage worldfile properties for free space model

Page 31: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 22

3.3.3 ITU Indoor Path Loss Model

Radio propagation models can be distinguished into site-specific and site-general.

While site-specific approaches take into account a detailed map of the environment,

e.g. blueprints of buildings or the location of obstacles, site-general models are

empirical mathematical formulas based on statistics. The site-specific indoor path

loss model proposed by the International Telecommunication Union (ITU) [P.101]

is well-known. The model itself applies to frequencies from around 900MHz up to

5GHz, which makes it suitable for the simulation of wireless devices. It models the

path loss depending on frequency, distance and number of floors between sender

and receiver and is expressed in Eqn. 3.2.

PathLoss(dB) = 20 ∗ log10(f) + N ∗ log10(d) + Pf (n)− 28 (3.2)

The empirical distance power loss coefficient N determines how much power the

signal loses with distance. The actual value depends highly on the architectural

settings as well as on the frequency. Higher values indicate higher energy loss.

The floor penetration factor Pf (n) tries to accommodate for floors between sender

and receiver. The number of floors is denoted by n. Example values for N and

Pf (n) can be found in Appendix C. Since the Stage simulator is a two dimensional

simulator, the floor penetration factor is omitted and the user only has to specify

the frequency and the power loss coefficient. As the name already suggests, the

wifi

(

# network properties

ip "192.168.0.1"

# radio propagation model

model "ITU indoor"

power 30

plc 30

)

Figure 3.5: Worldfile properties for ITU indoor model

Page 32: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 23

ITU indoor model is primarily used for indoor scenarios, for example in office

or residential areas. The power loss coefficient needs to be set accordingly. The

default value is 30.

3.3.4 Log Distance Path Loss Model

The Log-distance path loss model is also a site-general indoor propagation model,

which predicts the path loss depending on distance [Rap01]. It tries to accom-

modate for the various obstacles between sender and receiver by introducing a

random variable [ATL06].

PathLoss(dB) = PathLoss(db)d0 + 10 ∗ α ∗ log10(d

d0

) + Xσ (3.3)

First the path loss at a reference distance d0, which is usually situated in a short

or far distance from the transmitter, is evaluated. The implementation uses Friis

transmission equation to calculate the loss in a distance of 1 metre from the trans-

mitter. This point is situated in the far field, so we get a reasonable value. The

path loss exponent α determines how fast the signal attenuates. While α = 2

would model the propagation in free space, higher values indicate a higher signal

loss. Values around 4 indicate an obstructed office building [Far05]. In order to

take signal fluctuations into account, a Gaussian random variable Xσ with zero

mean and variance σ is introduced. Literature [Rap01] reports that σ ∈ [4, 12]

dB. Higher deviation values indicate higher turbulence in the environment. The

probability that a specific loss l is observed is given through:

P(Loss = l) =1√2πσ

∗ exp(− l2

2σ2) (3.4)

The Log distance model is a widely used indoor propagation model that re-

flects environmental changes through the statistical model given by the parameters

(α, σ). In order to employ it in a scenario, the user has to know how to set these

parameters accordingly. As in all site-general propagation models, it highly de-

pends on empirical parameters. Figure 3.6 shows how to set the path loss exponent

(ple) and the standard deviation σ (sigma) in Stages’ worldfile.

Page 33: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 24

wifi

(

model "log distance"

ple 4

sigma 6

)

Figure 3.6: Worldfile properties for Log Distance Path Loss Model

3.3.5 Simple Raytrace Model

The ’Simple Raytrace’ model is a site-specific model trying to accommodate for

the surrounding area of an individual robot. It is called simple ray-tracing because

it is a line-of-sight approach and does not consider effects like reflection, scattering

or diffraction. As shown in Algorithm 1, a ray is sent straight out from one wireless

device to another, only if the other device is reachable according to the ITU indoor

model, which basically serves as a foundation here.

Algorithm 1 Simple raytracing

for each wireless device wi in simulation dofor each wireless device wj and i 6= j do

calculate path loss plij from wi to wj according to ITU indoor modelif signali - plij is still detectable by wj then

calculate distance of ray through wall dwij

new path loss nplij = wallfactor ∗ 100 ∗ dwij + plijif signali - nplij is still detectable by wj then

appendLinkInformation of wj for device wi

end ifend if

end forend for

If a connection is possible the distance in metres the signal has to travel through

obstacles is calculated, multiplied with a constant, and again multiplied with the

wallfactor. This reasonable value is added to the already obtained path loss. If

the signal is still strong enough to be detected from the other wireless device, a

connection is established.

Page 34: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 25

The worldfile configurations are straightforward. The user solely has to specify

the model as well as the wallfactor to determine how difficult it is for the signal

to pass an obstacle. It has to be mentioned that the results differ depending on

how a map, (i.e. a bitmap) looks like, and if the space between surfaces of walls

is filled. If it is filled, then the whole distance is measured; if it is not, then only

the surfaces of the walls, which are usually only a few pixels wide, are regarded as

obstacles.

wifi

(

# network properties

ip "192.168.0.1"

mac "08-00-20-ae-fd-7e"

essid "test network"

# radio propagation model

model "raytrace"

wall_factor 10

range_db -50

)

Figure 3.7: Worldfile properties for Simple Raytracing model

Visualisation

The user is not only interested in seeing if a link between two robots is established,

but also wants a nice visualisation of how the signal behaves in the near environ-

ment. The implementation employs the concept of contour lines. The user can set

a property called ’range db’ in the WiFi devices’ entry in the worldfile. While the

other models described above render a circle around the transmitting robot, the

’Simple Raytrace’ model will try to find a good approximation of the levels’ con-

tour. To limit computational costs, rays are sent out in steps of 5 degrees around

the robot, altogether 72. The distance each ray can travel until the given dB range

is reached is approximated. Subsequently, a green colored polygon is created and

rendered from the GUI. Since the ITU indoor model is used in the presented sim-

ple raytracing model, it is not surprising that if the wallfactor approaches zero

Page 35: Implementation of Radio Communication and Multi-Hop Data Forwarding

3. Radio Communication Module for Stage 26

the model converges to the ITU model. In this case, the connectivity area set by

’range db’ will simply be a circle as well. Figure 3.8 depicts two robots situated

in the same environment with two different configurations. The left picture shows

a robot whose wallfactor is set to a high value of 100. In this case, the signals

are unable to propagate through walls. A connection, indicated through the blue

arrows between robots, is only possible if the robots are in direct line-of-sight.

The right picture, in which the wallfactor is around 6, shows that the signal can

partially pass through walls. Yet, the ’range db’ is set to -40 dB in contrast to the

left picture where this value is -50 dB, resulting in shorter rays.

Figure 3.8: Connectivity visualisation by Simple Raytracing model

Page 36: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver

for Player

The Player/Stage system was developed to facilitate research in Multi-Robot Sys-

tems. Thus, it is not surprising that communication between Robots in a Stage

simulation can be achieved easily. For instance, a client program controlling de-

vices of robot A could subscribe to various devices of robot B. Since no blocking

mechanisms are implemented and the data transfer is handled over TCP sockets,

robot A could easily read sensor information from robot B [GVH03]. Likewise

robot A could subscribe to robot B’s position device and set motor commands.

Consequently, in an extreme case only one client program could control an armada

of robots, i.e. devices. In this manner, multi-robot sensing, as well as multi-robot

coordination becomes more facile.

However, as communication cannot always be guaranteed due to environmental or

devices constraints, like adversarial settings or low transmitter power, it is reason-

able to design a communication system that considers these effects. The proposed

radio communication module for Stage is well suited to be used in this case. The

objective is to develop a rather simple communication plug-in driver for Player

that enables nodes to communicate if a link between their wireless devices is es-

tablished. Far away from any sophisticated routing protocol, the driver should

provide simple broadcasting functionality, i.e. forward incoming data to other

currently reachable nodes and thus allow multi-hop data forwarding. The follow-

ing section describes the implementation, while all necessary configuration steps,

as well as a scenario will be presented later.

Page 37: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver for Player 28

4.1 Implementation

As already mentioned earlier, a device in Player always consists of an interface

bound to a certain driver. All messages from client programs adhere to interfaces,

and are processed by the driver in use. Player facilitates the development of new

drivers through the concept of so called plug-in drivers [CMG05]. A plug-in driver

is built as a shared object and can be developed independently from Player. There

is no need to recompile Player if the plug-in driver is modified. The communica-

tion driver itself is written in C++ and inherits from Players basic Driver class.

Rather than describing every method in great detail, the structure and its compo-

nents are explained through the use of a simple scenario, where robot A wants to

send a message to robot B.

Basically, the plug-in driver consists of three fundamental parts. The Opaque

interface is a generic interface to send user defined messages. It is used twice, first

to deal with messages from and for the client program and secondly to forward

messages to other nodes. The wireless device constitutes the third part. If robot

Figure 4.1: Structure of communication plug-in driver

Page 38: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver for Player 29

A wants to send a message to robot B then the message from the client program

is first sent to the internal Opaque interface. This interface processes the message

and handles it down to the internal Opaque interface, which is responsible for inter

node communication. The internal messaging interface forwards the message only

to nodes which are currently reachable, i.e. whose link information are provided

by the wireless device. The message arrives at the internal Opaque interface of

robot B, is delivered to the external Opaque device, which in turn sends it to

the running robot control program. If other nodes are within range, the internal

Opaque interface will forward the message again.

The reader might wonder why an internal messaging interface is used and why the

external one does not exchange messages directly. This objection is justified. The

main reason is that inter-hop communication can be hidden internally. If in future

applications a message has to be forwarded without notifying the client program

running on top, i.e. the message is destined for a different node, this two-layer

approach forwards the message without informing the robots client program.

4.2 Configuration

While Stages worldfile stays untouched, the configuration file for Player is slightly

more involved. This is the case because the developed communication driver re-

quires an existing Opaque interface as well as a wireless device to compute link

information. Figure 4.2 shows how a setup for the communication driver might

look like. First, the user has to specify the internal Opaque interface. A robot gets

instantiated carrying a wireless device. The ’alwayson’ option is defined as true to

load the drivers upfront, in order that the user does not have to deal with nasty

startup delays when a client program connects. Afterwards, the communication

driver is specified, loading its very own plug-in. It requires a WiFi and Opaque

device, as well as a mapping of simulated IP addresses to port numbers. The robot

possesses link information that only contains individual simulated IP addresses.

However, since messages are delivered over TCP sockets, the driver needs to know

which port belongs to the robot with a certain simulated IP. Therefore a mapping

has to be inserted. The user should make sure that the specified IPs match the

IPs of the wireless devices, which are specified in the worldfile. Figure 4.2 indi-

Page 39: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver for Player 30

cates that another robot exists in the simulation whose internal Opaque device is

accessible on port 6666. The driver provides the external Opaque device which

talks to the client program on port 6665 at index 1.

driver(name "relay"provides ["6665:opaque:0"]alwayson 1

)

driver(name "stage"provides ["6665:wifi:0"]model "robot1"alwayson 1

)

driver(name "comdriver"plugin "libcomdriver"provides ["6665:opaque:1"]requires ["6665:wifi:0" "6665:opaque:0"]alwayson 1mapping [ "192.168.0.1" 6665

"192.168.0.2" 6666 ])

Figure 4.2: Configuration for communication driver

4.3 Example Scenario

To motivate the communication driver, as well as to show its capabilities, imagine

a rescue scenario where five robots search through a building which is about to

collapse in order to find the last remaining casualty. After robot ’A’ discovered the

individual, it broadcasts a ’fallback’ message to all others. These robots in turn

forward the message to all other robots in range, which should react and leave the

building immediately.

Page 40: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver for Player 31

Figure 4.3 depicts the initial situation. Five teammates search the area when

the lower robot in the middle is about to discover the injured person. Robots

are evenly distributed over the area and currently maintaining radio connectivity

so that it should be possible for a broadcast message to reach every node. The

green area around a robot denotes good radio connectivity. Since robots move in

Figure 4.3: Robot discovers injured person

a collapsing building, it is reasonable to model an adversarial environment. The

communication is hardly sustainable through walls, leading to a very high wall

factor for the chosen ’simple raytrace’ model. A link can be established through

very thin walls and in a line-of-sight path, leading to the depicted network where

the lower robot will broadcast the ’fallback’ message, in intervals of 3 seconds.

Figure 4.4 in turn shows that the message was sent and already received from the

robot in the main hallway, as indicated through the ’F’ next to the robot. The

receiving robot is now in charge to forward the message to warn the others. As

shown in Figure 4.5, the message even reached the robot in the lower left room.

However, in order that the message is not re-broadcasted again and again leading

to extensive flooding, the user must specify a time-to-live (TTL), which is the first

symbol of a message. Every hop decreases it and only forwards the message if

the TTL is greater than zero. Although the mobility was not modeled accurately

in this scenario, it can be seen that the robots forward messages as desired, i.e.

according to their actual link information.

Page 41: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver for Player 32

Figure 4.4: Robot forwards ’fallback’ message

Figure 4.5: Message received by all nodes

4.4 Capabilities

The presented communication plug-in driver is rather a proof-of-concept than a so-

phisticated routing driver. It enables nodes to send, receive and forward messages

according to a time-to-live value (TTL), specified by the user. It uses a two-layer

approach to hide internal communication steps, i.e. forwarding messages, from

client programs running on top. Nevertheless it has the ability to broadcast mes-

sages and can be deployed in scenarios where this is sufficient. The one described

above serves as an example.

The use of Opaque interface in order to talk to the plug-in driver is rather clever

since client support for it is available in many different languages. No client li-

Page 42: Implementation of Radio Communication and Multi-Hop Data Forwarding

4. Radio Communication Plug-in Driver for Player 33

braries have to be adapted and the plug-in driver is usable in client programs

written in Python or Java. However, if this approach evolves, it is more appro-

priate to specify a driver specific interface that provides required features. An

example of how to write a client program is depicted in Appendix B.

Page 43: Implementation of Radio Communication and Multi-Hop Data Forwarding

5. Conclusion

This thesis presented the implementation of the radio communication module for

Player/Stage robot simulator. Following the existing implementations’ structure

of other models, like laser, ranger or gripper, it enables the user to easily equip

their virtual robots with radio communication devices. The model simulates IP

and MAC addresses together with ESSID, and allows users to choose between five

different radio propagation models. Aside from site-general, with ’Simple Ray-

trace’, a side-specific model can be found. By means of this radio communication

module, the user can reproduce a variety of different environmental settings. A

patch to include the radio communication module in Player/Stage is available from

the projects’ website.

Furthermore, a plug-in driver for Player is presented that enables client programs

to send, receive and forward messages with respect to the nodes’ current link

connectivity. Employing a two-layer approach, the forwarding of messages can

be hidden internally in the driver and lead to very simple client programs. A

broadcasting scenario, where robots search in a collapsing building for a casualty,

demonstrates its use. This driver, though helpful in some scenarios, rather shows

what kind of structure a future implementation might use.

5.1 Future Works

The current implementation of the radio communication model provides a reason-

able level of abstraction, which in turn leads to relatively low computational costs.

In this manner, Stage remains what its developers intended it to be, a powerful

low-fidelity device simulator for large populations of virtual robots. However, radio

Page 44: Implementation of Radio Communication and Multi-Hop Data Forwarding

5. Conclusion 35

propagation can be tricky and the implemented models might not fit in all cases;

especially if the user needs an extremely accurate map of how radio is propagated.

In this case, a more powerful raytrace model has to be implemented, that deals

with reflection, diffraction and scattering. The computational costs would increase

significantly and, since it is not possible to specify reflection values for different

materials in the current Stage implementation, more work has to be done on the

simulator. In general, if a newly presented radio propagation model appears to

be useful, the implementation is straightforward, since the radio communication

module is inherently designed to support a variety of different models.

For some users, it might also be useful to simulate certain values with greater

detail. Although the current implementation propagates values for link quality,

noise and encryption settings to client programs, these values are not set.

An interesting future application might be to see if the modeled radio device works

in localisation scenarios. For example, if a group of autonomous networked robots

is able to localise themselves in a SLAM scenario based on wireless connectivity.

The plug-in driver for Player is developed to be a proof-of-concept driver to enable

simple multi-hop communication. To sustain powerful communication capabilities,

the use of sophisticated routing algorithms like AODV or DSR is inevitable. Fu-

ture applications might include evaluations of coordinated behavior under varying

constraints, for instance different routing algorithms, radio propagation models,

environments and mobility capabilities. However, it is essential that the user keeps

in mind that simulations are always abstractions from real life and only give in-

sights on how systems might behave under real world conditions. For example,

the radio propagation model used in simulation has great impact on how efficient

a routing protocol appears to be [SW06].

Furthermore, a promising future application is the implementation of a radio com-

munication module for the three-dimensional outdoor robot simulator Gazebo.

Since Gazebo comprises high-fidelity models, it makes sense to implement highly

accurate raytracing algorithms in this environment. As Gazebo is also executed

in conjunction with Player, a routing driver for Player will work with Gazebo as

well as with Stage and lead to a yet even more powerful software package for the

robotic research community.

Page 45: Implementation of Radio Communication and Multi-Hop Data Forwarding

Bibliography

[ATL06] Robert Akl, Dinesh Tummala, and Xinrong Li. Indoor Propagation

Modeling at 2.4 GHz for IEEE 802.11 Networks, 2006. The Sixth

IASTED International Multi-Conference on Wireless and Optical Com-

munications.

[BTA+99] Lokesh Bajaj, Mineo Takai, Rajat Ahuja, Rajive Bagrodia, and Mario

Gerla. Glomosim: A scalable network simulation environment, 1999.

Technical Report.

[CMG05] Toby H.J. Collett, Bruce A. MacDonald, and Brian P. Gerkey. Player

2.0: Toward a practical robot programming framework. In Proc. of

the Australasian Conf. on Robotics and Automation (ACRA), Sydney,

Australia, December 2005.

[Far05] Daniel B. Faria. Modeling Signal Attenuation in IEEE 802.11 Wire-

less Lans- Vol.1, 2005. Technical report TR-KP06-0118, Kiwi Project,

Stanford University.

[GVH03] Brian P. Gerkey, Richard T. Vaughan, and Andrew Howard. The

Player/Stage project: Tools for Multi-Robot and Distributed Sensor

Systems. In Proceedings of the International Conference on Advanced

Robotics (ICAR 2003), pages 317–323, 2003.

[I99a] IEEE Standard 802, Part 11: Amendment 1: High-speed Physical Layer

in the 5 GHz Band.

[I99b] IEEE Standard 802, Part 11: Supplement: Higher-speed Physical Layer

Extension in the 2.4 GHz Band.

Page 46: Implementation of Radio Communication and Multi-Hop Data Forwarding

BIBLIOGRAPHY 37

[IEE] IEEE Standard 802, Part 11: Wireless Lan Medium Access Control

(MAC) and Physical Layer (PHY) specifications.

[Jon] Edwin C. Jones. The Basics of Radio Wave Propagation. http://

ecjones.org/propag.html.

[KS07] James Kramer and Matthias Scheutz. Development environments for

autonomous mobile robots: A survey. Auton. Robots, 22(2):101–132,

2007.

[LB0] Radio theory and link planning for Wireless LAN (WLAN). http:

//www.swisswireless.org/wlan calc en.html.

[ML] MissionLab User Manual. Technical report, College of Computing,

Georgia Institute of Technology, Atlanta.

[NS] The Network Simulator NS-2. http://www.isi.edu/nsnam/ns/.

[P.101] Recommendation ITU-R P.1238-2. Propagation data and prediction

methods for the planning of indoor radiocommunication systems and

radio local area networks in the frequency range 900 MHz to 100 GHz.

ITU Recommendations, 2001. Geneva.

[PBRD03] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance

Vector (AODV) Routing, 2003.

[Rap01] Theodore Rappaport. Wireless Communications: Principles and Prac-

tice. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001.

[RR02] R. Ramanathan and J. Redi. A Brief Overview of Ad hoc Networks:

Challenges and Directions. IEEE Communications Magazine, pages

20–22, May 2002.

[Sha05] Joseph A. Shaw. Radiometry and the Friis Transmission Equation,

2005.

[SW06] Arne Schmitz and Martin Wenig. The effect of the radio wave propaga-

tion model in mobile ad hoc networks. In MSWiM ’06: Proceedings of

Page 47: Implementation of Radio Communication and Multi-Hop Data Forwarding

BIBLIOGRAPHY 38

the 9th ACM international symposium on Modeling analysis and sim-

ulation of wireless and mobile systems, pages 61–67, New York, NY,

USA, 2006. ACM Press.

[UA04] Patrick Ulam and Ronald C. Arkin. When good comms go bad: Com-

munications recovery for multi-robot teams. In Proceedings of the In-

ternational Conference on Robotics and Automation (ICRA 2004), vol-

ume 4, pages 3727–3734, 2004.

[Vau06] Richard Vaughan. The Player Project. Website, 2006. Available online

at http://playerstage.sourceforge.net/; visited July 13th 2007.

Page 48: Implementation of Radio Communication and Multi-Hop Data Forwarding

A. Configuration files

Player configuration file example

More complex example for ’Player’ configuration file, instantiating a robot in a

Stage simulation. The robot uses the adaptive Monte Carlo localization algorithm

together with a vector field histogram as a local obstacle avoidance algorithm. A

wavefront path planner sits on top.

# load a stage simulation

driver

(

name "stage"

provides ["simulation:0" ]

plugin "libstageplugin"

worldfile "slalom.world"

)

# load the ’cave’ map

driver

(

name "stage"

provides ["map:0"]

model "cave"

)

# instantiate a robot

driver

(

name "stage"

Page 49: Implementation of Radio Communication and Multi-Hop Data Forwarding

A. Configuration files 40

provides ["position2d:0" "laser:0" ]

model "robot1"

)

# adaptive Monte Carlo localization

driver

(

name "amcl"

provides ["localize:0" "position2d:2"]

requires ["odometry:::position2d:1" "laser:0" "laser:::map:0"]

init_pose [-5 -5 90 ]

alwayson 1

)

# vector field histogram navigation to avoid obstacles

driver

(

name "vfh"

provides ["position2d:1"]

requires ["position2d:0" "laser:0"]

safety_dist 0.1

distance_epsilon 0.3

max_speed 0.6

max_turnrate_0ms 90

angle_epsilon 5

alwayson 1

)

# wavefront planner for ’global’ path planning

driver

(

name "wavefront"

provides ["planner:0"]

requires ["output:::position2d:1" "input:::position2d:2" "map:0"]

safety_dist 0.15

distance_epsilon 0.5

angle_epsilon 10

alwayson 1

)

Page 50: Implementation of Radio Communication and Multi-Hop Data Forwarding

A. Configuration files 41

Stage worldfile example

Stage worldfile, setting properties and instantiating a Pioneer2dx robot.

# includes for pioneer and map

include "pioneer.inc"

include "map.inc"

# configure simulation size, resolution and intervals

size [16 16]

resolution 0.02

gui_interval 50

interval_sim 100

interval_real 50

# set window properties

window

(

size [ 591.000 638.000 ]

center [-0.010 -0.040]

scale 0.028

)

# load ’cave’ map

map

(

bitmap "bitmaps/cave.png"

size [16 16]

name "cave"

)

# create pioneer2dx robot with laser device

pioneer2dx

(

name "robot1"

color "red"

pose [-5 -5.5 90]

laser()

)

Page 51: Implementation of Radio Communication and Multi-Hop Data Forwarding

B. Player Client Programs

Link information example

This example describes how to read the current link information in a wireless

scenario. This Player client is written using the C++ client library enhanced with

some methods to easily obtain the link information.

#include <iostream>

#include <libplayerc++/playerc++.h>

int main(int argc, char *argv)

{

using namespace PlayerCc;

// instantiate Player client on localhost

PlayerClient robot("localhost");

// create to various proxy devices

LaserProxy lp(&robot,0);

Position2dProxy pp(&robot,0);

WiFiProxy wp(&robot,0);

for() {

robot.Read();

int links = wp.GetLinkCount();

char* ip = wp.GetOwnIP();

std::cout<< "<----------Own State--------->" <<std::endl;

std::cout<< "Number of links:�" << links <<std::endl;

std::cout<< "Robots IP adress:�" << ip <<std::endl;

std::cout<< "<---------------------------->" <<std::endl;

Page 52: Implementation of Radio Communication and Multi-Hop Data Forwarding

B. Player Client Programs 43

for ( int j=0; j<links; j++ ) {

std::cout<< "----------Link No.: " << j+1 << "--------" <<std::endl;

std::cout<< "IP adress:�" << wp.GetLinkIP(j) <<std::endl;

std::cout<< "MAC adress:�" << wp.GetLinkMAC(j) <<std::endl;

std::cout<< "ESSID:�" << wp.GetLinkESSID(j) <<std::endl;

std::cout<< "Frequency:�" << wp.GetLinkFreq(j) <<std::endl;

std::cout<< "Link mode:�" << wp.GetLinkMode(j) <<std::endl;

std::cout<< "Encrypted:�" << wp.GetLinkEncrypt(j) <<std::endl;

std::cout<< "Link quality:�" << wp.GetLinkQuality(j) <<std::endl;

std::cout<< "Link level:�" << wp.GetLinkLevel(j) <<std::endl;

std::cout<< "Link noise:�" << wp.GetLinkNoise(j) <<std::endl;

std::cout<< "----------------------------" <<std::endl;

}

}

}

Page 53: Implementation of Radio Communication and Multi-Hop Data Forwarding

B. Player Client Programs 44

Sending messages using Players’ plug-in driver

To send messages using the presented Player plug-in driver is easy. The user just

has to specify the correct Opaque device, define the data to send and handle it over

to the Interface. The message is forwarded as long as the time-to-live (TTL) value

is positive. After sending the message the client waits 3 seconds and broadcasts it

again.

#include <iostream>

#include <libplayerc++/playerc++.h>

#include <time.h>

#include <args.h>

int main(int argc, char *argv)

{

parse_args(argc, argv);

using namespace PlayerCc;

PlayerClient robot(gHostname,gPort);

PlayerClient relay(gHostname,gPort);

OpaqueProxy op(&relay,1);

player_opaque_data_t opData;

opData.data_count = 2;

for (;;) {

opData.data0 = 3; // ttl

opData.data1 =’F’; // data

op.SendCmd(&opData);

printf("Data sent!");

sleep(3);

}

}

Page 54: Implementation of Radio Communication and Multi-Hop Data Forwarding

C. Reasonable Coefficients for

Radio Propagation models

ITU Indoor Path Loss Model

The ITU Recommendation [P.101] specifies reasonable values for their proposed

indoor radio propagation model. Table C.1 gives examples for the distance power

loss coefficient while Table C.2 states more precisely how to deal with the floor

penetration loss factor.

Frequency Residential Office Commercial900 MHz - 33 201.2-1.3 GHz - 32 221.8-2.0 GHz 28 30 224 GHz - 28 225.2 GHz - 31 -60 GHz - 22 17

Table C.1: Power loss coefficients, N , for indoor transmission loss calculation

Frequency Residential Office Commercial900 MHz - 9 (1 floor) -

19 (2 floors)24 (3 floors)

1.8-2.0 GHz 4n 15+4(n-1) 6+3(n-1)5.2 GHz - 16 (1 floor) -

Table C.2: Floor penetration loss factor, Pf (n), n ≥ 1


Related Documents