ALBERT-LUDWIGS-UNIVERSITY OF FREIBURG DEPARTMENT OF COMPUTER SCIENCE

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

Bachelors Thesis
To obtain the grade Bachelor of Science presented by

Michael Sebastian Schrder o

at

Computer Networks and Telematics Professor: 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 Bachelors thesis was neither used in total nor in extraction for any other work.

Freiburg, July 31, 2007

You see, wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Do you understand this? And radio operates exactly the same way: you send signals here, they receive them there. The only dierence is that there is no cat. 1 Albert Einstein

Abstract
Over the few past decades the scientic 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 communication devices, more attention has been drawn to communications. Questions about the ecient 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 signicant progress in the eld of robot simulators. Modern simulators do not only visualise robots in their particular environment, but provide sophisticated algorithms for localisation, path-planning and mapping, among others. One that is widely used is the Player/Stage robot simulator. 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.

Unsourced citation, attributed to Einstein

Zusammenfassung
In den letzten Jahrzehnten wurde die Wissenschaft der Robotik mageblich durch Mechanik, Kontrolltheorie und Elektronik dominiert. In letzter Zeit und vor allem durch die weitreichende Verfgbarkeit drahtloser Netzwerke, wurde der Kommuu nikation zwischen mobilen Robotern immer mehr Beachtung geschenkt. Fragen nach der ezienten und koordinierten Bewltigung bestimmter Aufgaben, a 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 ermglichen nicht nur die Visualo isierung der Roboter in ihrer jeweiligen Umgebung sondern stellen weitgehende Algorithmen, wie etwa zur Lokalisierung, Pfadplanung oder Kartographierung bereit. Ein sehr bekannter und bewhrter Robotsimulator ist das Player/Stage-System. a Ziel dieser Arbeit ist es diese Simulationsumgebung derart zu erweitern, dass mobile autonome Roboter in der Lage sind, unter Bercksichtigung ihrer gegenwrtigen u a drahtlosen Verbindungsinformationen, zu kommunizieren. Ein Modul wird implementiert, welches unter besonderer Beachtung der Ausbreitung von Radiowellen eine drahtlose Netzwerkschnittstelle simuliert. Weiterhin wird ein Plug-in Treiber fr Player entwickelt, der grundlegende Forwarding-Funktionalitt bietet und das u a 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 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 4.1 4.2 4.3 4.4 4.5

Wireless ad-hoc networking overview . . . . . . . . . . . . . . . . . Example: Player server on ActivMedia robot Example conguration le . . . . . . . . . . . Pioneer 2dx robot in Stage simulation . . . . . Robot conguration in Stage worldle . . . . . Player/Stage simulation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. 8 . 9 . 10 . 12 . 13 . . . . . . . . . . . . . 15 17 20 21 22 24 25 26 28 30 31 32 32

Overview of radio device . . . . . . . . . . . . . . . . . . . . Implementation overview . . . . . . . . . . . . . . . . . . . . Stage worldle properties for simple radio propagation model Stage worldle properties for free space model . . . . . . . . Worldle properties for ITU indoor model . . . . . . . . . . Worldle properties for Log Distance Path Loss Model . . . Worldle properties for Simple Raytracing model . . . . . . Connectivity visualisation by Simple Raytracing model . . . Structure of communication plug-in driver Conguration for communication driver . . Robot discovers injured person . . . . . . . Robot forwards fallback message . . . . . Message received by all nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Tables

2.1 2.2 3.1 3.2

Comparison between Stage and Gazebo . . . . . . . . . . . . . . . . 7 Available device models in Stage . . . . . . . . . . . . . . . . . . . 11 Link budget to determine connectivity . . . . . . . . . . . . . . . . 16 Methods by Radio Communication Module . . . . . . . . . . . . . . 18

C.1 Power loss coecients . . . . . . . . . . . . . . . . . . . . . . . . . 45 C.2 Floor penetration loss factor . . . . . . . . . . . . . . . . . . . . . . 45

Contents

1 Introduction 1.1 Wireless Networking Background 1.2 Network Simulators . . . . . . . . 1.3 Robot Simulators . . . . . . . . . 1.4 Motivation . . . . . . . . . . . . . 1.5 Objective . . . . . . . . . . . . . 1.6 Structure of thesis . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

1 2 4 4 5 5 5 7 8 9 9 10 11 11 12 14 14 15 17 17 18 19 19

2 The Player/Stage Robot Simulator 2.1 The Robot Server Player . . . . . . 2.1.1 Devices, Interfaces, Drivers . 2.1.2 Conguration les . . . . . 2.2 Device Simulator Stage . . . . . . . 2.2.1 Device models . . . . . . . . 2.2.2 Stage worldle . . . . . . . 2.2.3 Player and Stage . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

3 Radio Communication Module for Stage 3.1 Preliminaries . . . . . . . . . . . . . . . 3.1.1 Radio Propagation . . . . . . . . 3.2 Implementation . . . . . . . . . . . . . . 3.2.1 Radio Communication Module . . 3.2.2 Player Interface . . . . . . . . . . 3.2.3 Radio Communication in Player . 3.3 Implemented Radio Propagation Models

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

CONTENTS 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 Simple Model . . . . . . . . . . Free Space Model . . . . . . . . ITU Indoor Path Loss Model . Log Distance Path Loss Model . Simple Raytrace Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii 20 20 22 23 24 27 28 29 30 32

4 Radio Communication Plug-in Driver 4.1 Implementation . . . . . . . . . . . . 4.2 Conguration . . . . . . . . . . . . . 4.3 Example Scenario . . . . . . . . . . . 4.4 Capabilities . . . . . . . . . . . . . .

for Player . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5 Conclusion 34 5.1 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendices A Conguration les B Player Client Programs C Coecients for Radio Propagation models 39 39 42 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, multiple robots scour through a hazardous area in search of victims. A group of autonomous UAVs (Unmanned Aerial Vehicle) observes and tracks down a suspicious 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 eciently. 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 communication 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 communications devices (nodes) that wish to communicate, but have no xed infrastructure available, and have no pre-determined organization of available links. Individual nodes are responsible for dynamically discovering 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

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 specication [IEE], rst 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 rst, there is no base station available, as a result nodes are responsible to congure and route data among themselves. With regard to the OSI Reference Model IEEE 802.11, like the other 802 standards, species 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

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 specied 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 dierent, 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 As radio range. To accomplish this, various protocols like AODV (Ad-hoc On-demand Distance 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 between 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

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 NS2 [NS], implement a large number of network types, protocols and trac models. Typically these network simulators cover a variety of dierent layer implementations and provide valuable insights on how the network functions. For instance, NS-2 comprises support for mobile networks, providing a variety of routing protocols based on three dierent 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 pathplan 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 unaordable 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. Signicant research was carried out on these simulators leading to extensive software-packages, often providing sophisticated algorithms for localization, path-planning and mapping [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 models 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

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 environmental conditions. Aside from a neat visualisation of the current radio devices state, the module should seamlessly integrate into the existing Player/Stage system, 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 rst given to the Player/Stage system, dealing with conguration, messaging and client programming, among others. The robot server

1. Introduction

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.

All the worlds a stage, And all the men and women merely players William Shakespeare, As You Like It

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 fundamental 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 dierence between the real robot devices and their simulated Stage equivalents [Vau06]. The third software package is also a simulator called Gazebo. Contrary to Stage, which serves as a low-delity 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 delity. In the following section, the combination of Player and Stage is explained in more detail.

Stage dimensionality 2D delity low population 10s-100s

Gazebo 3D high max.10

Table 2.1: Comparison between Stage and Gazebo

2. The Player/Stage Robot Simulator

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 typically runs on the robot itself and hides the actual complexity of the robots hardware by drawing in an additional layer. This layer species generic concepts as interfaces, 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 dierent underlying devices through a generic interface. For instance, the Hokuyo URG scanning laser range-nder, 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 dierent kind of robot, you would use its corresponding driver.

Figure 2.1: Example: Player server on ActivMedia robot

2. The Player/Stage Robot Simulator

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 exchanging 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 eld histogram navigation), wavefront (path planner) or nd (nearness diagram navigation) [Vau06].

2.1.2

Conguration les

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 conguration le that species 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 conguration le 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 dened as localhost and

2. The Player/Stage Robot Simulator

10

6665. The robot eld 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 simulator 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 conguration le, as well as its own so-called worldle [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 conguration in the Stage world while in the right window the program 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 rangender, ducial detector and, most importantly, a robot base with odometry. Typically, models are quite general and need to be adapted in order to reect the real devices 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 blobnder bumper ducial gripper laser position ptz ranger speech

Description color-blob-nding vision device binary touch sensors ducial-detecting device two-ngered gripper device scanning laser rangender mobile robot base pan-tilt-zoom camera head sonar/ infra-red rangender draws a message bubble

Table 2.2: Available device models in Stage

2.2.2

Stage worldle

Similarly to Player, Stage requires a conguration le named worldle that is mainly responsible for describing devices and the world itself. In this le the user sets device properties, species map-size and resolution, as well as simulation intervals. It needs to be written in correspondence to the Player conguration le. Additionally, a few lines are needed in Players cong-le 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 congured. The eld of view (fov) adds up to 180 degrees with a sample size of 180 rays.

2. The Player/Stage Robot Simulator 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 conguration in Stage worldle

12

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-specic 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 conguration le and congured further in Stages worldle. 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 modications 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 module is designed in the style of WLANs. One important property of this module should be that it is easily deployable, ensuring high re-usability. Besides an easy conguration, the module should simulate a variety of parameters including IP and MAC addresses, ESSID, as well as physical 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-delity device simulator and it should be kept that way. Therefore, the aim is not to simulate a wireless device with great delity 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 signicance to model the propagation of radio waves

3. Radio Communication Module for Stage to determine which node is reachable and which is not.

15

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 gure, 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 diusion of all electromagnetic waves in free space is proportional to the inverse square of the distance to the originating source [Rap01]. However, the propagation of all electromagnetic waves is exposed to environmental inuences that can aect their behaviour signicantly. For example ionospheric

3. Radio Communication Module for Stage

16

conditions, determined by the activity of our sun, aect high frequency (HF) radio wave propagation [Jon]. Materials and the architecture of a building inuence the behaviour of ultra high frequency (UHF) waves, which are mainly used for wireless LAN. Generally, radio waves at dierent frequencies behave dierently and, due to the environmental inuences, it is dicult 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 eects 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) path loss PL (dB)

Propagation 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 ts the environmental conditions. If the link budget given by Table 3.1 is positive,

3. Radio Communication Module for Stage then a link between transmitter and receiver can be established.

17

3.2

Implementation

As depicted in Figure 3.2, the implementation of the radio communication module substantially comprises four parts. First, the model le 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 exibility and conguration 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 briey 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 Method init load startup update shutdown render data render cfg unrender data unrender cfg

18

Description set default properties, add menu items for rendering called after init and reads properties from worldle called when rst subscriber subscribes account for change of the virtual world called when last subscriber unsubscribes and resets properties visualise connectivity display communication range clear data visualisation clear cong 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 o during a simulation. Right after init the loading function load is called, which reads the worldle and sets the specied parameters accordingly. For example, the simulated IP and MAC addresses, as well as the ESSID, can be specied in the worldle 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 reecting 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 conguration 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-specic 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 implementation 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 dierent frequencies are exposed to very dierent environmental 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 eects (like rain). Indoor models 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 implementation of the radio communication module provides ve dierent 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 ts best to accommodate the robots environment. Independent of the used radio propagation module, the user can dene IP and MAC addresses, as well as the ESSID (Extended Service Set Identier), which stands for the name of the network. The following subsections describe every model in detail and give examples

3. Radio Communication Module for Stage of how to use them.

20

3.3.1

Simple Model

The simple model is, as the name suggests, a very basic model. Apart from address specication the user solely has to specify the models name and the communication range. The dened 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 worldle. wifi ( # network properties ip "192.168.0.1" essid "test network" # radio propagation model model "simple" range 5 ) Figure 3.3: Stage worldle 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. eects like reection or diraction 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. 2 P athLoss = 4d

3. Radio Communication Module for Stage

21

Basically, the transmission power is spread over the surface of an increasing sphere. c Keeping in mind that d is the distance from the transmitter and = f , while f is the frequency and c denotes the speed of light, the formula can be resolved in the logarithmic decibel scale as follows: P athLoss(dB) = 10 log10 c 2 4df 3 + 20 log10 (d) + 20 log10 (f ) = 20 log10 4 10 (3.1) = +32.44 + 20 log10 (d) + 20 log10 (f )

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 specied 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 eld, 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 dont have to worry about the near eld. 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 dened in the worldle, 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 worldle 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-specic and site-general. While site-specic 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-specic 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 oors between sender and receiver and is expressed in Eqn. 3.2. P athLoss(dB) = 20 log10 (f ) + N log10 (d) + Pf (n) 28 (3.2)

The empirical distance power loss coecient 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 oor penetration factor Pf (n) tries to accommodate for oors between sender and receiver. The number of oors 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 oor penetration factor is omitted and the user only has to specify the frequency and the power loss coecient. 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: Worldle properties for ITU indoor model

3. Radio Communication Module for Stage

23

ITU indoor model is primarily used for indoor scenarios, for example in oce or residential areas. The power loss coecient 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 accommodate for the various obstacles between sender and receiver by introducing a random variable [ATL06]. P athLoss(dB) = P athLoss(db)d0 + 10 log10 ( d ) + X d0 (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 transmitter. This point is situated in the far eld, 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 oce building [Far05]. In order to take signal uctuations 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 specic loss l is observed is given through: P(Loss = l) = l2 1 exp( 2 ) 2 2 (3.4)

The Log distance model is a widely used indoor propagation model that reects 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 depends on empirical parameters. Figure 3.6 shows how to set the path loss exponent (ple) and the standard deviation (sigma) in Stages worldle.

3. Radio Communication Module for Stage wifi ( model "log distance" ple 4 sigma 6 ) Figure 3.6: Worldle properties for Log Distance Path Loss Model

24

3.3.5

Simple Raytrace Model

The Simple Raytrace model is a site-specic 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 eects like reection, scattering or diraction. 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 do for each wireless device wj and i = j do calculate path loss plij from wi to wj according to ITU indoor model if signali - plij is still detectable by wj then calculate distance of ray through wall dwij new path loss nplij = wallf actor 100 dwij + plij if signali - nplij is still detectable by wj then appendLinkInformation of wj for device wi end if end if end for end 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 worldle congurations are straightforward. The user solely has to specify the model as well as the wallfactor to determine how dicult it is for the signal to pass an obstacle. It has to be mentioned that the results dier depending on how a map, (i.e. a bitmap) looks like, and if the space between surfaces of walls is lled. If it is lled, 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: Worldle 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 environment. The implementation employs the concept of contour lines. The user can set a property called range db in the WiFi devices entry in the worldle. While the other models described above render a circle around the transmitting robot, the Simple Raytrace model will try to nd a good approximation of the levels contour. 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 simple 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 dierent congurations. 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 Systems. Thus, it is not surprising that communication between Robots in a Stage simulation can be achieved easily. For instance, a client program controlling devices 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 Bs 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 reasonable to design a communication system that considers these eects. 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 established. 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 following section describes the implementation, while all necessary conguration 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 modied. The communication 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 components 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 dened messages. It is used twice, rst 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 rst 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 justied. 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 dierent node, this two-layer approach forwards the message without informing the robots client program.

4.2

Conguration

While Stages worldle stays untouched, the conguration le for Player is slightly more involved. This is the case because the developed communication driver requires 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 dened 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 specied, 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 specied IPs match the IPs of the wireless devices, which are specied in the worldle. 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 1 mapping [ "192.168.0.1" 6665 "192.168.0.2" 6666 ] )

Figure 4.2: Conguration for communication driver

4.3

Example Scenario

To motivate the communication driver, as well as to show its capabilities, imagine a rescue scenario where ve robots search through a building which is about to collapse in order to nd 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 ooding, the user must specify a time-to-live (TTL), which is the rst 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 sophisticated routing driver. It enables nodes to send, receive and forward messages according to a time-to-live value (TTL), specied 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 messages and can be deployed in scenarios where this is sucient. 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 dierent 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 appropriate to specify a driver specic 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 ve dierent radio propagation models. Aside from site-general, with Simple Raytrace, a side-specic model can be found. By means of this radio communication module, the user can reproduce a variety of dierent 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 reasonable 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-delity device simulator for large populations of virtual robots. However, radio

5. Conclusion

35

propagation can be tricky and the implemented models might not t 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 reection, diraction and scattering. The computational costs would increase signicantly and, since it is not possible to specify reection values for dierent 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 dierent 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. Future applications might include evaluations of coordinated behavior under varying constraints, for instance dierent 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 insights on how systems might behave under real world conditions. For example, the radio propagation model used in simulation has great impact on how ecient a routing protocol appears to be [SW06]. Furthermore, a promising future application is the implementation of a radio communication module for the three-dimensional outdoor robot simulator Gazebo. Since Gazebo comprises high-delity 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 Communications.

[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 Wireless 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 317323, 2003. [I99a] IEEE Standard 802, Part 11: Amendment 1: High-speed Physical Layer in the 5 GHz Band. IEEE Standard 802, Part 11: Supplement: Higher-speed Physical Layer Extension in the 2.4 GHz Band.

[I99b]

BIBLIOGRAPHY [IEE]

37

IEEE Standard 802, Part 11: Wireless Lan Medium Access Control (MAC) and Physical Layer (PHY) specications. Edwin C. Jones. The Basics of Radio Wave Propagation. http:// ecjones.org/propag.html. James Kramer and Matthias Scheutz. Development environments for autonomous mobile robots: A survey. Auton. Robots, 22(2):101132, 2007. Radio theory and link planning for Wireless LAN (WLAN). http: //www.swisswireless.org/wlan calc en.html. MissionLab User Manual. Technical report, College of Computing, Georgia Institute of Technology, Atlanta. The Network Simulator NS-2. http://www.isi.edu/nsnam/ns/. 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.

[Jon]

[KS07]

[LB0]

[ML]

[NS] [P.101]

[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 Practice. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. R. Ramanathan and J. Redi. A Brief Overview of Ad hoc Networks: Challenges and Directions. IEEE Communications Magazine, pages 2022, May 2002. Joseph A. Shaw. Radiometry and the Friis Transmission Equation, 2005. Arne Schmitz and Martin Wenig. The eect of the radio wave propagation model in mobile ad hoc networks. In MSWiM 06: Proceedings of

[RR02]

[Sha05]

[SW06]

BIBLIOGRAPHY

38

the 9th ACM international symposium on Modeling analysis and simulation of wireless and mobile systems, pages 6167, New York, NY, USA, 2006. ACM Press. [UA04] Patrick Ulam and Ronald C. Arkin. When good comms go bad: Communications recovery for multi-robot teams. In Proceedings of the International Conference on Robotics and Automation (ICRA 2004), volume 4, pages 37273734, 2004. Richard Vaughan. The Player Project. Website, 2006. Available online at http://playerstage.sourceforge.net/; visited July 13th 2007.

[Vau06]

A. Conguration les

Player conguration le example

More complex example for Player conguration le, instantiating a robot in a Stage simulation. The robot uses the adaptive Monte Carlo localization algorithm together with a vector eld 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. Conguration les

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. Conguration les

41

Stage worldle example

Stage worldle, 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<< std::cout<< std::cout<< std::cout<< "<----------Own State--------->" <<std::endl; "Number of links:" << links <<std::endl; "Robots IP adress:" << ip <<std::endl; "<---------------------------->" <<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, dene 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 #include #include #include

<iostream> <libplayerc++/playerc++.h> <time.h> <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 Coecients for Radio Propagation models

ITU Indoor Path Loss Model

The ITU Recommendation [P.101] species reasonable values for their proposed indoor radio propagation model. Table C.1 gives examples for the distance power loss coecient while Table C.2 states more precisely how to deal with the oor penetration loss factor. Frequency 900 MHz 1.2-1.3 GHz 1.8-2.0 GHz 4 GHz 5.2 GHz 60 GHz Residential 28 Oce Commercial 33 20 32 22 30 22 28 22 31 22 17

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

Frequency 900 MHz

Residential -

1.8-2.0 GHz 5.2 GHz

4n -

Oce Commercial 9 (1 oor) 19 (2 oors) 24 (3 oors) 15+4(n-1) 6+3(n-1) 16 (1 oor) -

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