ALBERT-LUDWIGS-UNIVERSITY OF FREIBURG DEPARTMENT OF COMPUTER SCIENCE Implementation of Radio Communication and Multi-hop Data Forwarding in Player/Stage Robot Simulator Bachelor’s Thesis To obtain the grade Bachelor of Science presented by Michael Sebastian Schr¨ oder at Computer Networks and Telematics Professor: Prof. Dr. Christian Schindelhauer Advisor: M.Eng. Chia Ching Ooi July 2007
54
Embed
Implementation of Radio Communication and Multi-Hop Data Forwarding
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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