implementation of radio communication and multi-hop data forwarding
TRANSCRIPT
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
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
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
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.
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.
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
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
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
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
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.
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
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.
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.
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
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.
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
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
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
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
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.
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.
2. The Player/Stage Robot Simulator 13
Figure 2.5: Player/Stage simulation overview
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
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
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,
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
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.
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
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
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
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
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.
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.
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
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
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.
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
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-
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.
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.
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-
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.
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
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.
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.
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
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.
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"
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
)
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()
)
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;
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;
}
}
}
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);
}
}
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