ROSint - Integration of a mobile robot in ROS architecture

Department of Electrical and Computer Engineering

Faculty of Sciences and Technology

University of Coimbra

ROSint - Integration of a mobilerobot in ROS architecture

André Gonçalves Araújo

A Dissertation presented for the degree of

Master of Science in Electrical and Computer Engineering

Coimbra, July 2012

ROSint - Integration of a mobilerobot in ROS architecture

Supervisor:

Prof. Doutor Rui P. Rocha

Co-Supervisors:

Eng. David Portugal

Eng. Micael Couceiro

Juries:

Prof. Doutor Armando Sousa

Prof. Doutor Jorge Lobo

Prof. Doutor Lino Marques

Prof. Doutor Rui P. Rocha

Project report written for the dissertation subject, included in the

Electrical and Computer Engineering Course, submitted in partial fulfillment

for the degree of Master of Science in Electrical and Computer Engineering.

Coimbra , July 2012

Agradecimentos

Em primeiro lugar quero começar por agradecer em especial ao Professor Doutor Rui

Rocha na minha orientação neste trabalho, prezando pelo seu rigor, organização e es-

timulação constante, onde sempre depositou bastante confiança nas capacidades do meu

trabalho.

Quero também agradecer, pelo apoio incondicional dos meus co-orientadores David Por-

tugal e Micael Couceiro, pela sua persistência, motivação e ajuda nos momentos mais

difíceis deste trabalho. Para além de orientadores, levo desta experiência dois grandes

amigos.

Agradeço também ao Instituto de Sistemas e Robótica, pelas óptimas condições disponi-

bilizadas, bem como todos os meus colegas de trabalho por toda a boa disposição e

companheirismo, que contribuíram para o meu bom estado de espirito, para progredir

neste trabalho.

Aos meus pais, agradeço profundamente pelo empenho, dedicação e paciência que propul-

sionaram na minha boa formação, dando me sempre a oportunidade de ter tudo de bom

e melhor, obrigado do fundo do coração. Não podendo esquecer, todo o apoio e carinho

prestado pela a minha família e namorada ao longo destes anos: Ângela, avós, tios e

primos.

Não podia deixar de agradecer a todos os amigos de Braga, em especial atenção ao Aníbal,

Bruno, Carlos, Catarina, Joana, Luís, Maura, Rui, Sérgio, Telmo e Vitor por nunca se

esqueceram de mim, apesar do pouco tempo que lhes disponibilizei. Aos amigos de Coim-

bra, André Oliveira, André Santos, Gonçalo Ferreira, Gonçalo Palaio, João, Nuno, Patrí-

cia Monteiro, Sérgio, as irmãs Patrícia e Filipa Ferraz e muitos outros, que me ajudaram

desde o primeiro dia em Coimbra até ao final.

Um obrigado muito especial, pelo tempo disponibilizado e atenção, por parte das pessoas

v

vi

que contribuíram para a realização deste trabalho Amadeu Fernandes (MRL, ISR), Beat-

riz Garrido (DEI, FCTUC), Gonçalo Cabrita (LSE, ISR) e Michael Ferguson (University

of Albany / Willow Garage).

Para finalizar, por todos os momentos felizes, pessoas conhecidas, vivências e experiências

passadas e especialmente a pessoa que me tornaste hoje, muito obrigado Coimbra, que

me deixas saudade para a vida.

Abstract

The goal of this work is to provide hardware abstraction and intuitive operation modes

to decrease the development and implementation time of robotic platforms, thus allowing

researchers to focus in their main scientific research motivations, e.g., search and rescue,

multi-robot surveillance, swarm robotics, among others. To that end, this work presents

the development of a compact mobile low-cost robotic platform, denoted as TraxBot, de-

veloped and assembled at the Institute of Systems and Robotics (ISR), which has been

fully integrated in the well-known Robot Operating System (ROS) framework.

Furthermore, several available mobile robots are compared and discussed in terms of their

physical dimensions, hardware, sensors, communication abilities, motion, maximum run

time and special features. This provides support to the reader on the decision-making

acquisition process of a cost-effective robotic platform.

Beyond the survey’s results, the robotic system assembly, with a full description of its

components as well as detailed information about the microcontroller programming, de-

velopment and testing are also presented. The potentialities of the TraxBot are described,

which combined with the herein presented ROS driver; provide several tools for data anal-

ysis and easiness of interaction between multiple robots, sensors and teleoperation devices.

In order to validate the approach, several experimental tests were conducted using both

real and mixed teams of real and virtual robots.

Key Words: ROS, Arduino, mobile robot, embedded system, integration.

Resumo

O objectivo deste trabalho é contribuir, através de abstracção de hardware e criação de

modos de operação intuitivos, na redução drástica do tempo de desenvolvimento e im-

plementação de plataformas móveis. Isto permite aos investigadores focarem-se na sua

motivação principal, tal como busca e salvamento, segurança com múltiplos robôs, swarm

robotics, entre outros. Assim sendo, desenvolveu-se no Instituto de Sistemas e Robótica

(ISR), uma plataforma robótica móvel, denominada TraxBot para simplificar este ob-

jectivo. A plataforma foi completamente integrada no ROS (Robot Operating System),

bastante em voga actualmente.

Para além disso, é apresentada uma vasta gama de robôs, comparando e discutindo as

suas características físicas, dimensões, sensores incorporados, poder de processamento,

particularidades de hardware, tempo de autonomia bem como a relação qualidade preço.

O TraxBot é apresentado com a total descrição dos seus componentes, dando ênfase a

detalhes sobre programação, unidade de processamento, características sensoriais e abor-

dagem usada para o desenvolvimento deste robô. É de referir ainda, que as potencialidades

da plataforma são discutidas, juntamente com o driver de integração deste robô em ROS.

Esta integração disponibiliza uma grande variedade de ferramentas e métodos de progra-

mação, sendo possível a interacção entre múltiplos robôs, sensores e tele-operação, entre

outras aplicações. Para validar a abordagem, foram realizados vários teste, a nível de de-

sempenho da plataforma, bem como testes usando robôs reais juntamente com simulação

de virtuais.

Palavras Chave: ROS, Arduino, robô móvel, sistemas embebidos, integração.

Declaration

The work in this dissertation is based on research carried out at the Mobile Robots

Laboratory of ISR (Institute of Systems and Robotics) in Coimbra, Portugal. No part of

this thesis has been submitted elsewhere for any other degree or qualification and it is all

my own work unless referenced to the contrary in the text.

Copyright © 2012 by André Gonçalves Araújo.

“The copyright of this thesis rests with the author. No quotations from it should be

published without the author’s prior written consent and information derived from it

should be acknowledged”.

xi

“Once we accept our limits,

we go beyond them.”

Albert Einstein

Contents

Agradecimentos v

Abstract vii

Resumo ix

Declaration xi

Contents xv

List of Figures xix

List of Tables xx

Notation xxiii

1 Introduction 2

1.1 Context and motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Hardware abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Outline of the dissertation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Related work 6

2.1 Compact mobile robotic platforms . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 ROS: Robot Operating System . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

xv

Contents xvi

3 The TraxBot platform 14

3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Processing and Motion Controller units . . . . . . . . . . . . . . . . . . . . 18

3.4 Sonars and Odometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Batteries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.7 Kinematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.8 TraxBot cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 TraxBot ROS Driver 26

4.1 ROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.2 Gold marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 ROS driver development for TraxBot . . . . . . . . . . . . . . . . . . . . . 29

4.2.1 Driver - version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.2 Driver - version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2.3 Driver Features and Potential . . . . . . . . . . . . . . . . . . . . . 35

4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Results and Discussion 40

5.1 Odometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Sensing and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 ROS Driver Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.1 Point-to-point Motion . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.2 Mixed virtual and real robots teams . . . . . . . . . . . . . . . . . . 46

5.4.3 Teleoperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.4.3.1 Adaptation of the ROS driver in different platform . . . . 48

5.5 ROS Driver Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5.1 Driver first version . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Contents xvii

5.5.2 Driver second version . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Conclusions 52

6.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.1.1 Published Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

References and Bibliography 54

List of Figures

2.1 Roomba Create. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Bot’n Roll ONE C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Circular GT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Hemisson. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Mindstorms NXT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 SRV-1 Blackfin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.7 E-puck. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.8 marXbot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.9 TraxBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.10 TurtleBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.11 Pioneer-3DX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 TraxBot dimensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Mechanical structure of the TraxBot. . . . . . . . . . . . . . . . . . . . . . 16

3.3 TraxBot’s main schematic. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 OMNI-3MD I2C protocol frame. . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 Control architecture of the robotic platform. . . . . . . . . . . . . . . . . . 20

3.6 Sonars chain connection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.7 Encoder signals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.8 XBee Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.9 Comparison of capacity and power of rechargeable batteries [Roo10]. . . . 23

3.10 TraxBot kinematics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 ROS architecture example diagram. . . . . . . . . . . . . . . . . . . . . . . 27

4.2 ROS driver architecture diagram. . . . . . . . . . . . . . . . . . . . . . . . 30

xix

List of Figures xx

4.3 Rxgraph topics and nodes provided by the TraxBot driver. . . . . . . . . 31

4.4 Frame protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.5 ROS driver architecture diagram - version 2. Comparison with the first

driver (Fig. 4.2), depicting the changes in red and what was unchanged in

green. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.6 Network topology example with multiple robots, sensors, teleoperation de-

vices and applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Odometry square test evaluation.

a) Clockwise (CW) direction b) Counter-clockwise (CCW) di-

rection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Sonar calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Mapping test. a) Sonars b) Laser. . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Noisy range situations. a) Issue during rotations using lateral sonars b)

This figure illustrates why the front sonar is not used for mapping. . . . . . 44

5.5 Power consumption behavior. . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.6 Driver Test. a) Real step test b) Stage simulation. . . . . . . . . . . . . . 45

5.7 TraxBot teleoperation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.8 Driver Test. a) Two robots with reactive navigation b) Mixed real and

virtual robots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.9 TraxBot teleoperation devices. . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.10 StingBot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.11 StingBot operating with ROS driver. . . . . . . . . . . . . . . . . . . . . . 48

5.12 ROS driver messages turnaround time for the ROS driver - version 1. . . . 49

5.13 ROS driver messages turnaround time for the ROS driver - version 2. . . . 50

List of Tables

2.1 Comparative robot table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 TraxBot hardware specifications. . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Traxbot total cost in euros. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

xxi

Notation

Cs Slipping offset.

Dl Number of pulses sent by left wheel encoder.

Dr Number of pulses sent by right wheel encoder.

Np Total number of pulses per revolution read by encoders.

Rr Radius of the robot.

Rw Radius of the robot wheels.

θ Angle of rotation between the current and the target position.

xn−1 Component x of the previous robot pose.

xn Component x of the current robot pose.

yn−1 Component y of the previous robot pose.

yn Component y of the current robot pose.

d Distance between the current and the target position.

xxiii

Chapter 1

Introduction

This dissertation describes the integration of a fully developed mobile robot denoted as

TraxBot on Robot Operating System (ROS) [QGC+09]. This project took place at the

Mobile Robots Laboratory of ISR (Institute of Systems and Robotics) in Coimbra. The

main goal of this master degree project is the study and development of robotic drives,

to easily integrate a mobile platform on ROS for future use by the robotics community,

providing hardware abstraction.

There were four main work phases. Starting with the physical assembly of the mobile

robot TraxBot [APC+12], describing the implementation of the electronic modules. The

second phase consisted in the development of the functional architecture of the mobile

robot. Several tests were carried out in order to evaluate the odometry, sonars and other

technical features of the TraxBot. The next phase consisted on studying and implementing

algorithms to fully integrate the mobile robot on ROS. Finally, several tests were carried

out to evaluate the protocols, main functions and full system integration.

This chapter presents the context and motivation for this study, its main goals and gives

an outline of the dissertation.

1.1 Context and motivation

Mobile robotics is a research area that has witnessed incredible advances for the last

decades. Issues like autonomous navigation, active perception, map learning, obstacle

avoidance and self-localization, have been deeply studied for the past years. Mobile robots

2

1.1. Context and motivation 3

are found in industry, transportation and in military and security environments [Pet11].

Also, some mobile robots have emerged as consumer products for entertainment or to

perform daily domestic tasks, like vacuum cleaning [Jon06]. Earlier, the focus of re-

search was especially on large and medium structures. However, with the recent advances

in electronics, sensor miniaturization and in microcontrollers computational power, the

emphasis has been put on the development of smaller and lower cost robots, which en-

ables affordable experimentation with relatively large groups of robots. Several different

robotic systems have been developed for research in different fields like search and rescue,

patrolling, security applications, cooperative robotic systems, human robot interaction

and, nowadays, almost every major engineering institute hosts one or more laboratories

focusing on mobile robotics research. Frequently, the need for practical integration tools

to implement valuable scientific contributions is felt. However, in the robotics research

area, roboticists end up spending excessive time with engineering solutions for their par-

ticular hardware setup.

Following the trend of research, this work focuses on a low-cost, open-source mobile robot

that enables researchers, even the ordinary student and robot enthusiasts, to easily step

into the robotics and artificial intelligence world. Hence, this dissertation presents in de-

tail the TraxBot robotic platform [APC+12], its features, price, communication abilities,

autonomy, and module integration, among others. Nevertheless, there is still a major issue

within the robotic community: a common framework to standardize a fully integration

system, thus avoiding the waste of unnecessary assembly and integration time [Miz05].

Robot Operating System (ROS) was create to solve this integration problem. Just as

common operating computer systems, it allows to easily plug and play multiple devices

in a host system.

ROS can be defined as a framework for robot development providing standard operat-

ing system services such as hardware abstraction, low-level device control, implementation

of commonly-used functionality, message-passing between processes and package manage-

ment. It is based on a graph architecture where the processing takes place in nodes. Before

the existence of ROS, the standard procedure encompassed single and out-community de-

velopment, which became a tremendous disadvantage because robotic software developed

for a particular robot platform required extensive adaptation to deal with different robots

1.2. Hardware abstraction 4

specifities making code reuse non-trivial. In other words, code implementation could not

be abstracted from hardware.

1.2 Hardware abstraction

Hardware abstraction is a set of software routines that emulate some platform-specific

details, giving direct access to the hardware resources. This allows programmers to write

algorithms in a high-level language for high performance applications, thus avoiding stan-

dard operating system hardware calls. This makes portability easy in applications and

plug devices.

In this particular case study, hardware abstraction is very important to overtake some

complex issues, like exchanging information between sensors, robots, tracking systems,

multi robot systems, simplify communications, by standardizing the acess to the informa-

tion.

By using hardware abstraction, the robotic community benefits from the expertize of

other scientific areas like mathematics, biology, health and social interaction, since now

it is possible to implement their theories, algorithms and approaches independently of

hardware details.

1.3 Objectives

The first objective of the present work is the assembly and integration of the various

hardware components of a low cost mobile robot. Secondly, the development of a robot

driver to allow its integration into the ROS framework providing hardware abstraction and

finally, the validation of the work by conducting tests with the robot and the respective

driver in typical situations of their use based on ROS.

1.4 Outline of the dissertation

This dissertation is organized in 6 chapters. The first chapter introduces the context and

motivation, and the objectives of this work.

Chapter 2 reviews some of the most relevant related work, including the comparison to

1.4. Outline of the dissertation 5

other similar mobile robotic platforms.

TraxBot is presented in more detail in chapter 3 , including its assembly and a description

of its main hardware parts and electronic modules.

Chapter 4 presents the driver development to integrate the TraxBot on ROS. In this

chapter, it will be presented a general overview of this meta operating system, as well

as some important features. Also, it is provided detailed information about two driver

development approaches that were followed in different stages of this research. To finish

this section, potential applications of the driver are discussed.

Chapter 5 presents experimental tests that were carried out to validate the robotic plat-

form and the ROS driver that was developed, along with a discussion of the obtained

results.

Finally, chapter 6 sums up the work, providing final conclusions and prospecting future

directions of research.

Chapter 2

Related work

In this chapter, a global overview of compact mobile robots used in academic research

and by robot enthusiasts is presented. A list of popular mobile robots used in the robotics

community are compared with TraxBot [APC+12] in terms of their features, price, com-

munications abilities, size, among others; and also whether they are already integrated

on Robot Operating System.

2.1 Compact mobile robotic platforms

This section focus on similar work, taking into account robots’ mobility in several ground

environments, capability, as well as the size, sensing and perception without compromis-

ing processing power. Here, the major features of each platform are emphasized as well

as their drawbacks.

As known, a vast range of mobile robots are available on the market. In this section,

robots with similar scale are presented [APC+12a], allowing to perform comparative con-

siderations to the TraxBot developed in this dissertation. Simpler and low-cost robots

are presented firstly, then more powerful robots are also described.

Roomba Create from iRobot [Kui09] was designed for students and researchers, being

very popular in the robotics community due to its small size and low cost. It is a light

version of the original vacuum cleaning Roomba , including a cargo bay that houses a 25

pin port used for digital and analogic input and output, instead of the original vacuum

system [Jon06]. It consists in a circular platform with approximately 340 mm of diameter,

6

2.1. Compact mobile robotic platforms 7

Figure 2.1: Roomba Create. Figure 2.2: Bot’n Roll ONE C.

which supports equipment until 2,26kg with extra space for larger sensors (e.g., 3D laser

sensor or Kinect). Many choose to utilize an external computer that supports serial com-

munication to control the Create robot, due to troublesome limitations in storage space

and processing power. In fact, a ROS driver for the Roomba iCreate has already been

developed [Roo12] at the Institute of Systems and Robotics.

Another low cost robot is the SAR’s Bot’n Roll ONE C [SAR10]. It has a differential con-

figuration providing two infrared obstacle detection sensors with possibility to add extra

modules. A USB-Serial (RS232) converter allows the programming of the robot using an

external computer. In general, it is an excellent starting kit for beginners.

Figure 2.3: Circular GT. Figure 2.4: Hemisson.

The IdMind´s Circular GT robot kit [Idm05], with a circular shape of 150mm of diameter,

supported in a plastic board and differential wheels, is smaller than the Bot’n Roll ONE

C, having more I/O ports to connect self-made extensions. It has five pairs of infrared

sensors, two micro-switches for collision detection and 7 additional links to connect other

sensors.

The Hemisson from K-Team [Col10] is more robust than the IdMind´s Circular GT. The

basic kit only provides limited computational power and a few sensors like 8 infrared light

sensors, 6 of them for obstacle detection and 2 facing the ground. It allows flash-memory


programming and supports cameras and ultrasonic sensors beyond others. These exten-

sions may increase both computational power and sensing capabilities.

Figure 2.5: Mindstorms NXT. Figure 2.6: SRV-1 Blackfin.

The Mindstorms NXT from Lego is an educational, academic robot kit for beginners

[Sha07]. The robot is equipped with drive motors with encoders and a good variety of

sensors, like an accelerometer, light, sound, ultrasound and touch sensors enabling appli-

cations in a wide range of scenarios. It also supports Bluetooth and USB communication.

Limited support for interfacing and controlling this robot with ROS is already available.

The SRV-1 Blackfin from Surveyor [CAS08], Fig. 2.6, is a robot equipped with tank-

style quad-motor tracks with differential drive having 120mm length and 100mm width

and an aluminum chassis. This robot has considerable processing power, with a CPU of

1000MIPS at 500MHz capable of running Linux Kernel 2.6. It is equipped with two range

lasers or optional ultrasonic ranging (support up to 4 ultrasonic ranging modules) and

a 1.3MP camera. It also supports Wireless 802.11b/g communication and various I2C

sensors. The robot runs programs stored in the onboard flash memory and can also be

remotely controlled via its webcam (managed by multi-OS).

Figure 2.7: E-puck. Figure 2.8: marXbot.

The E-puck [MBR+09], illustrated in Fig. 2.7, is an educational platform for beginners.

It is a small-sized robot of 80mm diameter, with the ability to perform mobility tests on


Figure 2.9: TraxBot.

a desk. Also, it is equipped with a vast set of sensors like microphones, infrared sensors,

3D accelerometer and a VGA camera, and still offers extension capabilities. According to

its developers, all this technology has a price of around 570€.

The MarXbot [BLM+10] was developed at École Polytechnique Fédérale de Lausanne

(EPFL). It is a fully equipped robot with infrared range sensors, 3D accelerometer, gyro-

scope, and an omnidirectional camera. It has a good processing power with an ARM 11

processor, at 533MHz. The platform is round with 170 mm of diameter and its price is

surely above 700€.

Finally the mobile robot involved in this dissertation, the TraxBot [APC+12], is a plat-

form with 225mm of length and 204mm width and its mobility is based on tracks. TraxBot

is equipped with three powerful range sonars and the platform is suitable to apply several

extensions. It has a very robust chassis and its tracks enable the operability in most

ground environments, feature that most compact mobile robots do not have.

Figure 2.10: TurtleBot. Figure 2.11: Pioneer-3DX.

Another platform built from popular off-the-shelf robot components is TurtleBot [Tur11],

shown in Fig. 2.10. This is a modular development platform that was built on top of an

iRobot Create, incorporating a Xbox Kinect and an ASUS eeePC 1215N netbook. The

platform is fully integrated in the ROS architecture [QGC+09]. TurtleBot provides 3D

functionalities and ROS out of the box, being open source and exploring all combined

capabilities of its components. The complete robot kit costs around 1000€.

2.2. ROS: Robot Operating System 10

Larger, more expensive and even more equipped mobile robots than the compact ones

presented are available. These are generally more powerful, with their own embedded

computers, up to 2GHz dual-core processors, and also heavier, slower and without the

agility of compact ones. One of the most popular research robot is Pioneer 3-DX [ZSS11]

(Fig. 2.11). The base platform is assembled with powerful motors with 500-tick encoders,

19cm wheels, tough aluminum body equipped with 8 forward-facing ultrasonic sensors

sonar, the basic platform costs up to 4500€.

2.2 ROS: Robot Operating System

With the exponential growth in the Robotics field, some difficulties have been found in

terms of writing compatible software for distinct robots. Wildly varying hardware makes

code reuse nontrivial. Opposing this tendency, ROS [QGC+09] provides libraries and

tools to help software developers creating robot applications.

The major goals of ROS are hardware abstraction, low-level device control, implemen-

tation of commonly-used functionalities, message-passing between processes and package

management. One of its gold marks is the amount of tools available for the community, like

the Stage simulator [GVH03], navigation capabilities [MBF+10], visual SLAM [GSB06],

and 3D point cloud based object recognition [RC11], among others. Regular updates

enable the users to obtain, build, write and run ROS code across multiple computers.

Therefore, integrating robots in ROS is highly beneficial, since it strongly reduces the

development time.

Despite many robotic frameworks presented in the last decade, like Player [GVH03],

YARP [MFN06], Orocos [Bru01], CARMEN [MRT03] or Microsoft Robotics Studio [Jac07];

ROS, which was originally released in 2007, has already became the most popular frame-

work, being used worldwide due to all the advantages pointed out before.

Additionally, since it is highly flexible, with a simple and intuitive architecture, ROS inte-

grates important features of other frameworks like several Player robot drivers, the Stage

2D [GVH03] and Gazebo 3D [SVE11] simulation environments and the Orocos stack,

which wraps this modular framework, mostly used in industrial robots and machine con-

trol.

2.3. Summary 11

2.3 Summary

TraxBot Surveyor

SRV-1 Blackfin Roomba iCreate

Lego Mindstorm NXT

K - Team Idmind Bot’n Roll ONE C Hemisson Circular GT

Aprox. Base Price 485,00 € *645,00€ 380,00 € 180,0€ 290,00 € 275,00 € 260,00 € 175,00 €

ROS

Physical Specifications: - Dimension (LxWxH) mm 225x204x76 120x100x80 (-/-/90) 145x97x61 (-/-/70) (-/-/60) 220x200x58 - Dimension diameter mm - - Ø 340 - Ø 120 Ø 150 - - Weight (g) 2045 *3160 3400 150 280 200 200 1300 - Chassis material Aluminum Aluminum Plastic Plastic Aluminum Plastic Acrylic Hardware: (with command module) - Processor 24MIPS 16MHz 1000MIPS

500MHz 20MIPS 20MHz 30MIPS 40MHz 5MIPS 20MHz 5MIPS 20MHz 16MIPS 32MHz

- µController ATmega 328 - ATmega 168 ARM 7 PIC16F877 PIC16F877 Picaxe 40x2 Sensors: - 3x Range sonar - Camera 1.3 MP

- 2 x Range Lasers - Temperature - iR obstacle

detection - micro-switches to cliff detection

- Accelerometer - Touch sensor - Light sensor - Sound sensor - Ultrasonic sensor

- 8x iR 1ight sensor - 6x iR obstacle detection

- 7x iR obstacle

detection - 2x micro-switches

- 2x iR obstacle detection

Communication: - USB serial

- Zigbee - Wireless remote control 802.11b/g

- RS-232 serial - USB serial

- Bluetooth

- USB - DB9 Serial - - USB serial

Speed: (cm/s) 30 40 13 10 10 10 Battery: - Type Ni – MH Li – poly Ni-MH Li-lon AA Ni-MH Alkaline AA Ni – MH - Power 12V 4600mAH 7,4V 2000mAH 14.8V 3000mAH 9V = 6x1.5V 8.4V 150mAh 6V= 4x 1.5V 12V - Autonomy aprox.(hours) 2 -3 3 3 - 4 3 – 4 2 2 2 Features: * with Asus Eee pc

1001PX Processor: Intel Atom N450 1,66 GHz

- Linux 2.6 support - Laser Pointer - Java-based console

- Simple base platform

- LCD display - Construct any configuration with Lego bricks

- Support

sensor and communication expensions - Buzzer

-

- Xbee (socket) - LCD (socket) - Support sensor expensions - Buzzer

Table 2.1: Comparative robot table.

Table 2.1 presents a comparison of all compact low-cost mobile robots described above.

It can be seen that the Roomba Create robot is the cheapest of all. However, it is very

poor in sensing ability, encoder resolution and processing power, usually needing an ex-

ternal computer deployed on top, which increases the price of the platform. On the other

hand, the SRV-1 Blackfin, is the most expensive, but it has the best onboard processing

power, provides Linux 2.6 support and is the only one that comes with a camera. Never-

theless, the ability to add sensor extensions is limited, due to lack of available space. The

IdMind´s Circular GT is also very cost-effective; but it does not have hardware to enable

communication between robots, being less appropriate for experimentation with teams of

robots. As for the K-Team Hemmisson, its downside is maximum run time (energy auton-

omy). The Mindstorm NXT, Circular GT and One C are ideal platforms for beginners.

2.3. Summary 12

Note however that, in their present form, most of these robots are limited to very simple

tasks with unreliable odometry. Robots equipped with range sensors are more suitable

for tasks that require precise localization. Hence, the majority of these platforms would

need extensions to their sensing capabilities for more demanding tasks.

Motivated by many limitations on the state-of-the-art of low-cost robots and challenged

to accomplish better value for money, the TraxBot platform [APC+12] was developed

and integrated in ROS [QGC+09]. In this work, the key contributions are the develop-

ment and description of a driver that enables fast prototyping through the interface and

control of the platform using ROS; and the verification of cooperative behaviors with real

multi-robot systems, but also mixed real and virtual robotic teams.

After conducting a comparative analysis of several platforms of mobile robotics, chapter

3 will present in detail the platform TraxBot that was used in this work.

Chapter 3

The TraxBot platform

The TraxBot is ideal for education and research, since it can provide basics required

for autonomous robot development, both at the hardware level (mechanics, energy, loco-

motion, embedded electronics, sensors) and software level (control theory, microcontroller

programming, robot navigation trajectory planning, localization, etc). The setting up, de-

velopment and programming of the robot was motivated by experimentation and research

in cooperative multi-robot systems, more specifically teams of robots with distributed con-

trol to perform cooperative patrolling [PR11] and swarm foraging [CRF11] tasks.

In this chapter, the mobile platform is presented in detail. Such platform has been essen-

tially chosen due to the following reasons:

- Robustness: All hardware is either aluminum or stainless steel;

- Low Cost: The platform costs around 485€ (not considering the notebook);

Figure 3.1: TraxBot dimensions.

14

3.1. Hardware 15

- Operability: It has the ability to maneuver in many different types of terrain and

surface topographies. Since it is a tracked mobile robot (TMR), it provides adequate

mobility in unstructured environments;

- Run Time: It can operate continuously around 2-3 hours – robots should have a long

battery life since they may have to operate for a long time during a mission;

- Sensor System: Equipped with ultrasonic range sensor to allow interaction with the

environment;

- Size: It is adequate for both indoor and outdoor experiments. Its detailed dimensions

are illustrated in Fig. 3.1;

- Flexibility: It can incorporate many new extensions and components (e.g., LEDs,

cameras, LIDARs, grippers, etc.);

- Hybrid design: It is able to work with and without a small netbook on top of the

platform according to the user’s computational power requirements;

- Communication: Supports wireless ZigBee communication or Wireless 802.11b/g

communication when the notebook is used;

- ROS-enabled: Ability to use ROS related tools with the robot.

Considering the lack of flexibility and the weaknesses of other compact mobile robots

presented in chapter 2, especially in terms of communication, sensing capabilities and

processing, our research group developed this robot with low cost and open source tools.

The TraxBot is ideal for multi-robot applications, thus covering all the requirements pre-

viously addressed. The next section presents the main properties and features of the

robot.

3.1 Hardware

The TraxBot is a tracked mobile robotic platform, which has a differential drive system

built upon the Traxster II Robot educational Kit extended with substantial components

and improvements [TRK11]. The light and robust aluminum chassis is equipped with 2

DC gearhead motors on the front wheels, with quadrature wheel encoders of 624 pulses

resolution. Motors operate at 7.2 Volts, being able to reach 160rpm with 7.2 kg-cm of

torque with no load. Since the original kit is endowed with ABS injection molded plastic

3.1. Hardware 16

Figure 3.2: Mechanical structure of the TraxBot.

Figure 3.3: TraxBot’s main schematic.

3.2. Assembly 17

Table 3.1: TraxBot hardware specifications.

tracks, additional rubber bands were attached to the tracks to increase friction and reduce

slipping during locomotion. It was also added a flat acrylic structure on the top of the

platform to support a 10” notebook and the three ultrasonic range sonars, as presented in

Fig. 3.2. The processing and control units are the Arduino Uno with xBee shield module

and the motor drive OMNI-3MD [BRO11], which were placed inside the Traxbot chassis.

The battery pack is deployed under the TraxBot and held together by two strips of velcro

on the outside for easy access and replacement. The circuit switch power is located in the

shield’s rear. Table 3.1 presents some hardware specifications. The TraxBot presents itself

as a robotic platform ideal for robotics education, since it is based on the Arduino open-

source platform board and presents an easy-to-use communication interface, enabling the

easy data exchange between multiple robots or between the robot and a remote unit.

3.2 Assembly

This section describes the assembly of the components inside the platform and the control

architecture. An outline of the electronics of the TraxBot platform is presented in Fig. 3.3.

The Arduino Uno board [Ard10], the Bot’n Roll OMNI-3MD driver and the DC motors

are located inside the robot shield, while the Maxbotix MB1300 sonar range finders are

placed under the acrylic support in a configurable layout. Having the Arduino Uno board

as the central component of the system, the sonar range finders connect through the

analog pins A0, A1 and A2. As for the connection to the OMNI-3MD motor driver, the

3.3. Processing and Motion Controller units 18

pins A4 and A5 are used for I2C connection respectively. Channels A and B of each

motor’s encoders are connected to the OMNI-3MD board through the white and green

wires, respectively. The Universal Serial Bus (USB) jack on the microcontroller connects

to the notebook, which is used to receive (RX) and transmit (TX) TTL serial data decoded

using a USB-to-TTL Serial chip incorporated on the Arduino board.

3.3 Processing and Motion Controller units

The processing unit consists of an 8 bit microcontroller (µC) ATmega 328p from At-

mel (in the middle of Fig. 3.3), embedded in an Arduino Uno open-source development

board [Ard10]. This is ideal for compact robots, allowing the optimization of space and

power consumption. A single integrated circuit (IC) has the 3 main components of the

architecture: central processing unit (CPU), memory and input/output (I/O). The CPU

runs at 16 MHz and provides 14 MIPS of peak processing power, it also has 14 I/O digital

pins (6 of them can be used as PWM analog outputs) and 6 analog inputs, up to 32kB of

program memory and 2kB of SRAM. The ATmega8U2 embedded in Arduino Uno board

creates a serial communication over USB to virtualize a COM port, that can be used by

the external computer.

The µC deals with data received from sensors, sends control signals to actuators and

sends information to computers or others devices. Furthermore, it offers advantages over

higher processing systems, such as low-cost and lower power consumption. Additionally,

Arduino has an open-source cross-platform development environment (i.e., runs on Win-

dows, Macintosh OSX and Linux) with extensible software and hardware characteristics,

i.e., the language can be expanded through C libraries (as we shall see in the ROS Driver,

chapter 4) and shields can be plugged on top of the Arduino board, thus extending its

capabilities. In our case a ZigBee shield module was added (see communication section

3.5).

Atmega 328p, as many other µCs, may offer limited flexibility due to its inherent hard-

ware limitations when compared with other processing systems (e.g., embedded PCs).

Still they are the best choice when creating simple electronic devices that will not change

much over time (e.g., swarm robots). In order to overtake these limitations, when re-

3.3. Processing and Motion Controller units 19

Figure 3.4: OMNI-3MD I2C protocol frame.

quired, we use a small and cheap 10” notebook, for external processing, the ASUS eeePC

1001PXD BLACK N455, with an Intel Atom processor at 1.66GHz. It provides a hybrid

design and enables the robot to perform a large variety of tasks, ranging from simple to

computationally expensive tasks. If more computing power is needed, it is possible to use

multiple machines (CPUs), to reduce the computation load on a single computer.

In this work, the ATmega 328p µC controls the platform’s motion through the use of

the Bot’n Roll OMNI-3MD board [BRO11] (right side of Fig. 3.3). It has an embedded

dsPIC30F6010 µC from Microchip and its CPU provides 30MIPS with a 16 bit processor.

It has 144kB of program memory and up to 8kB of RAM memory. This driver has the

ability to control three motors in omnidirectional platforms by sending linear velocity,

direction and speed commands, performing both velocity and position control. In our

case, we use only 2 motors for differential drive. In terms of tension range, motors oper-

ate between 7 and 24 VDC. As for current intensity, the driver supports up to 4A. This

driver also features thermic protection to avoid extreme overheat on the driver board,

mainly caused by the DC power amplifiers (Choppers); and current overhead is protected

with self-resettable fuse. On monitoring issues, it is possible to access motor tension for

each motor, firmware version, as well as board temperature. Furthermore, the OMNI-

3MD board has the flexibility to provide direct number of pulses from encoders, which

can be set with a desire prescaler. For controlling the motors the board provides a closed

loop PID, which is extremely functional. It takes into account the platform configuration,

which is designed to operate in different surfaces and terrains, and support variable load

on top of it.

For Serial Data Connection and Serial Clock Connection, the I2C BUS works with data

exchange rate up to 100 kbit/s in the standard-mode or up to 400 kbit/s in the fast-mode.

For I2C data exchange, a frame with 3 segments is used for address, command and data

(Fig. 3.4). Firstly, the 8bit segment contains the I2C address where the most significant

bit selects write or read mode. The next segment is the specific list of operations com-

mands, and the last segment frames are the data for parameters commands.

3.4. Sonars and Odometry 20

Figure 3.5: Control architecture of the robotic platform.

For protection, if the I2C connection exceeds a greater timeout, the driver automatically

interrupts motors movements. Having specified the hardware and the platform electronics,

the modular control architecture of the robot is summarized in Fig. 3.5.

3.4 Sonars and Odometry

For range sensing, the TraxBot uses 3 ultrasonic range sonars, more precisely 3 LV-

MaxSonar MB1300 from Maxbotix [MBX05] (left side of Fig. 3.3), with a dead zone of

15 cm, maximum range of approximately 6.45 m, resolution of 2.45 cm, and a configurable

layout. It is possible to use up to 4 sonars in one platform through the available analog

ports of the Arduino Uno board.

These ultrasonic sonars send out a pulse of sound and wait to receive the sound´s echo

off of an obstacle. By measuring how long it takes for the sound to bounce back, the µC

embedded on the sonar board calculates the distance that the sound traveled, and hence,

how far the obstacle is. However, this originates an issue of different sonars “hearing” echos

from the other sonars, which results in faulty detections. Hence, to avoid this crosstalk

3.4. Sonars and Odometry 21

Figure 3.6: Sonars chain connection.

Figure 3.7: Encoder signals.

phenomenon, a chain loop was created to synchronize cadence values from individual

sonars, as shown in Fig. 3.6.

The two DC motors have a quadrature encoder incorporated, with 624 pulses per output

shaft revolution, used to sense position, as well as wheel direction and rotation speed

by converting displacement into digital pulses. Consisting of a disk with coded patterns

of opaque and transparent sectors that is attached to a rotating shaft, the quadrature

encoder converts rotating patterns into two pulse output signals, A and B (Fig. 3.7).

When counted, these pulses determine position. The phase difference between output

signal A and output signal B determines the direction of rotation. For example, if pulse

output A leads pulse output B, the shaft is rotating in the clockwise direction. Conversely,

if pulse output B leads pulse output A, the shaft is rotating in the counter-clockwise

direction [DT06].

3.5. Communication 22

Figure 3.8: XBee Module.

3.5 Communication

TraxBot provides wireless communication, which is fundamental for robot teams. ZigBee

communication is embedded in the TraxBot and Wi-Fi 802.11 b/g/n wireless technology

is also available when using a notebook on top of it.

ZigBee is used for exchanging short messages between robots when operating without a

notebook and running simple coordination algorithms, whereas the Wi-Fi supports larger

bandwidth with heavy data exchange and easy integration in a ROS network (chapter 4).

ZigBee technology provides fast, low-cost wireless communication, featuring low-power

consumption, possibility to support a huge number of networks nodes (theoretically up to

65536) as well as to set point-to-point, peer-to-peer, and multicast communication suit-

able for cooperative robot teams.

In this work, TraxBot is equipped with a XBee Shield [XBM06] from Maxstream, consist-

ing on a ZigBee communication module with an antenna attached on top of the Arduino

Uno board as an expansion module (Fig. 3.8), operating on the ZigBee protocol at stan-

dard IEEE 802.15.4 and using 2.4 GHz ISM band. This Xbee module is powered at 1mW

having a range between 30m to 100m, for indoor and outdoor operation, respectively.

The power consumption of this module is extremely low: 10µA in sleep mode and 50mA

while sending and receiving data. The advantage of being an expansion of Arduino is the

possibility of easily integrating wireless data exchange in the main source code [CFL+12].

The notebook provides communication via Wireless Wi-Fi 802.11 b/g/n to the robot and

is dedicated to run ROS onboard, as previously referred. Wi-Fi is used for remote access

and to enable a ROS network to run and share information.

3.6. Batteries 23

Figure 3.9: Comparison of capacity and power of rechargeable batteries [Roo10].

3.6 Batteries

In order to choose appropriate batteries, several considerations were made, like capacity,

energy density, power, number of cycles, available sizes, recycling requirements and cost.

In Fig. 3.9, the specific energy that represents the capacity that a battery can hold in

watt-hours per kilogram (Wh/kg) and the battery’s ability to deliver power in watts per

kilogram [Roo10]. The battery type chosen in this project was the Ni-MH batteries, due

to the balance between its performance and cost.

Therefore, two packs of 12V 2300mAh Ni-MH batteries, constituted by 8 AA Ni-MH cells,

were placed under the chassis of each robot to ensure good autonomy and the required

power. Note that the notebook operates on its own battery without consuming TraxBot

batteries.

3.7 Kinematics

TraxBot is a differential nonholonomic drive robot (Fig 3.10), with two motors indepen-

dently controlled from each other. This tracked configuration provides a better stability

and traction, thus allowing to perform a wider range of tasks in different surfaces when

compared to wheeled robots. On the other hand, the tracked locomotion system presents

a slipping effect that needs to be overcome. Hence, in order to control the TraxBot more

effectively, the slipping phenomenon was minimized by considering a slip offset. Slip needs

to be defined in the rotation case (3.1). The offset (Cs) was determined on a smooth car-

3.7. Kinematics 24

d

Rr

Rw

Figure 3.10: TraxBot kinematics.

pet, for suitable and stable rotation.

Taking into account the wheel radius Rw = 39mm and the robot radius Rr = 102mm;

the combination between encoders and wheel provides Np = 624pulses/revolution, where

each pulse corresponds to a resolution of approximately 0.004 degrees.1

Rotation:

Dr = −Dl = (Dl + Cs)θ

2πRr

Rw

, (3.1)

Straight Motion:

Dr = Dl + Cm = Npd

2π.Rw

+ Cm, (3.2)

where the total odometry is represented in spatial coordinates (x, y, θ),

xn = xn−1 + d. cos θ

yn = yn−1 + d. sin θ(3.3)

Although the motors model is exactly the same, their behavior is slightly different. It is

not possible to ensure that applying the same voltage on both motors will result in the

same speed. Therefore, it is necessary to compensate one of the motors (Cm) to obtain a

straight motion (3.2).

Given the previous information, it is possible to obtain a resolution of 0.39 mm for each

pulse.

1see Notation section.

3.8. TraxBot cost 25

Table 3.2: Traxbot total cost in euros.

3.8 TraxBot cost

The fully-assembled platform presents the following final cost, shown in table 3.2.

Given all its capabilities, TraxBot achieves great value for money when compared to pre-

viously described low-cost compact robots. It also provides the flexibility to incorporate

many more expansions ranging from simple sensors like LEDs, microphone and displays;

as well as more complex ones like LRFs and Kinect among others, which is not a common

option in other available robots. In addition, it uses recognized open-source tools like the

Arduino board and ROS for controlling the robot, as it will be seen in the next section.

3.9 Summary

In brief, the TraxBot was fully described, thus presenting the features and architecture

design, the kinematics model, and the final cost of the platform. Next chapter describes

the integration of TraxBot platform in ROS starting with a general overview of ROS

(Robot Operating System).

Chapter 4

TraxBot ROS Driver

In this chapter, the driver to integrate the TraxBot on ROS (Robot Operating System) is

presented and detailed description of the two distinct driver versions is done. Finally, at

the end of this chapter several features and potential applications of the TraxBot in ROS

are presented.

4.1 ROS

The required code to develop real robotic applications can be daunting, as it must con-

tain a deep stack starting from driver-level software and continuing up through perception,

abstract reasoning, and beyond. Robotics software architectures must also support large-

scale software integration efforts. In the past, many robotic researchers solved some of

those issues presenting a wide variety of frameworks to manage complexity and facilitate

rapid prototyping of software for experiments, thus resulting in the many robotic soft-

ware systems currently used in academia and industry. Those frameworks were designed

in response to perceived weaknesses of other available frameworks or to place emphasis

on aspects which were seen as most important in the design process. ROS [QGC+09] is

the product of tradeoffs and prioritizations made during this process.

ROS (Robot Operating System) is a meta operating system for robotics that provides

libraries and tools to help software developers to quickly and easily create robotic appli-

cations. ROS [QGC+09] is completely open source (BSD) and free to use, change and

commercialize solutions based on it. It is noteworthy that this operating system is not

26

4.1. ROS 27

Node B1Node A1

Node B2

Stack B

Sensor Message

Node C1

Float Message

Range Message

Package 1

Stack A

Package 2

Node Bn

Package n

Int Message

PointCloud Message

Stack C

Package

Package

Type of messages exchanged in topics

TopicsSubscriber

TopicPublisher

Topic

Figure 4.1: ROS architecture example diagram.

a reinvented OS but an Unix-based OS. However, ROS is not an operating system in

the traditional sense of process management and scheduling, yet it provides a structured

communication layer above the host operating systems of a heterogeneous computing

cluster.

4.1.1 Overview

ROS has two levels of concepts: i) the file system level; and ii) the computation graph

level.

The file system level can be summarized as ROS resources files which are organized in

groups of packages, which are the main unit for organizing software in ROS. A package

may contain ROS runtime processes (nodes), a ROS-dependent library, datasets and / or

configuration files. Stacks are collections of packages that provide aggregate function-

ality, such as the well-known navigation stack from ROS community [NS12]. This stack

allows the 2D navigation that takes into consideration the information from odometry and

4.1. ROS 28

sensor streams, returning a target pose and output velocities that are sent to the mobile

platform, using for example, the Adaptive Monte Carlo Localization (AMCL) approach.

The computation graph level is the peer-to-peer network of ROS processes that pro-

cesses all the data together. The basic computation graph concepts of ROS are nodes,

Master, messages, services and topics, all of which provide data to the graph in different

ways. This concept can be summarized in Fig. 4.1.

The ROS Master provides the name registration and lookup to the rest of the compu-

tation graph. Without the Master, nodes would be unable to find each other, exchange

messages, or invoke services. In Fig. 4.1, it is possible to see nodes, which are processes

that perform some computation. ROS is designed to be modular at a fine-grained scale;

a robot control system usually comprises many nodes. For instance, one node controls

a laser range-finder, one node controls the wheel motors, one node performs localization,

one node performs path planning, one node provides a graphical view of the system, and

so on. A ROS node is written with the use of a ROS client library, such as roscpp for

libraries in C++ or rospy for libraries in Python. Nodes send out a message by publish-

ing or subscribing it to a given topic. The topic is a name that is used to identify the

content of the message. Hence, a node that requires a certain kind of data subscribes

to the appropriate topic. There may be multiple concurrent publishers and subscribers

for a single topic, and a single node may publish and/or subscribe to multiple topics. In

general, publishers and subscribers are not aware of each other’s existence. The idea

is to decouple the production of information from its consumption. In other words, one

can think of a topic as a strongly typed message bus. Each bus has a name, and anyone

can connect to the bus to send or receive messages as long as they are of the right type.

Finally, nodes communicate with each other by passing messages via topics. A message

is simply a data structure, comprising typed fields. Standard primitive types (integer,

floating point, boolean, etc.) are supported, as are arrays of primitive types. Messages

can include arbitrarily nested structures and arrays (much like C structs) and users are

able to create custom messages for their applications [RC12].

4.2. ROS driver development for TraxBot 29

4.1.2 Gold marks

ROS is designed to be as “thin” as possible. A corollary to this is that ROS has already in-

tegrated some functionalities of OpenRAVE [DK08], Orocos [Bru01], and Player [GVH03].

The preferred development model is to write ROS-agnostic libraries with clean functional

interfaces. In terms of availed languages, besides C++ and Python, other libraries are

being developed for Octave, LISP, java and Lua, making ROS a language-independent

framework.

ROS is easy to test since it is endowed with a builtin unit/integration test framework

called rostest that makes it easy to bring up and tear down test fixtures. In terms of scal-

ing, ROS is appropriate for large runtime systems and for large development processes.

Another key feature of ROS are the tools available for robotics, as stage simulation, nav-

igation, framework for visual SLAM, 3D point cloud based object recognition system,

among others.

4.2 ROS driver development for TraxBot

After assembling the robot, a driver for the TraxBot robot was developed for integration

and control of the platform using ROS Electric Emys version [REE12] running on Ubuntu

11.04 “Natty Narwhal”. To develop the ROS driver, some pre-existent stacks available in

the ROS community were used, being the most relevant for this work the rosserial [RS12]

and the serial_communication [SCS11]. Both stacks have the liability to make the poin-

to-point serial communication between the Arduino and the PC / ROS side. As we will

see in the next subsections, two drivers were developed. The first one is based on rosserial

stack where some limitations were subsequently found. This version became less efficient

for more complex tasks due to the high overhead imposed by the data acquisition and

commands sent by rosserial, thus resulting in an overflow of the Arduino microcontroller

Atmel 328p SRAM. These problems and limitations of the critical driver of the first version

are presented in Section 5.5.

To overcome such weaknesses, it was necessary to develop a second version of the driver.

This second driver was based on serial_communication being more robust and fast for

more complex applications, such as teleoperation, crossing of sensory information, the


Figure 4.2: ROS driver architecture diagram.

integration of the stack robot navigation, among others.

4.2.1 Driver - version 1

For this first version, the rosserial stack [RS12] was adopted to establish point-to-point

serial communication, making use of a general protocol to exchange ROS messages with

the Arduino Uno. The rosserial stack has been used by the ROS community, being open

source and prone to further improvements. This stack has specific client libraries that

can be used in the microcontroller main source code. Such libraries allow users to easily

start ROS nodes by using the ROS server installed in the CPU and rosserial is then used

to set up the connection protocol on the TraxBot driver.

The power motor driver OMNI-3MD provides Arduino libraries to control the motors

(i.e., velocity or position control), read encoders and temperature, as well as setting the

parameters for the initial configurations of the PID controller, among others. The motor

driver is connected to the Arduino Uno through I2C communication. ROS topics and

nodes must be provided by the TraxBot driver.1

1available for all ROS community at: http://www.ros.org/wiki/mrl_robots


Figure 4.3: Rxgraph topics and nodes provided by the TraxBot driver.

Algorithm 4.1 takes into account all the components and their features, which are required

for the robot operation. The remaining architecture of the ROS driver is depicted in Fig.

4.2. All callback functions rely on activation topics for the read commands, avoiding

messages overflow with unnecessary information. For instance, the function to stop the

motors is always available as an external interruption.

C/C++ language was used as the programming language for the ATmega328p microcon-

troller, combined with ROS client and OMNI-3MD libraries. Algorithm 4.1 illustrates the

resident high-level code of the TraxBot firmware, running on the Arduino Uno board, as

shown in Fig 4.2. Note that ROS provides many different built-in sensor message types

which are appropriately assigned to the topics of each component of the TraxBot driver.

The ROS server runs in the notebook, and the connection node from the rosserial stack

allows starting the communication with the TraxBot, providing the available topics to

subscribe and publish.

One of many ROS tools, rxgraph, is used to allow real time monitoring of the available

nodes, as well as the topics connecting different nodes. In Fig. 4.3, a ROS computation

graph is presented, where the TraxBot driver is connected to TraxBot_DriverTest - a

program developed to test every topic/feature of the platform. The TraxBot_DriverTest

node verifies all functionalities implemented in the TraxBot, subscribing to every topic


Algorithm 4.1 TraxBot resident firmware version 1, running in the Arduino Uno board.

published by the TraxBot driver, testing the firmware and the motion of the robot by

sending velocity commands; and continuously reading odometry updates provided by the

encoders.

4.2.2 Driver - version 2

It was necessary to develop a second driver in order to overcome the critical limitations

of the first driver, described before in section 4.2. In this new version, the package

cereal_port [CPP11] from the serial_communication stack [SCS11] developed in the Em-

bedded Systems Lab at ISR, was used. This stack follows the same approach of rosserial

used in the first version of the driver, allowing the point-to-point connection through

serial communication. This package has the versatility of creating a specific protocol to

exchange data between the Arduino and the PC / ROS side. Consequently, this allows

creating a much more customized, transparent and faster communication than the one


Figure 4.4: Frame protocol.

originally implemented in the first version.

The protocol developed for the second version of the driver consists on sending a frame

with a specific configuration, as shown in Fig. 4.4. A specific character ‘@’ is used to start

the protocolled frame and commas ‘,’ separate the different parameters. The character

‘e’ is used to identify the end of the frame.

Regarding the content of the protocol, the first parameter corresponds to the action

command. For instance, move motors, encoders read, read sonar, PID definition, and

others (Algorithm 4.2). After the action command, it follows the arguments of the de-

sired functions. For instance, let us suppose that we want the platform to move for-

ward at 40% of its maximum speed, the frame would be, “@9,1,40,1,40e” representing

“@command,direction_motor1,speed_motor1,direction_motor2,speed_motor2e”.

As opposed to the first version, this new version allows to stream data (Algorithm 4.2).

This results in fewer requests, freeing the channel of communication. Another option of

this new driver is the ability to enable and disable a debug option.

Fig. 4.5 presents the driver architecture and compares it to the first version, depict-

ing the changes in red and what was unchanged in green. The most significant changes

were carried out in the TraxBot platform (i.e., Arduino firmware), where the algorithm

was implemented due to the communication protocol mentioned above. In the PC /

ROS side, changes mainly consist on using the functions from the communication stack

serial_communication instead of the rosserial stack. Another relevant change was the up-

grade of the "Driver Source Code" which allows interpreting the messages and publishing

or subscribing the relevant information in ROS. That information is then used by other

nodes as Fig. 4.5 depicts, e.g. "TraxBot Source Code". However, the main difference

between the two versions consists on how the ROS topics are published. From the rosse-

rial point of view, libraries are added to the Arduino source code, in order to emulate

ROS language directly in Arduino code. This results in high overhead in communication

between PC / ROS and the Arduino, due to the structures used for example to publish

messages from the Arduino side. On the other hand, using the serial_communication


Algorithm 4.2 TraxBot Resident Firmware version 2, running in the Arduino Uno board.


ROS Driver

Connection node

TraxBot Source CodeCereal_port node establish I2C

communication via serial protocol and Driver source

code Interprets the frame sent by the firmware program to

perform the desired task.

Driver Source Code

USB cable connection

Firmware Implemented in C with specific

protocol frame

Motor Driver Power driver to control motors,

Encoders and temperature among others.

I2C

Figure 4.5: ROS driver architecture diagram - version 2. Comparison with the firstdriver (Fig. 4.2), depicting the changes in red and what was unchangedin green.

stack, the messages sent from the Arduino only consist of arrays of characters, which are

parsed to integer variables on the PC / ROS side, decreasing the communication load, as

it will be seen later on the results section 5.5.

The next chapter presents some performance evaluation of the two drivers.

4.2.3 Driver Features and Potential

The drivers previously presented offers several features, many of which are inherited by

the direct integration with ROS middleware. These drivers enable the interface with

ROS tools for data processing and analysis of the TraxBot platform, like 3D visualiza-

tion (rviz), logging real-time robot experiments and playing them offline (rosbag / rxbag),

plotting data (rxplot) and visualize the entire ROS network structure (rxgraph). Beyond

the easiness of using the available tools, ROS also provides effortlessly integration of new

sensors without needing hardware expertise. For instance, the addition of tele-operating

devices like the wiimote to take advantage of its internal accelerometers [SR09], sensors,

such as laser range finders, Xbox Kinect, global positioning system devices (e.g., GPS),

electronic compasses, accelerometers, gyroscopes, among others, can be accomplished by


Figure 4.6: Network topology example with multiple robots, sensors, teleoperationdevices and applications.

directly integrating their ROS drivers into the network. This opens a new range of pos-

sibilities since several well-known stacks from the ROS community comprises algorithms

for robotics development such as the navigation and slam_gmapping stacks. These are

useful since they avoid programming low-level behaviors by reusing code, and shift the

focus to scientific issues. As a result, the overall time spent in robotics research is greatly

reduced and, therefore, the driver represents a valuable tool that enables fast prototyping

and opens a gateway into the world of ROS.

The interaction between high-level programs and the available resources in the TraxBot

platform allows the hardware abstraction and the possibility of using standard interfaces

of any mobile robotic platform integrated with ROS architecture.

Another interesting feature of the TraxBot driver is the simplicity for enabling multi-

robot coordination and cooperation. Running the same hardware abstraction layer in all

nodes of the robotic team, ROS takes care of the communication messaging system using

a publish / subscribe mechanism [GM02] which enables all kinds of interaction between

members of the same team. Not only multiple robots are able to cooperate with each


other, in heterogeneous networks, through Wi-Fi, ZigBee or Bluetooth by exchanging

messages in common topics of the ROS global network, but they can also be equipped

with distinct sensors.

In Fig. 4.6, an example of a ROS network is depicted. It is also shown how the network

has the flexibility to work with a large variety of integrated solutions, which enables the

assignment of particular tasks for specific members of the team. Robots of the same team

may have different purposes and perform different tasks, thus meaning that heterogeneous

teams with different capabilities can coexist. For example, in a search and rescue sce-

nario, the cooperation of a multi-robot team may arise from performing different tasks

with hundreds or thousands of heterogeneous robots. In a scenario where a swarm of air

scouts are deployed, these scouts may search and mark objective points to pass them on,

in real time, to ground robot surveillance teams.

Not only ROS have the potential to integrate homogenous and heterogeneous robotic

teams, but it also allows the cooperation between mixed real and virtual robot teams.

With the herein presented driver, the same code can be used to drive both real robots

and virtual simulated agents running on Stage or Gazebo [SVE11].

Therefore, the TraxBot driver allows the hybrid integration of different mobile platforms,

as well as virtual robots with different sizes and driving characteristics, as it will be seen

in the results section. In addition, the communication between real and virtual agents

is completely transparent since they are both operating in ROS middleware. This ma-

jor feature is ideal to perform multi-robot tasks, allowing the use of a large population of

robots when no extra physical robots are available, being cheaper and promoting safer test

scenarios by making interactions between physical and virtual world objects [WCM09].

Multi-robot simulation is available for ROS through a Stage wrapper [SS12], which sup-

ports a high number of interacting robots depending on the computational complexity

of the algorithm. However, the opportunity to execute nodes on multiple CPUs in the

same network turns the upper bound of the teamsize arbitrarily high, thus removing the

overloading processing of a single machine. Finally, another particularity of using this

ROS driver is a mean to improve security in multi-robot tasks, for example, in a mil-

itary operation, where it is possible to create a specific encrypted node for a robot of

the team [WA09], making the system more robust to attacks. Additionally, it is always

4.3. Summary 38

possible to monitor, log and debug at any time all exchanged information and specific

nodes running in the network.

4.3 Summary

This chapter presented a general overview of ROS (Robot Operating System), as well as a

full description of the two developed drivers. Further more, the potentialities and features

of the ROS drivers have been discussed. Chapter 5 presents the experimental results to

evaluate both the TraxBot platform and the ROS drivers.

Chapter 5

Results and Discussion

In order to experimentally evaluate the herein proposed platform, as well as the ROS

drivers, some experiments were conducted on a laboratory scenario, using both real and

virtual TraxBot platforms using stageros [SS12], which provides essential options like the

information about the ground truth pose and the odometry of virtual robots. These

robots are controlled with velocity commands. Other tests were performed to evaluate

the sensing system and the platform autonomy.

Firstly, the odometry of the robot is analyzed. This is followed by an accuracy analysis

of the sensing information provided by two lateral ultrasonic sonars mounted on top of

the robot, which are compared with a range laser sensor. Subsequently, an analysis of the

robot’s power consumption is done.

A more complex experiment with three sonars mounted on top of the robot is conducted to

address obstacle avoidance performance, as well as interaction between real and simulated

robots, tele-operation test was also performed to validate de potentialities of the ROS

driver and the flexibility to integrate several control devices. Finally, the communication

delays between the modules of the system were analyzed for both drivers.

5.1 Odometry

To evaluate the TraxBot odometry, a square trajectory with one-meter of side length was

performed, in both clockwise (CW) and counter-clockwise (CCW) directions. This test is

extremely challenging due to the fact that the robot always turns in the same direction,

40

5.2. Sensing and Mapping 41

Figure 5.1: Odometry square test evaluation.a) Clockwise (CW) direction b) Counter-clockwise (CCW)

direction.

thus accumulating dead reckoning errors without compensation in the opposite direction.

Fig. 5.1 depicts the trajectories performed by the platform during the experiments. The

trajectories illustrated were collected using an overhead camera mounted on top of the

scenario. The tests were performed relying on the odometry system of the robot and

without the assistance of any external sensor or global localization system. The robot

performs movements in straight line with high accuracy. However, as expected, it exhibits

significant errors when rotating 90°.

Moreover, as the platform rotates, the odometry error increases due to a minor slipping

effect. Nevertheless, the accumulative error in the end of each test, after one lap, is

reduced. In the trial in CCW direction the robot ends with a positional error to its initial

position of 9.67cm and an angular error of -4.93°, while in the CW direction the positional

error is of 7.71 cm and the angular error of +2.13°.

5.2 Sensing and Mapping

In order to convert to centimeters the analog output values given by the sonar readings,

a calibration phase was initially conducted by measuring sonar readings in a straight line

at a distance to a wall between 5 to 200 cm, with an increment of 5 cm. The data was

collected and a curve fitting method by means of a power function f(x) = a.xb + c was

used, converting the analog values to centimeters, as shown in Fig. 5.2. The calibration

5.2. Sensing and Mapping 42

Figure 5.2: Sonar calibration.

function obtained, with the sensor readings (s) as input, was:

f(s) = 1, 1767s0,94657 − 0, 3759

with R2 : 0, 9992.

Note that R2 (or R-square) is a fraction between 0.0 and 1.0, which has no units and

quantifies goodness of fit. Higher values indicate that the model fits the data better

[PR12].

The TraxBot platform was temporarily equipped with a laser range finder (LFR) to

compare its performance against the native ultrasonic range sonars on a mapping task

[RDC05] and to show the flexibility of integrating new sensors in the robot by means of

ROS driver. The Hokuyo URG-04LX is a LRF classified as an Amplitude Modulated

Continuous Wave (AMCW) sensor [KTC+09]. The laser emits an infrared beam and a

rotating mirror changes the beam’s direction. The rotating mirror sweeps the laser beam

horizontally over a range of 240°, with an angular resolution of 0.36°. As the mirror

rotates at about 600 rpm, the scan rate is about 100 msec. The LRF has a quoted range

between 20 and 4095 mm. The quoted measurement error is ±10 mm for distances of less

than 1 m. For greater distances, the error is quoted as ±2%.

In order to test the sonars performance, a scenario with 2 m by 1.6 m in L shape was built,

with a constant width of 1 m and 0.5 m of height (Fig. 5.3). To perform this test, only

two lateral sonars placed at 45 degrees were used, since the goal of this test is to evaluate

the accuracy of sonars by mapping the scenario based on the combination of odometry

5.3. Power Consumption 43

Figure 5.3: Mapping test. a) Sonars b) Laser.

information and sonars readings. The front sonar is usually used for reactive avoidance of

obstacles, given that in mapping situations the projection of walls and obstacles detected

by the cone of the sonar will always be placed in front of the robot, which is highly

unreliable in most situations, as shown for example in Fig. 5.4b. In this test, the robot

movement relies solely on odometry. In Fig. 5.3a it can be seen in the first rectilinear

motion, that the sonars readings are stable (red dots) and coincident with the ground

truth scenario limits (blue line). Green dots represent the midpoint of sonars acoustic

beam.

Some issues arise when there is a rotation of 90 degrees, because the sonar beam cone has

an opening of approximately 36 degrees, thus presenting a loss of resolution, as illustrated

in Fig. 5.4a. In the case of Fig. 5.3b, the Hokuyo range laser sensor was used to perform

the same test. The opening of the laser was set to 180 degrees with a rate of 512 samples

per reading. It is possible to observe some discrepancy in some readings especially at the

end of the movement due the odometry position error accumulated during motion.

This test shows the possibility of integrating more sensors in the TraxBot platform, by

adding, in this case, the hokuyo node in the ROS network.

5.3 Power Consumption

In order to analyze the TraxBot’s power consumption, non-stop circular trajectories stress

tests were performed, at different velocities: Firstly tested at low velocity of 50mm/s,

5.3. Power Consumption 44

Figure 5.4: Noisy range situations. a) Issue during rotations using lateral sonars b)This figure illustrates why the front sonar is not used for mapping.

Figure 5.5: Power consumption behavior.

5.4. ROS Driver Test 45

Figure 5.6: Driver Test. a) Real step test b) Stage simulation.

then at a regular velocity of 100mm/s and finally at a high velocity of 200mm/s. Fig.

5.5 demonstrates the remaining energy of batteries until they reach a minimum working

voltage of approximately 9 V, for the 3 different velocities tested. As expected with the

variation of speeds, it is possible to observe in the figure that the running time decreases

as speed increases.

The results show that the robot is able to operate continuously for 2-3 hours, depending

on the speed profiles.

5.4 ROS Driver Test

5.4.1 Point-to-point Motion

A ROS driver test that consists in performing a step-like trajectory on a grid map of

400×400mm is shown in Fig. 5.6. In this “step test”, a standalone point-to-point navi-

gation algorithm was adopted, using x, y and theta position commands, retrieving data

from sonars and controlling the robot reactively. Two boxes with different dimensions

were added to the map as reference points. The main goal of the experiment is to test

the connectivity between distinct nodes of the network.

A network composed by two machines was used for distributing the processing load, re-

lieving the eeePC notebook, and replicating the experiment simultaneously in the Stage

simulator. ROS master (roscore) and stageros node ran in a desktop computer and the

eeePC was placed on top of TraxBot running the ROS driver (TraxBot_Driver) and the

algorithm node (TraxBot_DriverTest). As it may be observed in Fig. 5.7 (combined with


Figure 5.7: TraxBot teleoperation.

Figure 5.8: Driver Test. a) Two robots with reactive navigation b) Mixed real andvirtual robots.

Fig. 4.3), all nodes operate in the same network and communicate through publication

and subscription to topics. While doing the “step test”, the TraxBot updates the odome-

try topic in real-time, which is subscribed by the stage node, processing the messages and

replicating the moves in the virtual world using a virtual robot (on the desktop screen),

as shown in Fig. 5.6b. The delay of this whole process is less than one second.

5.4.2 Mixed virtual and real robots teams

In this experimental trial, two TraxBots were deployed in a bounded laboratory arena

running a reactive wandering algorithm as illustrated by Fig. 5.8a. This test was con-

ducted to verify the coordination between multiple robots. In this case, a mixed team of

real and virtual robots was used to demonstrate the ideas presented in section 4.2.3. The

two real TraxBots were replicated in Stage (Fig. 5.8b), and an extra virtual TraxBot,

with exactly the same reactive algorithm, was added. This can be seen as an interesting


Figure 5.9: TraxBot teleoperation devices.

feature for programmers, since with minor adjustments it is possible to use the same code

for either real or virtual robots. The blue beams in front of the robots correspond to real

scale range readings of 3 ultrasonic sonars installed in the TraxBot platform. All three

robots were able to coordinate themselves in the environment without colliding to each

other through reactive behavior, as shown in the video of the experiments.

5.4.3 Teleoperation

In this test, a node to teleoperate the TraxBot was developed. With teleoperation, one

can drive the robot using external remote control; e.g., a joystick or a keyboard. In the

case of a joystick like the wiimote or the PS3 controller (Fig. 5.9), since they operate via

a wireless technology; i.e., Bluetooth, the teleoperation node runs in the eeePC netbook,

which is an advantage over using the keyboard, given that this option assumes a static

operator controlling the robot, running the ROS teleoperation node in another computer,

which is connected over the ROS network with the eeePC netbook.

The teleoperation node subscribes to topics which have the information of the joystick

state and assigns functions for each pressed button, publishing then velocity commands,

which are interpreted by the TraxBot driver, resulting on motor commands. In the key-

board case, it is not necessary to subscribe to topics with the keyboard state, because the

teleoperation node uses standard C++ libraries to detect which keys are being pressed.

5.5. ROS Driver Limitations 48

Figure 5.10: StingBot. Figure 5.11: StingBot operatingwith ROS driver.

5.4.3.1 Adaptation of the ROS driver in different platform

In this test, the portability of the ROS driver to other platforms based on similar hard-

ware is demonstrated. The adaptations basically consist on specific adjustments of the

platforms, however the communication protocol is exactly the same, as well as the oper-

ation mode.

As an application example of the portability of this driver, a new differential platform was

used: the StingBot represented in Fig.5.10. This platform has a similar architecture to

the TraxBot, using an Arduino board as the processing unit and the OMNI-3MD driver

to control the motors. For test purposes, the driver was used in the StingBot robot with-

out any modification of the functions developed. From the motor drive side, the only

modification conducted was the assignment of the PID controller gains of the StingBot

motors, because this is a lighter and trackless platform, thus requiring gains of a much

smaller order.

To validate this test, the teleoperation node previously described was used to control the

robot with the same ROS driver (Fig. 5.11).

5.5 ROS Driver Limitations

5.5.1 Driver first version

In order to analyze the driver overhead, the turnaround time of messages exchanged

between the three layers of the system (the OMNI-3MD driver, the Arduino board and

5.5. ROS Driver Limitations 49

Figure 5.12: ROS driver messages turnaround time for the ROS driver - version 1.

ROS) was measured.

It can be seen in Fig. 5.12 that the total turnaround time, between the OMNI-3MDmotors

driver and ROS, increases with the number of messages, as expected. However, the values

measured are negligible when considering applications with real robots. For instance, the

average number of messages exchanged per second in the previous experimental trial is

20, which corresponds to a turnaround time of 36ms, a very residual delay which is not

critical when hard real-time constraints do not exist.

However, on the downside, it was also concluded that the Atmega328p microprocessor

used in the robot presents a limitation in terms of SRAM memory. When running the

driver, only 283 bytes of memory are available in the Arduino Uno, which means that for

standard topics (float 32 messages + topic headers), only 7 more topics can be added for

extensions and the message buffer is limited to 70 standard messages. This was the main

reason for migrating the publication of messages in topics to PC / ROS, in the second

version of the driver.

5.5.2 Driver second version

The same test was performed using the second version of the driver, exchanging float32 (4

bytes) messages. The time to pass a message between the PC / ROS side to the Arduino

was drastically decreased. Therefore, a global reduction of around 35% on the turnaround

time can be clearly observed when sending messages. In addition, the exchange capac-

ity bottleneck is in the communication between the Arduino and the Omni-3MD driver,

5.6. Summary 50

Figure 5.13: ROS driver messages turnaround time for the ROS driver - version 2.

therefore the frequency of messages should be set accordingly in the ROS side to avoid

buffer overflow.

Given the reduction of the turnaround time and overtaken the SRAM limitations of the

first version of the driver, the new version presents enhanced robustness and responsive-

ness, becoming highly superior for the desired applications.

5.6 Summary

In this chapter, results were presented and discussed. In the subsequent chapter, an

overview of objectives accomplished in this work and the associate publications are pre-

sented. Finally this dissertation ends with conclusions and future work.

Chapter 6

Conclusions

This dissertation presented the development and experimental evaluation of a compact

robotic platform and its integration in ROS by developing a firmware driver. The next

section states the contributions of this work.

6.1 Contributions

There are two key contributions of this work. First, the development of a low-cost plat-

form, denoted as TraxBot, suitable for reinforcing beginning programming concepts and

exploring algorithms of current interest to the robotics community. In addition, this plat-

form is also useful in the fields of multi-robot systems (MRS) since it is a cost-efficient

off-the-shelf solution. Secondly, two ROS drivers are presented that allows the full inte-

gration of the robotic platform within ROS middleware. The advantages of integrating

the platform with ROS middleware were demonstrated, enabling the usage of a wide range

of tools and reducing the development time through code reuse. Beyond providing access

to all ROS tools, the driver simplifies the robotic development by supporting hardware

abstraction to easily control the platform. Moreover, the driver also allows the extension

and integration of all kinds of sensors, and enables multi-robot cooperation and coor-

dination through the operation in a ROS network for real, virtual and hybrid teams of

homogeneous and heterogeneous robots, by running the same code. The results obtained

in the experiments demonstrate all of these features and the negligible overhead imposed

by the driver.

52

6.2. Future Work 53

6.1.1 Published Work

Regarding the first contribution of this work, a paper describing the assembling and

programming of the TraxBot was published in February 2012 in the 4th International

Conference on Agents and Artificial Intelligence (ICAART’2012) [APC+12] and another

one presenting a survey on small and middle-sized compact mobile robotic platforms

was published on the Automatics International Conference (FA’2012) [APC+12a] in June

2012. These works were mainly focused on presenting low-cost, open-source robots, as

well as the developed one, the TraxBot, to enable the ordinary consumer to enter the

robotics and artificial intelligence world, giving an innovative overview of compact mobile

robots used by academic researchers and by robot enthusiasts, and depicting their features,

prices, communications abilities, autonomy and dimensions, among others. Regarding the

second contribution of this work, i.e. the development of a ROS driver, a paper is being

prepared for submission on the 28th Symposium On Applied Computing (SAC’2013).

Also, in May of this year, an article presenting the work contained in this dissertation

was submited to the Robotica Journal on Cambridge, which is still waiting for review and

decision. All these papers are available as attachments and on the dissertation CD.

6.2 Future Work

In the future, a vast possibility of work is now possible: integrate ZigBee communication

directly through ROS, develop new drivers to accommodate different robots in the team

for heterogeneous experiments; integrate ROS navigation stack using an Hokuyo Laser;

integrate a Kinect sensor to endow the robot with the ability for visual SLAM; use an

android phone, together with the robot, to take advantages of its communication capabil-

ity, as well as its internal sensors (electronic compass, GPS, accelerometers, camera, light

sensor).

References and Bibliography

[APC+12] A. Araújo, D. Portugal, M. Couceiro, C. Figueiredo and R. P. Rocha.

TraxBot: Assembling and Programming of a Mobile Robotic Platform, in

Proceedings of the 4th International Conference on Agents and Artificial

Intelligence (ICAART’2012), Vilamoura, Algarve, Portugal, February 6-8,

2012.

[APC+12a] A. Araújo, D. Portugal, M. Couceiro, C. Figueiredo and R. P. Rocha. Small

and Compact Mobile Robots Surveying and Comparing Platforms, in Proceed-

ings of the 1st International Automatics Conference of the Technical Univer-

sity of Sofia (AUTOMATICS’2012), Sozopol, Bulgaria, June 1-4, 2012.

[BLM+10] M. Bonani, V. Longchamp, S. Magnenat, P. Rétornaz, D. Burnier, G. Roulet,

F. Vaussard, H. Bleuler and F. Mondada. The MarXbot, a Miniature Mobile

Robot Opening new Perspectives for the Collective-Robotic Research, in Int.

Conf. on Intelligent Robots and Systems, Oct. 18-22, 2010, Taipei, Taiwan,

2010.

[Ard10] Arduino Uno, 2010, http://arduino.cc/en/Main/ArduinoBoardUno Last

access: 03.07.2012

[BRO11] Manual Bot’n Roll OMNI-3MD, 2011, http://botnroll.com/omni3md/

downloads/Manual%20OMINI3-MD%2818-07-2011%29.pdf Last access:

03.07.2012

[Bru01] H. Bruyninckx, Open robot control software: the OROCOS project, in Pro-

ceedings of IEEE International Conference on Robotics and Automation

(ICRA’01), volume 3, pp. 2523–2528, 2001.54

http://arduino.cc/en/Main/ArduinoBoardUno

http://botnroll.com/omni3md/downloads/Manual%20OMINI3-MD%2818-07-2011%29.pdf

http://botnroll.com/omni3md/downloads/Manual%20OMINI3-MD%2818-07-2011%29.pdf


[MRT03] M. Montemerlo, N. Roy, S. Thrun, Perspectives on Standardization in Mobile

Robot Programming: The Carneggie Mellon Navigation (CARMEN) toolkit,

in Proceedings of the 2003 IEEE/RSJ International Conference on Intelligent

Robots and Systems (IROS’2003). Las Vegas, Nevada, October, 2003.

[CAS08] J. Cummins, M.Q. Azhar and E. Sklar. Using Surveyor SRV-1 Robots to Mo-

tivate CS1 Students, in Proceedings of the AAAI 2008 Artificial Intelligence

Education Colloquium, 2008.

[CFL+12] M. S. Couceiro, C. M. Figueiredo, J. M. A. Luz, N. M. F. Ferreira and R. P.

Rocha. A Low-Cost Educational Platform for Swarm Robotics, International

Journal of Robots, Education and Art, IJREA, Volume 2, Issue 1, February,

pp. 1-15, 2012.

[Col10] Colot, A.: K-Team Hemisson Manual, K-Team S.A., Yverdon-les-

Bains, Switzerland (2010), http://ftp.k-team.com/hemisson/Manuel_En/

Manual_Hemisson.pdf Last access: 03.07.2012

[CPP11] ceral_port Package. http://www.ros.org/wiki/cereal_port Last access:

03.07.2012

[CRF11] M. S. Couceiro, R. P. Rocha and N. M. Ferreira. A Novel Multi-Robot Explo-

ration Approach based on Particle Swarm Optimization Algorithms, in Proc.

of 9th IEEE Int. Symposium on Safety, Security, and Rescue Robotics (SSRR

2011), Kyoto, Japan, pp. 327-332, Nov. 1-5, 2011.

[DK08] R. Diankov and J. Kuffner, OpenRAVE: A Planning Architecture for Au-

tonomous Robotics, Robotics Institute, Tech. Rep. CMU-RI-TR- 08-34, July

2008.

[DT06] Data Translation Using Quadrature Encoders/ Decoders for X/Y Positioning

and Rotation, January, 2006.

[GM02] B. Gerkey and M. Mataric, Sold!: Auction Methods for Multirobot Coordi-

nation, in IEEE Transactions on Robotics and Automation, Special Issue on

Multi-robot Systems, 18(5):758-768, October, 2002.

http://ftp.k-team.com/hemisson/Manuel_En/Manual_Hemisson.pdf

http://ftp.k-team.com/hemisson/Manuel_En/Manual_Hemisson.pdf

http://www.ros.org/wiki/cereal_port


[GSB06] G. Grisetti, C. Stachniss and W. Burgard, Improved Techniques for Grid

Mapping with Rao-Blackwellized Particle Filters, in IEEE Transactions on

Robotics, 2006.

[GVH03] B. Gerkey, R. Vaughan and A. Howard, The Player/Stage Project: Tools for

Multi-Robot and Distributed Sensor Systems, in Proceeding of the Intl. Conf.

on Advanced Robotics (ICAR 2003), pp. 317-323, Coimbra, Portugal, July

2003.

[Idm05] IdMind, Engenharia de Sistemas, Lda: Manual de construção: Robô

Circular GT. Lisboa, Portugal 2005, http://aprobotica.com.sapo.pt/

ManualCircularGT.pdf

[Jac07] J. Jackson,Microsoft robotics studio: A technical introduction, in Proceedings

of the IEEE Robotics and Automation Magazine, Dec. 2007

[Jon06] J. L. Jones, Robots at the tipping point: the road to iRobot Roomba, in IEEE

Robotics & Automation Magazine, 13(1), 76-78, March, 2006.

[Kui09] M. Kuipers, Localization with the iRobot Create, in Proceedings of the 47th

Annual Southeast Regional Conference ACM (ACM-SE 47), Clemson, South

Carolina, USA, March 19-21, 2009.

[KTC+09] L. Kneip, F. Tâche, G. Caprari and R. Siegwart, Characterization of the

compact Hokuyo URG-04LX 2D laser range scanner, in Proceedings of the

IEEE International Conference on Robotics and Automation, Kobe, Japan,

May 12-17, 2009.

[MBF+10] E. Marder-Eppstein, E. Berger, T. Fully, B. Gerkey and K. Konolige, The

Office Marathon: Robust Navigation in an Indoor Office Environment, in Pro-

ceeding of the International Conference on Robotics and Automation (ICRA

2010), Anchorage, Alaska, May 2010.

[MBR+09] F. Mondada, M. Bonani, X. Raemy, J. Pugh, C. Cianci, A. Klaptocz, S.

Magnenat, J. C. Zufferey, D. Floreano and A. Martinoli. The e-puck, a Robot

http://aprobotica.com.sapo.pt/ManualCircularGT.pdf

http://aprobotica.com.sapo.pt/ManualCircularGT.pdf


Designed for Education in Engineering, in Proceedings of the 9th Conference

on Autonomous Robot Systems and Competitions, 1(1) pp. 59-65 2009.

[MBX05] MB1300 XL-MaxSonar®-AE0™ Datasheet (2005), http://www.maxbotix.

com/documents/MB1200-MB1300_Datasheet.pdf Last access: 03.07.2012

[MFN06] G. Metta, P. Fitzpatrick, L. Natale. Yarp: Yet another robot platform, in

Proceedings of International Journal on Advanced Robotics Systems 3 (1),

pp.43-48, 2006.

[Miz05] M. Mizukawa. Robot Technology (RT) Trend and Standardization, in Pro-

ceedings of the IEEE Workshop on Advanced Robotics and its Social Impacts

(ARSO’05), WAO-1-1, Nagoya, Japan, June 2005.

[NS12] navigation Stack. http://www.ros.org/wiki/navigation Last access:

03.07.2012

[Pet11] A. M. Petrina. Advances in Robotics, in Automatic Documentation and Math-

ematical Linguistics, Vol. 45, No. 2, pp. 43–57, Allerton Press, Inc. 2011.

[PR11] D. Portugal and R.P. Rocha. On the Performance and Scalability of Multi-

Robot Patrolling Algorithms, in Proceedings of the 2011 IEEE International

Symposium on Safety, Security, and Rescue Robotics (SSRR 2011), pp. 50-55,

Kyoto, Japan, November 1-5, 2011.

[PR12] D. Portugal and R.P. Rocha, Measuring Variables Effect to Statistically

Model the Multi-Robot Patrolling Problem by means of ANOVA, in Luis M.

Camarinha-Matos, Ehsan Shahamatnia, Gonçalo Nunes (editors), Techno-

logical Innovation for Value Creation, Vol. 372, pp. 199-206, Proc. of 3rd

Doctoral Conference on Computing, Electrical and Industrial Systems (Do-

CEIS 12), Costa da Caparica, Lisbon, Portugal, Springer Berlin Heidelberg,

Feb. 27-29, 2012.

[QGC+09] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs, E. Berger,

R. Wheeler, and A. Y. Ng,. ROS: an open-source Robot Operating System,

http://www.maxbotix.com/documents/MB1200-MB1300_Datasheet.pdf

http://www.maxbotix.com/documents/MB1200-MB1300_Datasheet.pdf

http://www.ros.org/wiki/navigation


in Proc. Open-Source Software workshop of the International Conference on

Robotics and Automation (ICRA 2009), Kobe, Japan, May, 2009.

[RC11] R. Rusu and S. Cousins. 3D is here: Point Cloud Library (PCL), in Proceed-

ing of International Conference on Robotics and Automation (ICRA 2011),

Shanghai, China, May 2011.

[RC12] ROS concepts. http://ros.org/wiki/ROS/Concepts Last access:

03.07.2012

[RDC05] R. Rocha, J. Dias and A. Carvalho. Cooperative Multi-Robot Systems: a Study

of Vision-based 3-D Mapping using Information Theory, in Proc. of IEEE Int.

Conf. on Robotics and Automation (ICRA’2005), Barcelona, Spain, pp. 386-

391, Apr. 18-22, 2005.

[REE12] ROS Electric Emys. http://ros.org/wiki/electric Last access:

03.07.2012

[Roo10] M. Root. The Tab Battery Book: An In-Depth Guide to Construction, De-

sign, and Use, McGraw-Hill/Tab Electronics, pp. 182, 2010.[ISBN: 978-

0071739900].

[Roo12] Roomba ROS driver http://www.ros.org/wiki/Robots/Roomba Last ac-

cess: 03.07.2012

[RS12] rosserial Stack. http://www.ros.org/wiki/rosserial Last access:

03.07.2012

[SAR10] SAR - Soluções de Automação e Robótica: Manual Bot’n Roll ONE

C. Guimarães, Portugal, 2010, http://botnroll.com/onec/downloads/

Manual%20Bot%27n%20Roll%20ONE%20C%20PT.pdf Last access: 03.07.2012

[SCS11] serial_communication Stack. http://www.ros.org/wiki/serial_

communication Last access: 03.07.2012

[Sha07] S. Sharad. Introducing Embedded Design Concepts to Freshmen and Sopho-

more Engineering Students with LEGO MINDSTORMS NXT, mse, pp.119-

http://ros.org/wiki/ROS/Concepts

http://ros.org/wiki/electric

http://www.ros.org/wiki/Robots/Roomba

http://www.ros.org/wiki/rosserial

http://botnroll.com/onec/downloads/Manual%20Bot%27n%20Roll%20ONE%20C%20PT.pdf

http://botnroll.com/onec/downloads/Manual%20Bot%27n%20Roll%20ONE%20C%20PT.pdf

http://www.ros.org/wiki/serial_communication

http://www.ros.org/wiki/serial_communication


120, IEEE International Conference on Microelectronic Systems Education

(MSE’07), 2007.

[SR09] A. J. Sousa, L. P. Reis. Using Accelerometers to Command a Cleaning Ser-

vice Robot, in Progress in Artificial Intelligence: Proceedings of the 14th Por-

tuguese Conference on Artificial Intelligence, EPIA2009, pp.288-299, 2009.

[SS12] stage Stack. http://www.ros.org/wiki/stage Last access: 03.07.2012

[SVE11] T. Linner, A. Shrikathiresan, M. Vetrenko, B. Ellmann. Modeling and Op-

erating Robotic Environment using Gazebo/ROS, in Proceedings of the 28th

International Symposium on Automation and Robotics in Construction (IS-

ARC2011), Seoul, Korea, pp.957-962, 2011.

[TRK11] Traxster II Robot kit. http://www.roboticsconnection.com/ Last access:

03.07.2012

[Tur11] TurtleBot, Willow Garage (2011),http://www.willowgarage.com/

turtlebot Last access: 03.07.2012

[WA09] A. Wagner and R. Arkin. Robot Deception: Recognizing when a Robot Should

Deceive, in Proceedings of Computational Intelligence in Robotics and Au-

tomation (CIRA), Daejeon, Korea, December 2009.

[WCM09] B.Wunsche, I. Chen, B. MacDonald. Mixed Reality Simulation for Mobile

Robots, in Proceedings of International Conference on Robotics and Automa-

tion (ICRA 2009), Kobe, Japan, May, 2009.

[XBM06] XBee® Multipoint RF Modules Datasheet (2006), http://www.digi.com/

pdf/ds_xbeemultipointmodules.pdf Last access: 03.07.2012

[ZSS11] S. Zaman, W. Slany and G. Steinbauer. ROS-based Mapping, Localization

and Autonomous Navigation using a Pioneer 3-DX Robot and their Relevant

Issues, in Proceedings of the IEEE Saudi International Electronics, Commu-

nications and Photonics Conference, Riad, Saudi-Arabia, 2011.

http://www.ros.org/wiki/stage

http://www.roboticsconnection.com/

http://www.willowgarage.com/turtlebot

http://www.willowgarage.com/turtlebot

http://www.digi.com/pdf/ds_xbeemultipointmodules.pdf

http://www.digi.com/pdf/ds_xbeemultipointmodules.pdf

Date post:	13-Feb-2017
Category:	Documents
Upload:	vokiet
View:	232 times
Download:	5 times

ROSint - Integration of a mobile robot in ROS architecture

Documents